Re: Call foward from Voicemail to External number over SIP - not working

bholashrestha · ‎11-06-2017

Hi
Hoping someone could assist me. We are having issue with a certain call flow and Service Provider thinks it is vendor (PBX), Vendor thinks its service provider.

Call scenario is like this.....
User A (DN 46834) calls User B (DN 46640) which goes to voicemail. User B has voicemail with Caller Input option "0" enabled to transfer the call to 0800 number. When Caller A hears the greeting and press option "0", caller A hears the unity message "Please wait while I transfer your call" followed by MOH and then call disconnects.

0800 number is a toll free number on Intelligent Network which i believe runs SS7 signalling.

I have provided the CUCM logs, CUBE logs (both) and logs from ITSP and approximate diagram of how everything is in place.

I have changed the IP address to fictitious one and shown in diagram as well.

CUCM:11.11.11.11
UNITY: 111.111.111.111

CUBE1:
CUCM Facing: 22.22.22.22
CUBE2 Facing: 33.33.33.33

CUBE2:
CUBE1 Facing: 44.44.44.44
ITSP Facing: 55.55.55.55
Loopback: 66.66.66.66 (ITSP talks directly to this)

ITSP: 77.77.77.77

Phone: 99.99.99.99
Transcoder: 88.88.88.88

Region Relationship:
phone-CuBE - G729
VM Port to CUBE: G729
Phone to VM port: G729
Calling Number: DN 46834
Called Numver: DN 46640
Final Called Number: 0800838383
Time Stamp: Sep 14 16:22:11

Regards

BRS

Andrew West · ‎11-06-2017

Does RTMT show the call getting back from UC?

RTMT Real TIme Data/Traffic to be specific

bholashrestha · ‎11-07-2017

I think it does. Is this what you mean (attached)?

Regards

BRS

Ayodeji Okanlawon · ‎11-10-2017

Hi,

Apologies for the delay in response. I have looked at the logs and here is what is going on..

++ Call comes in from cube and negotiates G711ulaw between the two phones +++

Will update this later

Please rate all useful posts

bholashrestha · ‎11-12-2017

Thanks for looking into this

Just to clarify..

Call flow is
phone to phone -> Voicemail
Voicemail forwards calls to ITSP

Initial invite (in PRACK) from CUCM sends IP address of Transcoder (88.88.88.88) to CUBE because of the relationship between the voicemail port and CUBE being G729 relationship. In this case CUCM has allocated transcoder for Unity Connection.

However when the call is transfered from Unity, the update being sent to CUBE from call manager has IP address of the phone (99.99.99.99) instead of transcoder. Phone and CUBE alos has G729 so the CUBE is rejecting the call. I would have expected the transcoder to be invoked in this case as well but its not.

If I change the relationship between CUBE and Phone to G711 the call will work, but there are some design restriction for this.

So my question really is around, why transcoder was not invoked or if there are any SIP messaging that is prventing the CUCM to allocate transocder for the phone.

Thanks

Ayodeji Okanlawon · ‎11-13-2017

Here is my summary

NB: We dont see the original call leg from CUBE to CUCM on the logs. Its possible that call leg went to another CUCM server

++ CUCM sends an outbound INVITE to CUBE for the call from voicemail ++

93148216.001 |16:21:03.583 |AppInfo |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 22.22.22.22:[5060]:
[7791082,NET]
INVITE sip:218000800838383@22.22.22.22:5060 SIP/2.0
Via: SIP/2.0/UDP 11.11.11.11:5060;branch=z9hG4bK10857a4aef59f4
From: "VoiceMail" <sip:29500@11.11.11.11>;tag=2818603~b5d96d6e-2656-4d33-a07b-ca72cfe7a573-262898773
To: <sip:218000800838383@22.22.22.22>
Date: Thu, 14 Sep 2017 04:21:03 GMT
Call-ID: 1d5ba700-9ba103af-fd942-b6e6c0a@11.11.11.11

+++ CUBE responds and whats to connect using G711a +++

93148225.001 |16:21:03.904 |AppInfo |//SIP/SIPUdp/wait_UdpDataInd: Incoming SIP UDP message size 1083 from 22.22.22.22:[63023]:
[7791084,NET]
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 11.11.11.11:5060;branch=z9hG4bK10857a4aef59f4
From: "VoiceMail" <sip:29500@11.11.11.11>;tag=2818603~b5d96d6e-2656-4d33-a07b-ca72cfe7a573-262898773
To: <sip:218000800838383@22.22.22.22>;tag=80CA8234-14F5
Date: Thu, 14 Sep 2017 04:21:03 GMT
Call-ID: 1d5ba700-9ba103af-fd942-b6e6c0a@11.11.11.11
CSeq: 101 INVITE
Require: 100rel
-
Remote-Party-ID: <sip:218000800838383@22.22.22.22>;party=called;screen=yes;privacy=off
Contact: <sip:218000800838383@22.22.22.22:5060>
-
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 250

