09-18-2014 01:52 PM - edited 03-17-2019 12:13 AM
I've run into an issue where callers coming from the PSTN do not hear ringback after being transferred using a Cisco Unity call handler.
Ringback works internally between phones, and also works internally if I dial the call handler DN and request a transfer.
Call flow is this: SIP Provider -> CUBE -> SIP Trunk -> CUCM -> Unity Connection (SCCP)
The caller just hears dead air until the phone is picked up, or it bounces to voicemail.
There is an MRGL assigned to the SIP trunk to CUBE that contains an announciator and MoH.
The weird thing is the caller does hear about a second of MoH when Unity begins the transfer, but nothing after that.
debug ccsip messages:
1111111111 is the called party/number, 2222222222 is the calling number (my cellphone)
000925: Sep 18 14:08:06.696 MST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:1111111111@184.71.242.2:5060 SIP/2.0
Via: SIP/2.0/UDP 208.43.85.75:5060;branch=z9hG4bK27e0cc04;rport
From: "2222222222" <sip:2222222222@208.43.85.75>;tag=as2bec68a8
To: <sip:1111111111@184.71.242.2:5060>
Contact: <sip:2222222222@208.43.85.75>
Call-ID: 264119bc6be819f81634da4a67543569@208.43.85.75
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Remote-Party-ID: "2222222222" <sip:2222222222@208.43.85.75>;privacy=off;screen=no
Date: Thu, 18 Sep 2014 20:08:06 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 361
v=0
o=root 1022 1022 IN IP4 208.43.85.75
s=session
c=IN IP4 208.43.85.75
b=CT:384
t=0 0
m=audio 11300 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
m=video 14308 RTP/AVP 34 99
a=rtpmap:34 H263/90000
a=rtpmap:99 H264/90000
a=sendrecv
000926: Sep 18 14:08:06.708 MST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:700@10.135.191.12:5061 SIP/2.0
Via: SIP/2.0/TLS 172.18.0.1:5061;branch=z9hG4bK40E577
Remote-Party-ID: "2222222222" <sip:2222222222@172.18.0.1>;party=calling;screen=no;privacy=off
From: "2222222222" <sip:2222222222@sip1.ixica.com>;tag=1D82524-20B8
To: <sip:700@10.135.191.12>
Date: Thu, 18 Sep 2014 20:08:06 GMT
Call-ID: 56A4B001-3EA611E4-8227D749-31CC0927@172.18.0.1
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 1453513609-1051070948-2183255881-0835455271
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M6a
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1411070886
Contact: <sip:2222222222@172.18.0.1:5061;transport=tls>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 394
v=0
o=CiscoSystemsSIP-GW-UserAgent 6324 6685 IN IP4 172.18.0.1
s=SIP Call
c=IN IP4 172.18.0.1
t=0 0
m=audio 16420 RTP/AVP 0 101
c=IN IP4 172.18.0.1
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
m=video 16422 RTP/AVP 34 119
c=IN IP4 172.18.0.1
a=rtpmap:34 H263/90000
a=fmtp:34 CIF=1
a=rtpmap:119 H264/90000
a=fmtp:119 profile-level-id=000000
000927: Sep 18 14:08:06.712 MST: //1040/56A2DB898221/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 208.43.85.75:5060;branch=z9hG4bK27e0cc04;rport
From: "2222222222" <sip:2222222222@208.43.85.75>;tag=as2bec68a8
To: <sip:1111111111@184.71.242.2:5060>
Date: Thu, 18 Sep 2014 20:08:06 GMT
Call-ID: 264119bc6be819f81634da4a67543569@208.43.85.75
CSeq: 102 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.2.4.M6a
Content-Length: 0
000928: Sep 18 14:08:06.716 MST: //1042/56A2DB898221/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/TLS 172.18.0.1:5061;branch=z9hG4bK40E577
From: "2222222222" <sip:2222222222@sip1.ixica.com>;tag=1D82524-20B8
To: <sip:700@10.135.191.12>
Date: Thu, 18 Sep 2014 20:08:06 GMT
Call-ID: 56A4B001-3EA611E4-8227D749-31CC0927@172.18.0.1
CSeq: 101 INVITE
Allow-Events: presence
Content-Length: 0
000929: Sep 18 14:08:06.728 MST: //1042/56A2DB898221/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS 172.18.0.1:5061;branch=z9hG4bK40E577
From: "2222222222" <sip:2222222222@sip1.ixica.com>;tag=1D82524-20B8
To: <sip:700@10.135.191.12>;tag=6169~dc062259-9b0a-4df2-b05d-e4de329c1980-23733830
Date: Thu, 18 Sep 2014 20:08:06 GMT
Call-ID: 56A4B001-3EA611E4-8227D749-31CC0927@172.18.0.1
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence
Server: Cisco-CUCM10.5
Supported: X-cisco-srtp-fallback
Supported: Geolocation
P-Asserted-Identity: "Cisco Unity" <sip:800@10.135.191.12>
Remote-Party-ID: "Cisco Unity" <sip:800@10.135.191.12>;party=called;screen=yes;privacy=off
Contact: <sip:700@10.135.191.12:5061;transport=tls>
Content-Length: 0
000930: Sep 18 14:08:06.732 MST: //1040/56A2DB898221/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 208.43.85.75:5060;branch=z9hG4bK27e0cc04;rport
From: "2222222222" <sip:2222222222@208.43.85.75>;tag=as2bec68a8
To: <sip:1111111111@184.71.242.2:5060>;tag=1D82538-D9C
Date: Thu, 18 Sep 2014 20:08:06 GMT
Call-ID: 264119bc6be819f81634da4a67543569@208.43.85.75
CSeq: 102 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: "Cisco Unity" <sip:800@184.71.242.2>;party=called;screen=yes;privacy=off
Contact: <sip:700@184.71.242.2:5060>
Server: Cisco-SIPGateway/IOS-15.2.4.M6a
Content-Length: 0
000931: Sep 18 14:08:06.804 MST: //1042/56A2DB898221/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 172.18.0.1:5061;branch=z9hG4bK40E577
From: "2222222222" <sip:2222222222@sip1.ixica.com>;tag=1D82524-20B8
To: <sip:700@10.135.191.12>;tag=6169~dc062259-9b0a-4df2-b05d-e4de329c1980-23733830
Date: Thu, 18 Sep 2014 20:08:06 GMT
Call-ID: 56A4B001-3EA611E4-8227D749-31CC0927@172.18.0.1
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence, kpml
Supported: replaces
Server: Cisco-CUCM10.5
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires: 1800;refresher=uas
Require: timer
P-Asserted-Identity: "Cisco Unity" <sip:800@10.135.191.12>
Remote-Party-ID: "Cisco Unity" <sip:800@10.135.191.12>;party=called;screen=yes;privacy=off
Contact: <sip:700@10.135.191.12:5061;transport=tls>;isFocus
Content-Type: application/sdp
Content-Length: 406
v=0
o=CiscoSystemsCCM-SIP 6169 1 IN IP4 10.135.191.12
s=SIP Call
c=IN IP4 10.135.191.12
b=TIAS:64000
b=CT:64
b=AS:64
t=0 0
m=audio 25280 RTP/AVP 0 101
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
m=video 0 RTP/AVP 31 34 96 97
a=rtpmap:31 H261/90000
a=rtpmap:34 H263/90000
a=rtpmap:96 H263-1998/90000
a=rtpmap:97 H264/90000
a=content:main
a=inactive
000932: Sep 18 14:08:06.808 MST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
ACK sip:700@10.135.191.12:5061;transport=tls SIP/2.0
Via: SIP/2.0/TLS 172.18.0.1:5061;branch=z9hG4bK40F1BB8
From: "2222222222" <sip:2222222222@sip1.ixica.com>;tag=1D82524-20B8
To: <sip:700@10.135.191.12>;tag=6169~dc062259-9b0a-4df2-b05d-e4de329c1980-23733830
Date: Thu, 18 Sep 2014 20:08:06 GMT
Call-ID: 56A4B001-3EA611E4-8227D749-31CC0927@172.18.0.1
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: telephone-event
Content-Length: 0
000933: Sep 18 14:08:06.812 MST: //1040/56A2DB898221/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 208.43.85.75:5060;branch=z9hG4bK27e0cc04;rport
From: "2222222222" <sip:2222222222@208.43.85.75>;tag=as2bec68a8
To: <sip:1111111111@184.71.242.2:5060>;tag=1D82538-D9C
Date: Thu, 18 Sep 2014 20:08:06 GMT
Call-ID: 264119bc6be819f81634da4a67543569@208.43.85.75
CSeq: 102 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: "Cisco Unity" <sip:800@184.71.242.2>;party=called;screen=yes;privacy=off
Contact: <sip:1111111111@184.71.242.2:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.2.4.M6a
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 292
v=0
o=CiscoSystemsSIP-GW-UserAgent 4672 7011 IN IP4 184.71.242.2
s=SIP Call
c=IN IP4 184.71.242.2
t=0 0
m=audio 16416 RTP/AVP 0 101
c=IN IP4 184.71.242.2
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
m=video 0 RTP/AVP 34
c=IN IP4 184.71.242.2
000934: Sep 18 14:08:06.896 MST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:1111111111@184.71.242.2:5060 SIP/2.0
Via: SIP/2.0/UDP 208.43.85.75:5060;branch=z9hG4bK243fd8d0;rport
From: "2222222222" <sip:2222222222@208.43.85.75>;tag=as2bec68a8
To: <sip:1111111111@184.71.242.2:5060>;tag=1D82538-D9C
Contact: <sip:2222222222@208.43.85.75>
Call-ID: 264119bc6be819f81634da4a67543569@208.43.85.75
CSeq: 102 ACK
User-Agent: Asterisk PBX
Max-Forwards: 70
Remote-Party-ID: "2222222222" <sip:2222222222@208.43.85.75>;privacy=off;screen=no
Content-Length: 0
000935: Sep 18 14:08:17.351 MST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
UPDATE sip:2222222222@172.18.0.1:5061;transport=tls SIP/2.0
Via: SIP/2.0/TLS 10.135.191.12:5061;branch=z9hG4bK8347ed20ac
From: <sip:700@10.135.191.12>;tag=6169~dc062259-9b0a-4df2-b05d-e4de329c1980-23733830
To: "2222222222" <sip:2222222222@sip1.ixica.com>;tag=1D82524-20B8
Date: Thu, 18 Sep 2014 20:08:07 GMT
Call-ID: 56A4B001-3EA611E4-8227D749-31CC0927@172.18.0.1
User-Agent: Cisco-CUCM10.5
Max-Forwards: 70
Supported: timer,resource-priority,replaces
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 UPDATE
Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=VIDEO_UNSPECIFIED
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires: 1800;refresher=uac
Min-SE: 1800
P-Asserted-Identity: "Anthony" <sip:270@10.135.191.12>
Remote-Party-ID: "Anthony" <sip:270@10.135.191.12>;party=calling;screen=yes;privacy=off
Contact: <sip:700@10.135.191.12:5061;transport=tls>
Content-Length: 0
000936: Sep 18 14:08:17.351 MST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 10.135.191.12:5061;branch=z9hG4bK8347ed20ac
From: <sip:700@10.135.191.12>;tag=6169~dc062259-9b0a-4df2-b05d-e4de329c1980-23733830
To: "2222222222" <sip:2222222222@sip1.ixica.com>;tag=1D82524-20B8
Date: Thu, 18 Sep 2014 20:08:17 GMT
Call-ID: 56A4B001-3EA611E4-8227D749-31CC0927@172.18.0.1
Server: Cisco-SIPGateway/IOS-15.2.4.M6a
CSeq: 101 UPDATE
Allow-Events: telephone-event
Contact: <sip:270@172.18.0.1:5061;transport=tls>
Require: timer
Session-Expires: 1800;refresher=uac
Supported: timer
Content-Length: 0
000937: Sep 18 14:08:22.894 MST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
BYE sip:1111111111@184.71.242.2:5060 SIP/2.0
Via: SIP/2.0/UDP 208.43.85.75:5060;branch=z9hG4bK7d5b6278;rport
From: "2222222222" <sip:2222222222@208.43.85.75>;tag=as2bec68a8
To: <sip:1111111111@184.71.242.2:5060>;tag=1D82538-D9C
Call-ID: 264119bc6be819f81634da4a67543569@208.43.85.75
CSeq: 103 BYE
User-Agent: Asterisk PBX
Max-Forwards: 70
Remote-Party-ID: "2222222222" <sip:2222222222@208.43.85.75>;privacy=off;screen=no
Content-Length: 0
000938: Sep 18 14:08:22.898 MST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 208.43.85.75:5060;branch=z9hG4bK7d5b6278;rport
From: "2222222222" <sip:2222222222@208.43.85.75>;tag=as2bec68a8
To: <sip:1111111111@184.71.242.2:5060>;tag=1D82538-D9C
Date: Thu, 18 Sep 2014 20:08:22 GMT
Call-ID: 264119bc6be819f81634da4a67543569@208.43.85.75
Server: Cisco-SIPGateway/IOS-15.2.4.M6a
CSeq: 103 BYE
Reason: Q.850;cause=16
P-RTP-Stat: PS=804,OS=128640,PR=693,OR=98712,PL=0,JI=0,LA=0,DU=16
Content-Length: 0
000939: Sep 18 14:08:22.898 MST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
BYE sip:700@10.135.191.12:5061;transport=tls SIP/2.0
Via: SIP/2.0/TLS 172.18.0.1:5061;branch=z9hG4bK4102F8
From: "2222222222" <sip:2222222222@sip1.ixica.com>;tag=1D82524-20B8
To: <sip:700@10.135.191.12>;tag=6169~dc062259-9b0a-4df2-b05d-e4de329c1980-23733830
Date: Thu, 18 Sep 2014 20:08:17 GMT
Call-ID: 56A4B001-3EA611E4-8227D749-31CC0927@172.18.0.1
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M6a
Max-Forwards: 70
Timestamp: 1411070902
CSeq: 102 BYE
Reason: Q.850;cause=16
P-RTP-Stat: PS=693,OS=98712,PR=804,OR=128640,PL=0,JI=0,LA=0,DU=16
Content-Length: 0
000940: Sep 18 14:08:22.902 MST: //1042/56A2DB898221/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 172.18.0.1:5061;branch=z9hG4bK4102F8
From: "2222222222" <sip:2222222222@sip1.ixica.com>;tag=1D82524-20B8
To: <sip:700@10.135.191.12>;tag=6169~dc062259-9b0a-4df2-b05d-e4de329c1980-23733830
Date: Thu, 18 Sep 2014 20:08:23 GMT
Call-ID: 56A4B001-3EA611E4-8227D749-31CC0927@172.18.0.1
Server: Cisco-CUCM10.5
CSeq: 102 BYE
Content-Length: 0
CUBE Dialpeers and voice config:
voice service voip
ip address trusted list
mode border-element
allow-connections sip to sip
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
sip
registrar server expires max 1200 min 300
rel1xx disable
midcall-signaling passthru
g729 annexb-all
dial-peer voice 1000 voip
description *** Outbound CUCM ***
destination-pattern ...
session protocol sipv2
session target ipv4:XXXXXX
session transport tcp tls
dtmf-relay rtp-nte
codec g711ulaw
no vad
!
dial-peer voice 2000 voip
description *** Inbound CUCM ***
session protocol sipv2
session transport tcp tls
incoming called-number ...
dtmf-relay rtp-nte
codec g711ulaw
no vad
!
dial-peer voice 101 voip
description *** Incoming Dial-Peer ***
translation-profile incoming INCOMING1
session protocol sipv2
session target sip-server
incoming called-number 1111111111
dtmf-relay rtp-nte
codec g711ulaw
no vad
!
dial-peer voice 1 voip
description *** Outbound Dial-Peer ***
translation-profile outgoing Strip9
destination-pattern 9.+
session protocol sipv2
session target sip-server
dtmf-relay rtp-nte
codec g711ulaw
no vad
!
10-15-2014 09:39 AM
for testing purpose, can you create the following SIP Profile and apply it to dial peer 1000 and then test please? also collect debug ccsip message & debug voice ccapi inout & ccm traces
voice class sip-profiles 2
request ANY sip-header Allow-Header modify "UPDATE, " ""
response ANY sip-header Allow-Header modify "UPDATE, " ""
!
dial-peer voice 1000 voip
description *** CUCM ***
destination-pattern ...
session protocol sipv2
session target ipv4:10.135.191.12
session transport tcp tls
voice-class sip profiles 2
dtmf-relay rtp-nte
codec g711ulaw
no vad
!
10-15-2014 11:16 AM
I have added the requested config to CUBE, then tested. Attached is the debug output from CUBE, and the CUCM traces.
The problem remains the same.
Calling details remain the same as before, call time was 12:10PM.
Thanks,
Anthony
10-15-2014 11:50 AM
Hi Anthony, could you please create a separate MRG only with ANNs and add it to a separate MRGL and apply that MRGL to SIP Trunk? save, reset and test it once please.
10-15-2014 12:02 PM
Hi Suresh,
I created a new MRGL with just the ANN in it and assigned it to the trunk facing CUBE, reset the trunk, then tested; the issue remains the same.
I don't hear the split second of MOH when the transfer is started with this new MRGL, confirming that the MRGL was changed properly..
Thank you,
Anthony
08-13-2017 02:02 PM
Thanks for the tip. Just had this issue and this was part of my resolution. I had 2 devices pools, one of which I thought wasn't being used. It was, and the locale and the MRGL were both wrong. Thanks for the pointers chaps.
10-14-2014 02:45 PM
Abrandelli, have you ever resolved this issue? If so, please share your solution...
I've a pretty similar scenario. The only different I've SIP all the way down to CUC...and the issue is exactly what you've described.
Thank you!
10-14-2014 03:45 PM
I'm hoping to have an answer from TAC this week. I tried all sorts of different suggestions from various sources and I had no luck getting this to work at all.
10-20-2014 01:44 AM
Please PM me your email and number, I have a TAC case opened.
10-24-2014 07:32 AM
Here is the resolution on this, it turns out there was numerous issues here that were playing into this.
The issue with the inactive SDP coming from the ITSP was fixed by always requiring an MTP on the trunk to CUBE, I don't know why this is required, and I would like to find out why, but at this point I'm just happy this is working because the ITSP did not have anyone else experiencing this issue they say.
Now the issue with the ringback not being present was due to a locale issue in CUCM. I am not sure why this issue existed and here is why. The default network locale in enterprise params is set to "United States", the Network Locale in the device pool that everything uses it set to "< None >", which to me should mean it looked at the Enterprise Param. After installing the combined network locale pack COP file from cisco.com and restarting the cluster the issue is now fixed, ring back is present to the PSTN caller. After I did this I then changed the network locale in the device pool to "Canada", and reset all devices in the pool, and ringback is still present.
I'm almost wondering if this was a browser issue, if that at all seems possible, I'm using chrome and I'm having a lot of issues with it not rendering pages from the CM admin console properly. Things are out of place, missing, etc.
Thank you so much to everyone who took time to help me with this, you guys are great!
Anthony
10-24-2014 08:07 AM
Anthony,
First of all congratulations on getting this resolved. Well done for sticking with it and it was a great pleasure working through this with you.
Second, How did you discover it was a locale issue. Was there any log files that showed this? Did you see errors in the CUCM IPVMS log files?
Thirdly,
When an MTP is involved in a call flow, the dynamics of the call flow changes because MTP stays in the media path. So there is never a break in media and no inactive SDP attribute is sent. The flow looks like below:
CUBE------Media------MTP------------Media-------Unity connection
When the new destination is dialled and transfer is committed, the call flow stays the same
CUBE-------------media----MTP--------media---------IP phone
if there is no MTP, the media path is between CUBE and the IP Phone directly hence when media changes, CUCM has to update it by sending RE-INVITE to CUBE ( it is this re-INVITE that has the inactive DSP which your provider is not responding well too). If MTP is involved, CUCM keeps the media leg between MTP and CUBE from beginning to end; when necessary, it just updates another leg of MTP between MTP and CUBE. UPDATE messages does not include any SDP, so there is no way an inactive attribute can be sent.
This is the flow without an MTP
CUBE-------------media-----Unity connection
When the new destination is dialled and transfer is committed, the call flow stays the same
CUBE-------------no media-----Unity connection
CUBE-------------media-----Transferred destination
Hope this helps
10-24-2014 08:37 AM
Deji,
There was indications in the IPVMS traces, silly me for not seeing this myself, but well done to TAC.
As soon as I saw this it was so obvious it was a network locale issue.
As well thank you for the explanation regarding the media streams, I'm still so new to CUCM and the VOIP world in general!
Thanks,
Anthony
10-24-2014 08:08 AM
You can also use following configuration in SIP Profile associated to SIP trunk to prevent sending “a=inactive” from CUCM. No need of any changes in the CUBE.
a. “Require SDP Inactive Exchange for Mid-Call Media Change” - “UNCHECK”
b. “Send send-receive SDP in mid-call INVITE” – “CHECK”
Note: Need early offer to check the above parameter : You may use "Early Offer support for voice and video calls (insert MTP if needed)" in the SIP Profile.
By this changes, CUCM will not send "a=inactive" to tear down the established media.
You can test this by un checking the MTP from the SIP Trunk.
Regards,
Jebin
10-24-2014 08:33 AM
Hi Jebin,
I made the requested changes in the SIP profile of the trunk to CUBE and CUC and I observe that there is now an RTP stream from the phone to the CUBE IP, before there was no RTP stream at all. However there is no audio to the called IP phone, and even though there is an RTP stream from the called IP phone there is still no audio heard on the PSTN.
Thanks,
Anthony
10-24-2014 10:44 AM
Anthony, sorry to bother you on this..can you make the changes above again and test. Please send me cucm traces. This feature is supposed to help in scenarios like this and even though it has been well documented, I would like to see it working in real life scenarios like this. If we can mae this work then you wont need to use MTP
10-24-2014 10:56 AM
No bother at all! Note that in addition to there being no audio in the call ringback is not present when "MTP required" is unchecked, so there is basically no audio present after the transfer is initiated.
Just to confirm "MTP required" is unchecked on both the CUC and CUBE trunks, and Send send-receive SDP in mid-call INVITE is checked in both SIP trunk profiles, Require SDP Inactive Exchange for Mid-Call Media Change unchecked.
Find attached traces for a call at 11:50AM from 4038012565 to 5873171522, transfer to Ext. 270.
Thanks,
Anthony
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide