No Ringback from SIP Provider after Unity Transfer

[Anthony Brandelli]

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
!

[Suresh Subramanian]

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
!

[Anthony Brandelli]

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

[Suresh Subramanian]

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.

[Anthony Brandelli]

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

[r.hall]

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. 

[Gustavo Moreschi]

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!

[Anthony Brandelli]

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.

[Ayodeji Okanlawon]

Please PM me your email and number, I have a TAC case opened.

[Anthony Brandelli]

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

[Ayodeji Okanlawon]

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

[Anthony Brandelli]

Deji,

There was indications in the IPVMS traces, silly me for not seeing this myself, but well done to TAC. 

14:22:02.997 |   CANNAudio::GetAnnouncement() Ann file missing (AnnRingBack.wav) UserLocale(1) Country(6)

14:22:02.997 |   CANNAudio::GetAnnouncement() Ann(Alertingtone) File(/usr/local/cm/tftp/)

14:22:02.997 |   CPlayWavFilesMgr::CMsgQueue::PostThreadMessage() Message enqueued, MsgType=1026, wP=0, lP=-144505896, queueSize=1

14:22:02.997 |   CPlayWavFilesMgr::CMsgQueue::GetMessage() Message dequeued, MsgType=1026, wP=0, lP=-144505896, queueSize=0

14:22:02.997 |   IpPlayWav::Play (24,18139461,0) Play (/usr/local/cm/tftp/) I(0) (/usr/local/cm/tftp/)

14:22:02.998 |   IpPlayWav::OpenWav (24,18139461,0) WAV open(/usr/local/cm/tftp/) failed err 2

14:22:02.998 |   CIpPlayWav::StartPlaying.ST_PLAYING_FIRST (24,18139461,0) *ERROR* Error openning WAV file (/usr/local/cm/tftp/)

14:22:02.998 |   IpPlayWav::CloseWav (24,18139461,0) Cached: False  CacheSize(1) CacheMem(0KB) CachePeakMem(397KB) CacheHits(0) CacheReq(3)

14:22:02.998 |   CIpPlayWav::NotifyCM (24,18139461,0) No notification

14:22:02.998 |   IpPlayWav::StopMediaMsg (24,18139461,0) Stop USR RX:

14:22:02.998 |   CSignalHandler::ProcessThreadProc() log 45

14:22:02.998 |   [ANN][CUCM] CEventHandler::WaitForMultipleEvents Removed Event=45 from signaled list, index=2, now size=0

14:22:02.999 |   [ANN][CUCM] CEventHandler::WaitForMultipleEvents Returned from wait on MEvent=128, ret=0, retCode=2

14:22:02.999 |   [ANN][CUCM] DeviceMgr::ProcessThreadProc Returned from wait, ret=2

14:22:02.999 |   [ANN][CUCM] DeviceMgr::ProcessDriverEvents RemoveStreamIoctl(ANN): AId 24, CId 18139461, PId 0: Stream not found.

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

[jkalarit]

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

[Anthony Brandelli]

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

[Ayodeji Okanlawon]

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

[Anthony Brandelli]

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