v=0
o=CiscoSystemsSIP-GW-UserAgent 2664 1328 IN IP4 22.22.22.22
s=SIP Call
c=IN IP4 22.22.22.22
t=0 0
m=audio 21448 RTP/AVP 8 101
c=IN IP4 22.22.22.22
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

++ CUCM needs to send PRACK and therefore invokes xcoder because the region between VM and CUBE =G729, but CUBE wants to do G711alaw on this leg ++

93148260.011 |16:21:03.911 |AppInfo |DET-MediaManager-(2494)::preCheckCapabilities, region1=ANB_VM_RGN, region2=ANB_GW_RGN, Pty1 capCount=6 (Cap,ptime)= (4,30) (11,60) (12,60) (2,30) (6,30) (257,10), Pty2 capCount=1 (Cap,ptime)= (2,20)

93148364.001 |16:21:03.929 |AppInfo |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 22.22.22.22:[5060]:
[7791085,NET]
PRACK sip:218000800838383@22.22.22.22:5060 SIP/2.0
Via: SIP/2.0/UDP 11.11.11.11:5060;branch=z9hG4bK10857b67f4aca5
From: "VoiceMail" <sip:29500@11.11.11.11>;tag=2818603~b5d96d6e-2656-4d33-a07b-ca72cfe7a573-262898773
To: <sip:218000800838383@22.22.22.22>;tag=80CA8234-14F5
---
Call-ID: 1d5ba700-9ba103af-fd942-b6e6c0a@11.11.11.11
CSeq: 102 PRACK
-
v=0
o=CiscoSystemsCCM-SIP 2818603 1 IN IP4 11.11.11.11
s=SIP Call
c=IN IP4 88.88.88.88
b=TIAS:64000
b=AS:64
t=0 0
m=audio 29498 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

++ At this point we have connected the 2nd leg forwarded from voicemail to CUBE, Next we need to complete the transfer to the original caller.

++ Next CUCM sends a first UPDATE to break the media on this leg while attempting to complete the transfer ++

93148604.000 |16:21:04.004 |SdlSig |SIPSPISignal |wait |SIPUdp(15,100,63,1) |SIPHandler(15,100,72,1) |15,100,13,4454241.104^111.111.111.111^ANBAK2-U1-VI1 |*TraceFlagOverrode
93148604.001 |16:21:04.004 |AppInfo |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 22.22.22.22:[5060]:
[7791087,NET]
UPDATE sip:218000800838383@22.22.22.22:5060 SIP/2.0
Via: SIP/2.0/UDP 11.11.11.11:5060;branch=z9hG4bK10857c34a45bb9
From: "VoiceMail" <sip:29500@11.11.11.11>;tag=2818603~b5d96d6e-2656-4d33-a07b-ca72cfe7a573-262898773
To: <sip:218000800838383@22.22.22.22>;tag=80CA8234-14F5
Date: Thu, 14 Sep 2017 04:21:03 GMT
Call-ID: 1d5ba700-9ba103af-fd942-b6e6c0a@11.11.11.11
User-Agent: Cisco-CUCM9.1
--
P-Asserted-Identity: "VoiceMail" <sip:29500@11.11.11.11>
Remote-Party-ID: "VoiceMail" <sip:29500@11.11.11.11>;party=calling;screen=yes;privacy=off
Contact: <sip:29500@11.11.11.11:5060>;isFocus
Content-Type: application/sdp
Content-Length: 246

v=0
o=CiscoSystemsCCM-SIP 2818603 2 IN IP4 11.11.11.11
s=SIP Call
c=IN IP4 0.0.0.0
b=TIAS:64000
b=AS:64
t=0 0
m=audio 29498 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000

++ Next CUCM sends a second UPDATE to update the caller-id to that of the original caller +++

93148830.001 |16:21:04.124 |AppInfo |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 22.22.22.22:[5060]:
[7791089,NET]
UPDATE sip:218000800838383@22.22.22.22:5060 SIP/2.0
Via: SIP/2.0/UDP 11.11.11.11:5060;branch=z9hG4bK10857d7f0c0f92
From: "VoiceMail" <sip:29500@11.11.11.11>;tag=2818603~b5d96d6e-2656-4d33-a07b-ca72cfe7a573-262898773
--
P-Asserted-Identity: "46834 - Beauden Barrett" <sip:46834@11.11.11.11>
Remote-Party-ID: "46834 - Beauden Barrett" <sip:46834@11.11.11.11>;party=calling;screen=yes;privacy=off
Contact: <sip:29500@11.11.11.11:5060>
Content-Length: 0

