locked
Exchange 2013 UM- integration issue with a bridged line RRS feed

  • Question

  • We have an Exchange 2013 CU3 system running UM through a Dialogic gateway and an Avaya PBX.  the exchange was migrated from Exchange 2007 with UM.

    We have an AA that is used for Transfer Directly to Mailbox.  It worked fine in 2007.

    Here are tested scenarios in 2013:

    1)  Dial the AA directly from extension 373= AA answers correctly.

    2)  Dial the AA directly from extension 374= AA answers correctly.

    3)  Dial the AA using the Bridged appearance of 374 that is on phone 373 = reach OVA and not the AA.

    I have reviewed the Dialogic traces and also the PBX traces.  They show sending the same information for 2 and 3.  Test 1 just shows the different calling extension.  All calls show the same called and redirect numbers.

    Any ideas if Exchange 2013 would handle these different than 2007?  If so, how to get it working again?

    Thanks.

    Friday, April 11, 2014 2:04 PM

Answers

  • Ends up the users were using a wrong method for the AA.

    I watched one and saw the issue.

    • Marked as answer by BiggJake Tuesday, April 22, 2014 6:27 PM
    Tuesday, April 22, 2014 6:27 PM

All replies

  • Anyone have any ideas?
    Tuesday, April 15, 2014 6:26 PM
  • Were there any diversion headers in the SIP INVITE that was different?

    Please remember, if you see a post that helped you please click "Vote As Helpful" and if it answered your question please click "Mark As Answer". SWC Unified Communications

    Tuesday, April 15, 2014 6:54 PM
  • Not that we can find.

    Below are the invites for both gathered in the4 Dialogic gateway.

    Bridged Line
     <----INVITE sip:2888@192.168.168.131;user=phone;transport=tcp SIP/2.0
    04-10 14:22:56.516 [VoIP      ] Prot     From:"<user1>"<sip:3778@192.168.111.223:5060;user=phone>;vnd.pimg.port=8;tag=10BD324631353641030508B4
    04-10 14:22:56.516 [VoIP      ] Prot     To:<sip:2888@192.168.168.131;user=phone>
    04-10 14:22:56.516 [VoIP      ] Prot     Contact:<sip:3778@192.168.111.223:5060;transport=tcp>
    04-10 14:22:56.516 [VoIP      ] Prot     Diversion: <tel:2880>;reason=no-answer
    04-10 14:22:56.516 [VoIP      ] Prot     Content-Type:application/sdp
    04-10 14:22:56.516 [VoIP      ] Prot     Supported:replaces,100rel
    04-10 14:22:56.516 [VoIP      ] Prot     Allow:INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,REFER,NOTIFY
    04-10 14:22:56.516 [VoIP      ] Prot     Call-ID:02055F354031000A0004C3CE@UMGW.<company>.com
    04-10 14:22:56.516 [VoIP      ] Prot     CSeq:1 INVITE
    04-10 14:22:56.516 [VoIP      ] Prot     Max-Forwards:70
    04-10 14:22:56.516 [VoIP      ] Prot     User-Agent:PBX-IP Media Gateway
    04-10 14:22:56.516 [VoIP      ] Prot     Via:SIP/2.0/TCP 192.168.111.223:5060;branch=z9hG4bK93DC298B159815159E80610605E56E32
    04-10 14:22:56.516 [VoIP      ] Prot     Content-Length:254
    04-10 14:22:56.516 [VoIP      ] Prot    
    04-10 14:22:56.516 [VoIP      ] Prot     v=0
    04-10 14:22:56.516 [VoIP      ] Prot     o=phone 31666 26833 IN IP4 192.168.111.223
    04-10 14:22:56.516 [VoIP      ] Prot     s=-
    04-10 14:22:56.516 [VoIP      ] Prot     c=IN IP4 192.168.111.223
    04-10 14:22:56.516 [VoIP      ] Prot     t=0 0
    04-10 14:22:56.516 [VoIP      ] Prot     m=audio 49334 RTP/AVP 0 8 101 13
    04-10 14:22:56.516 [VoIP      ] Prot     a=rtpmap:0 PCMU/8000/1
    04-10 14:22:56.516 [VoIP      ] Prot     a=rtpmap:8 PCMA/8000/1
    04-10 14:22:56.516 [VoIP      ] Prot     a=ptime:30
    04-10 14:22:56.516 [VoIP      ] Prot     a=rtpmap:101 telephone-event/8000
    04-10 14:22:56.516 [VoIP      ] Prot     a=fmtp:101 0-15
    04-10 14:22:56.516 [VoIP      ] Prot     a=rtpmap:13 CN/8000
    04-10 14:22:56.516 [VoIP      ] Code     [SIP_LAYER 0x99:0] k://scimitar//pimg//sw//src//pbn//trl//so//so_ptli.c:780 SoLiHitDatReq(pst, spId(0), spConId(464), mBuf(0x4502a20)
    04-10 14:22:56.516 [VoIP      ] Code     [SIP_LAYER 0x99:0] k://scimitar//pimg//sw//src//pbn//trl//so//so_tmr.c:326 TIMER: Evnt 98 Action 1 Value 320 CB 0x4efbae8
    04-10 14:22:56.516 [VoIP      ] Code     [SIP_LAYER 0x99:0] k://scimitar//pimg//sw//src//pbn//trl//so//so_tmr.c:326 TIMER: Evnt 9 Action 2 Value 0 CB 0x4efc180
    04-10 14:22:56.516 [VoIP      ] Code     [TCP_UDP_CONVERGENCE_LAYER 0x75:0] k://scimitar//pimg//sw//src//pbn//trl//tucl_1.5//hi_bdy1.c:2123 HiUiHitDatReq(pst, spId(0), spConId(464), mBuf(0x4502a20)))
    04-10 14:22:56.516 [Gw        ] Code     (395aa64) eGW_ST_ORIGINATE<-eGW_ST_ROUTE_METHOD -1
    04-10 14:22:56.516 [Pbn       ] Code     _voipGccCallGetInfo: pSpCall[4115458] pInfo[37d761c]
    04-10 14:22:56.532 [VoIP      ] Code     [TCP_UDP_CONVERGENCE_LAYER 0x75:0] k://scimitar//pimg//sw//src//pbn//trl//tucl_1.5//hi_ptui.c:1251 HiUiHitDatInd(pst, suId(0), suConId(364080), mBuf(0x4502a20))
    04-10 14:22:56.532 [VoIP      ] Code     [SIP_LAYER 0x99:0] k://scimitar//pimg//sw//src//pbn//trl//so//so_li.c:982 SoLiHitDatInd(pst, suId(0), suConnId(364080), mBuf(0x4502a20)
    04-10 14:22:56.532 [VoIP      ] Code     [SIP_LAYER 0x99:0] k://scimitar//pimg//sw//src//pbn//trl//so//so_tmr.c:326 TIMER: Evnt 66 Action 3 Value 300 CB 0x48abe50
    04-10 14:22:56.532 [VoIP      ] Prot    

    Direct Line
    04-10 14:23:11.766 [VoIP      ] Prot     <----INVITE sip:2888@192.168.168.132;user=phone;transport=tcp SIP/2.0
    04-10 14:23:11.766 [VoIP      ] Prot     From:"<User2>"<sip:3777@192.168.111.223:5060;user=phone>;vnd.pimg.port=9;tag=3B443246313536410305094C
    04-10 14:23:11.766 [VoIP      ] Prot     To:<sip:2888@192.168.168.132;user=phone>
    04-10 14:23:11.766 [VoIP      ] Prot     Contact:<sip:3777@192.168.111.223:5060;transport=tcp>
    04-10 14:23:11.766 [VoIP      ] Prot     Diversion: <tel:2880>;reason=no-answer
    04-10 14:23:11.766 [VoIP      ] Prot     Content-Type:application/sdp
    04-10 14:23:11.766 [VoIP      ] Prot     Supported:replaces,100rel
    04-10 14:23:11.766 [VoIP      ] Prot     Allow:INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,REFER,NOTIFY
    04-10 14:23:11.766 [VoIP      ] Prot     Call-ID:02055F354F31000A0004C3D3@UMGW.<company>.com
    04-10 14:23:11.766 [VoIP      ] Prot     CSeq:1 INVITE
    04-10 14:23:11.766 [VoIP      ] Prot     Max-Forwards:70
    04-10 14:23:11.766 [VoIP      ] Prot     User-Agent:PBX-IP Media Gateway
    04-10 14:23:11.766 [VoIP      ] Prot     Via:SIP/2.0/TCP 192.168.111.223:5060;branch=z9hG4bKCCCE1DFA98F09E23BBF24B0D8800A48C
    04-10 14:23:11.766 [VoIP      ] Prot     Content-Length:253
    04-10 14:23:11.766 [VoIP      ] Prot    
    04-10 14:23:11.766 [VoIP      ] Prot     v=0
    04-10 14:23:11.766 [VoIP      ] Prot     o=phone 1442 18834 IN IP4 192.168.111.223
    04-10 14:23:11.766 [VoIP      ] Prot     s=-
    04-10 14:23:11.766 [VoIP      ] Prot     c=IN IP4 192.168.111.223
    04-10 14:23:11.766 [VoIP      ] Prot     t=0 0
    04-10 14:23:11.766 [VoIP      ] Prot     m=audio 49330 RTP/AVP 0 8 101 13
    04-10 14:23:11.766 [VoIP      ] Prot     a=rtpmap:0 PCMU/8000/1
    04-10 14:23:11.766 [VoIP      ] Prot     a=rtpmap:8 PCMA/8000/1
    04-10 14:23:11.766 [VoIP      ] Prot     a=ptime:30
    04-10 14:23:11.766 [VoIP      ] Prot     a=rtpmap:101 telephone-event/8000
    04-10 14:23:11.766 [VoIP      ] Prot     a=fmtp:101 0-15
    04-10 14:23:11.766 [VoIP      ] Prot     a=rtpmap:13 CN/8000
    04-10 14:23:11.766 [VoIP      ] Code     [SIP_LAYER 0x99:0] k://scimitar//pimg//sw//src//pbn//trl//so//so_ptli.c:780 SoLiHitDatReq(pst, spId(0), spConId(469), mBuf(0x4501a30)
    04-10 14:23:11.766 [VoIP      ] Code     [SIP_LAYER 0x99:0] k://scimitar//pimg//sw//src//pbn//trl//so//so_tmr.c:326 TIMER: Evnt 98 Action 1 Value 320 CB 0x4efbae8
    04-10 14:23:11.766 [VoIP      ] Code     [SIP_LAYER 0x99:0] k://scimitar//pimg//sw//src//pbn//trl//so//so_tmr.c:326 TIMER: Evnt 9 Action 2 Value 0 CB 0x4efc180
    04-10 14:23:11.766 [VoIP      ] Code     [TCP_UDP_CONVERGENCE_LAYER 0x75:0] k://scimitar//pimg//sw//src//pbn//trl//tucl_1.5//hi_bdy1.c:2123 HiUiHitDatReq(pst, spId(0), spConId(469), mBuf(0x4501a30)))
    04-10 14:23:11.766 [Gw        ] Code     (395aa64) eGW_ST_ORIGINATE<-eGW_ST_ROUTE_METHOD -1
    04-10 14:23:11.766 [Pbn       ] Code     _voipGccCallGetInfo: pSpCall[411efe8] pInfo[37d761c]
    04-10 14:23:11.782 [VoIP      ] Code     [TCP_UDP_CONVERGENCE_LAYER 0x75:0] k://scimitar//pimg//sw//src//pbn//trl//tucl_1.5//hi_ptui.c:1251 HiUiHitDatInd(pst, suId(0), suConId(364085), mBuf(0x4501a30))
    04-10 14:23:11.782 [VoIP      ] Code     [SIP_LAYER 0x99:0] k://scimitar//pimg//sw//src//pbn//trl//so//so_li.c:982 SoLiHitDatInd(pst, suId(0), suConnId(364085), mBuf(0x4501a30)
    04-10 14:23:11.782 [VoIP      ] Code     [SIP_LAYER 0x99:0] k://scimitar//pimg//sw//src//pbn//trl//so//so_tmr.c:326 TIMER: Evnt 66 Action 3 Value 300 CB 0x48a8650
    04-10 14:23:11.782 [VoIP      ] Prot   

    2888 is the OVA\trunk number

    2880 is the AA we are having issues with.

    Wednesday, April 16, 2014 1:34 PM
  • You do have a diversion, but it is the same for both invites.  What I do see that is different is the IP the invite is going to. 

    .131 and .132

    I assume those are both the same versions of Exchange and can answer the same way.  Assuming you just have 2 Exchange 2013 servers that can take calls, I would just concentrate on troubleshooting with as few Exchange 2013 servers in the mix as possible.  You might have different Exchange servers involved that might not have all the data needed to answer the call as you are expecting it to.

    Wednesday, April 16, 2014 3:27 PM
  • This looks like an Avaya trunking issue if I'm seeing it correctly.

    Why is the invite going to 2888 (OVA) if the call is destined for 2880 (the AA)?  I'd take a look at that, if you're trying to reach 2880, that's what I'd expect to see in the invite, but it looks like the Avaya is trying to pass it through 2888 with a diversion header which isn't quite right.  That would be correct for a call headed to voicemail, but a call to an AA should go directly to 2880.


    Please remember, if you see a post that helped you please click "Vote As Helpful" and if it answered your question please click "Mark As Answer". SWC Unified Communications

    Wednesday, April 16, 2014 8:30 PM
  • Ends up the users were using a wrong method for the AA.

    I watched one and saw the issue.

    • Marked as answer by BiggJake Tuesday, April 22, 2014 6:27 PM
    Tuesday, April 22, 2014 6:27 PM