++ Next CUCM sends a final UPDATE to connect the first call leg ++

Note now that the region relationship between the call legs is re-evaluated. Now we have region relationship between CUBE and original caller

93148902.007 |16:21:04.198 |AppInfo |DET-SIPInterface-(2759)::filterAudioCaps, mAudiomLine[0].capCount=8 index=0 after filter
93148902.008 |16:21:04.198 |AppInfo |DET-RegionsServer::sortMediaPayload-capCount=2, regionA=ANB_GW_RGN, regionB=ANBPOCDC1_RGN,

++ Based on this CUCM sends an UPDATE using G729 and IP address of the phone ++

( The only way cucm will ever invoke a xocder here is if this UPDATE was sent using DO ++

UPDATE sip:218000800838383@22.22.22.22:5060 SIP/2.0
Via: SIP/2.0/UDP 11.11.11.11:5060;branch=z9hG4bK10857e77075668
From: "VoiceMail" <sip:29500@11.11.11.11>;tag=2818603~b5d96d6e-2656-4d33-a07b-ca72cfe7a573-262898773
To: <sip:218000800838383@22.22.22.22>;tag=80CA8234-14F5
Date: Thu, 14 Sep 2017 04:21:03 GMT
Call-ID: 1d5ba700-9ba103af-fd942-b6e6c0a@11.11.11.11
User-Agent: Cisco-CUCM9.1
Max-Forwards: 70
Supported: timer,resource-priority,replaces
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 105 UPDATE
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires: 1800;refresher=uas
P-Asserted-Identity: "46834 - Beauden Barrett" <sip:46834@11.11.11.11>
Remote-Party-ID: "46834 - Beauden Barrett" <sip:46834@11.11.11.11>;party=calling;screen=yes;privacy=off
Contact: <sip:29500@11.11.11.11:5060>
Content-Type: application/sdp
Content-Length: 261

v=0
o=CiscoSystemsCCM-SIP 2818603 3 IN IP4 11.11.11.11
s=SIP Call
c=IN IP4 99.99.99.99
b=TIAS:8000
b=AS:8
t=0 0
m=audio 18264 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no

++ CUBE then responds with 488 media unacceptable ++

93148909.001 |16:21:04.216 |AppInfo |//SIP/SIPUdp/wait_UdpDataInd: Incoming SIP UDP message size 466 from 22.22.22.22:[63023]:
[7791092,NET]
SIP/2.0 488 Not Acceptable Media
Via: SIP/2.0/UDP 11.11.11.11:5060;branch=z9hG4bK10857e77075668
From: "VoiceMail" <sip:29500@11.11.11.11>;tag=2818603~b5d96d6e-2656-4d33-a07b-ca72cfe7a573-262898773
To: <sip:218000800838383@22.22.22.22>;tag=80CA8234-14F5
Date: Thu, 14 Sep 2017 04:21:04 GMT
Call-ID: 1d5ba700-9ba103af-fd942-b6e6c0a@11.11.11.11
Server: Cisco-SIPGateway/IOS-15.4.3.S5
CSeq: 105 UPDATE
Allow-Events: telephone-event
Content-Length: 0

+++ Suggestions/Solution +++

Configure the dial-peer on the CUBE for the called number 218000800838383 to use G729 instead of G711a

two: Configure on-board xcoding on CUBE so that CUBE will inkove xcoder for this call leg. Because essentially what you have is that CUCM leg is G729 and CUBE leg is G711alaw, because CUCM has sent offer in UPDATE using g729, cube then has to xcode on its side

The reason why this works when you use G711 between phone and CUBE is that on the final leg of that call as I analyzed, CUCM will send UPDATE using G711alaw and since the CUBE leg is also G711ala, it works without any issues

Please rate all useful posts

bholashrestha · ‎11-14-2017

Thanks for your time. This explains why expected behaviour i.e. transcoder use was not taking place.

Could you please clarify one thing. You mentioned in your reply "The only way cucm will ever invoke a xocder here is if this UPDATE was sent using DO"

What is "DO" and if there is anything in cucm settings that can make cucm send update using DO?

Thanks again for your help.

Regards

Ayodeji Okanlawon · ‎11-14-2017

DO is delayed offer. In delay offer, CUBE will send its own codec and CUCM will then say that since CUBE wants to negotiate G711 and the region setting is set to G729, it will then invoke a transcoder. I am not sure if we can force CUCM to do that.

Please rate all useful posts