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
!

[Carlo Poggiarelli]

Hi Anthony.

Please let me know which version of IOS, CUCM and CUC you're running so I'll try to reproduce your environment in my lab.

Thanks 

Regards

Carlo

[Anthony Brandelli]

CUCM 10.5.1.10000-7

CUC Version 10.5.1.10000-7

IOS Version 15.2(4)M6a

Thanks,

Anthony

[tpfrankli]

What as your final resolution to this? I am facing the exact same issue with the same versions of software. I have a TAC case open but they are slowly pouring over logs.

Thanks.

[Anthony Brandelli]

This turned out to be a bunch of issues stacked, as best as I recall it here is what happened:

• Canadian network locale not installed. There was some weirdness surrounding the network locale showing as "< None >" in the device pool, which means it should have used the enterprise parameter default (which was US), but for whatever reason this didn't happen. IPVMS traces showed this issue. 
• The main issue that took so much time to nail down after this turned out to be an ITSP issue. Memory here is a bit fuzzy but I believe that CUBE was sending multiple re-invites to the ITSP in the transfer process, the ITSP wasn't dealing with this in a productive manner and this broke the audio path. The temporary solution here was to configure re-invite consumption on CUBE, the actual fix was to work with the ITSP to deal with the re-invites properly. (http://www.cisco.com/en/US/docs/ios-xml/ios/voice/cube_proto/configuration/15-2mt/voi-cube-midcall-reinvite.html)

With an MTP in the call flow I think everything worked fine, but I did not want, and would not recommend having the need for a software MTP resource being inserted into every call. 

Whether this is your issue is hard to say, but if you aren't getting traction with TAC maybe start a thread here and see what happens. Otherwise I'd give TAC a nudge. 

HTH

Anthony

[wgonzalez07]

My issue was with the Media Resource Groups, make sure you have an ANN on the MRGL you are assigning to the trunks as well as the phones.

Good luck.

[Ayodeji Okanlawon]

One thing I observed which I didn't mention yesterday is that an MTP was involved in this call flow..CUCM had to insert MTP for this call..

+++Here we see this+++

08055575.002 |08:30:06.791 |AppInfo  |MediaTerminationPointControl(6)::getResourcesAllocated -- DeviceName=MTP_2 Ci=25208339 ResourceCount=1
08055647.001 |08:30:06.800 |AppInfo  |MediaTerminationPointControl(6)::star_StationOutputOpenReceiveChannel - TCPPid = [1.100.14.140069] myIP: 0xcbf870a (10.135.191.12) ConferenceID: 16780871, MediaPartyId: 16778500, msecPacketSize: 20 compressionType: 4

+++We can also see this in the 200 OK from cucm to CUBE, CUCM tells cube to send the media to its IP, instead of unity connection's ip+++

08055693.001 |08:30:06.814 |AppInfo  |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.0.1 on port 43004 index 1752
[907307,NET]
SIP/2.0 200 OK
Via: SIP/2.0/TLS 172.18.0.1:5061;branch=z9hG4bK846A1D
From: <sip:4038012565@172.18.0.1>;tag=6D21DB18-167E
To: <sip:700@10.135.191.12>;tag=316422~dc062259-9b0a-4df2-b05d-e4de329c1980-25208335
--
--
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: 248

v=0
o=CiscoSystemsCCM-SIP 316422 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

I believe that it is due to DTMF mismatch (sccp on OOB) and sip on (rtp-nte), even though the logs doesn't give us a reason why MTP is invoked..

There are two things we can do...

1. use SIP integration between unity connection and cucm to remove MTP. Test and see the the call goes directly to unity connection

2.try the following dtmf config on both dial-peer to cucm and itsp

dtmf-relay rtp-nte digit-drop.

3. ensure dtmf on sip trunk is set to no preference.

You can try the option 2 first, check your logs to see the 200Ok has its C=ip address set to that of unity. That way you know no MTP is in use..

[Anthony Brandelli]

Changing to a SIP integration to Unity gives be a few issues that I can't really figure out why they are problems.

Unchecking MTP required on the CUBE trunk and changing to a SIP integration gives me the following problem:

Entering an extension to transfer to results in dead air, no error is played but the call never goes anywhere. 

Picking an option from the menu results in "Wait while I transfer your call" being played, but the call never gets to the phone it should.

DTMF Signalling method is set to "No preference" on both the trunk to CUBE, and CUC. 

In the port group basics page on CUC I have changed the codec advertising to just G711 mu law, which is what the call should be end to end... DTMF should also be inband end to end too... Not sure why the MTP is required here?

Anthony

[Ayodeji Okanlawon]

Can you confirm that your sip security profile for cuc looks like the attached..

I am mobile now so cant look at your logs, but if you still have issues after changing the sip security profile, then please send the cuc conversation manager logs and cucm logs.(will analyse later)

I take it you are the one who selected require MTP on the CUBE sip trunk earlier..If you still have your sccp integration, can you uncheck it, reset you trunk and test again

[Anthony Brandelli]

The SIP security profile does indeed look like that minus the fact that I am using a TLS integration on both ends. 

More or less I was the one who checked the MTP required box, this was enabled as part of an issue with calls not transferring at all through CUC form CUBE. 

Find attached CUC + CUCM traces. Call time was 8:44AM, other details remain the same as previous. 

Thanks again,

Anthony

EDIT: To be clear, the MTP required checkbox was enabled on the CUBE trunk even when the SCCP integration existed. When it was not checked during the SCCP integration calls never transferred properly and experienced a one way audio issue referenced in another thread I opened. 

[Ayodeji Okanlawon]

The issue you are having is with tls and that's why this only worked with MTP checked..

+++This is unity connection spending 200 Ok to the Invite from cucm+++

++NB: the new attribute a=crypto:XXXX+++

00248132.002 |08:44:24.285 |AppInfo  |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 10.135.191.13 on port 5061 index 1118 with 869 bytes:
[26530,NET]
SIP/2.0 200 OK
From: <sip:9014038012565@10.135.191.12>;tag=9566~dc062259-9b0a-4df2-b05d-e4de329c1980-33309488
To: <sip:800@10.135.191.13>;tag=9ef70f0ed9e449f4b4d87fbc5c97222b
Via: SIP/2.0/TLS 10.135.191.12:5061;branch=z9hG4bKb1a34837898
Contact: <sip:800@10.135.191.13:5061;transport=tls>
Expires: 180
Call-ID: ea915980-43f1d9c8-a38-cbf870a@10.135.191.12

--

--

o=CiscoSystemsUCXN 426435743 426435744 IN IP4 10.135.191.13
s=No Subject
c=IN IP4 10.135.191.13
t=0 0
m=audio 18126 RTP/SAVP 0 101
a=crypto:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
a=rtpmap:0 pcmu/8000

This parameter is used to secure the preceding media line. In other words this is what is used to do tls encryption.

Now the problem here is this, during the re-INVITE after unity sends its re-invite for the transfer, which includes the crypto parameter used to secure the dialog

+++re-INVITE from unity connection for transfer of call++

00248280.003 |08:44:32.151 |AppInfo  |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 10.135.191.13 on port 56005 index 1119 with 988 bytes:
[26534,NET]
INVITE sip:9014038012565@10.135.191.12:5061;transport=tls SIP/2.0
From: <sip:800@10.135.191.13>;tag=9ef70f0ed9e449f4b4d87fbc5c97222b
To: <sip:9014038012565@10.135.191.12>;tag=9566~dc062259-9b0a-4df2-b05d-e4de329c1980-33309488

---

v=0
o=CiscoSystemsUCXN 426435743 426435745 IN IP4 10.135.191.13
s=No Subject
c=IN IP4 0.0.0.0
t=0 0
m=audio 18126 RTP/SAVP 0 101
a=crypto:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
a=rtpmap:0 PCMU/8000

+++CUCM sends the re-INVITE to CUBE, however it included the crypto parameter++++

00248328.001 |08:44:32.156 |AppInfo  |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.0.1 on port 5061 index 1047
[26536,NET]
INVITE sip:4038012565@172.18.0.1:5061;transport=tls SIP/2.0
Via: SIP/2.0/TLS 10.135.191.12:5061;branch=z9hG4bKb1c77f74122
From: <sip:700@10.135.191.12>;tag=9565~dc062259-9b0a-4df2-b05d-e4de329c1980-33309485
To: <sip:4038012565@172.18.0.1>;tag=72554EC0-FC8
--

o=CiscoSystemsCCM-SIP 9565 2 IN IP4 10.135.191.12
s=SIP Call
c=IN IP4 0.0.0.0
b=TIAS:64000
b=AS:64
t=0 0
m=audio 18126 RTP/SAVP 0 101
a=crypto:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

What happens next provides the clue to why this is failing+++

CUBE immediately rejects the call, because in its INVITE to cucm, there is no crypto parameter offered to CUCM.

++CUBE sends a 488 media not acceptable++

00248334.002 |08:44:32.163 |AppInfo  |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 172.18.0.1 on port 5061 index 1047 with 438 bytes:
[26538,NET]
SIP/2.0 488 Not Acceptable Media
Via: SIP/2.0/TLS 10.135.191.12:5061;branch=z9hG4bKb1c77f74122
From: <sip:700@10.135.191.12>;tag=9565~dc062259-9b0a-4df2-b05d-e4de329c1980-33309485
To: <sip:4038012565@172.18.0.1>;tag=72554EC0-FC8
Date: Thu, 16 Oct 2014 14:44:30 GMT
Call-ID: C01DB2F3-547911E4-8C3DFE6A-66978997@172.18.0.1
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.2.4.M6a
Content-Length: 0

The TLS configuration is breaking things. The reason why this worked with MTP is because 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 agent. However UPDATE messages which does not include any SDP, is passed end to end.

So instead of a re-INVITE what we see is an UPDATE which  has no SDP.

08056570.001 |08:30:17.449 |AppInfo  |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.0.1 on port 5061 index 181
[907321,NET]
UPDATE sip:4038012565@172.18.0.1:5061;transport=tls SIP/2.0
Via: SIP/2.0/TLS 10.135.191.12:5061;branch=z9hG4bKd6325b6b3c57
From: <sip:700@10.135.191.12>;tag=316422~dc062259-9b0a-4df2-b05d-e4de329c1980-25208335
To: <sip:4038012565@172.18.0.1>;tag=6D21DB18-167E

Suggestions:

To test everything for now, please remove tls and just use tcp..

When we get this working, then we can figure out how to secure the connection end to end.

[Anthony Brandelli]

I have removed TLS from both the trunk facing CUC and the trunk facing CUBE. I have unchecked "MTP required" on the CUBE trunk and now calls are properly transferred. 

Would another round of traces at this point be wanted?

Thank you,

Anthony

[Ayodeji Okanlawon]

Do you still have issues with ring back? Do you get ring back on transfer now?

If not then yes we will need traces again from cucm

[Anthony Brandelli]

Still no ringback, attaching CUCM and CUC traces. Call time 3:07PM. 

Thanks,

Anthony

[Ayodeji Okanlawon]

To give you an update and understand where the call is failing now, I need to explain how call transfer works with sip...

1. CUCM sends invite (re-invite) with an inactive SDP (a=inactive) to indicate a break in media path

2. CUCM sends a Delayed offer to insert MOH/play ringback or to resume Media stream

NB: CUCM expects a sendrecv offer with SDP to the DO. (NB:if cucm gets an inactive offer SDP in the 200 OK instead of providing a send-recv offer SDP, the media path remains in an inactive state and causes calls to dropcall will drop),CUCM sends an ACK with sendonly to the 200 OK

3.CUCM establishes newcall leg with the intended transfered destination..Once this call is connected

4.CUCM receives a new Transfer instruction from the transferring phone to connect the held party

5. Next CUCM sends a re-invite with an inactive SDP to indicate a break in media path to MOH (in attempt to complete transfer)

6.Next CUCM sends an inactive SDP to indicate a break in media path between transfering party & transfered party to remove Xferring party from call

7. Next CUCM sends a DO re-invite to connect the transfered party. The far end then sends 200 OK with the required SDP to connect the call

The trace below is supposed to be point 2 above. This is where MOH/ringback should be played..but you can see that the attribute parameter=inactive instead of sendonly.

+++++++++++

00367449.001 |15:04:34.379 |AppInfo  |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.0.1 on port 5060 index 1633
[39200,NET]
ACK sip:270@172.18.0.1:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.135.191.12:5060;branch=z9hG4bK11483f8a9fea
From: <sip:700@10.135.191.12>;tag=14033~dc062259-9b0a-4df2-b05d-e4de329c1980-33309629
To: <sip:4038012565@172.18.0.1>;tag=73B148D4-21D9
Date: Thu, 16 Oct 2014 21:04:34 GMT
Call-ID: D99BCEA3-54AE11E4-8E27FE6A-66978997@172.18.0.1
User-Agent: Cisco-CUCM10.5
Max-Forwards: 70
CSeq: 103 ACK
Allow-Events: presence
Content-Type: application/sdp
Content-Length: 192

v=0
o=CiscoSystemsCCM-SIP 14033 4 IN IP4 10.135.191.12
s=SIP Call
c=IN IP4 10.135.191.12
t=0 0
m=audio 4000 RTP/AVP 0
a=X-cisco-media:umoh
a=ptime:20
a=rtpmap:0 PCMU/8000
a=inactive

+++comparing this to mine, you can see I have a=sendonly. my ann is 10.105.40.16++

c=IN IP4 10.105.40.16
t=0 0
m=audio 4000 RTP/AVP 18
a=X-cisco-media:umoh
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no
a=sendonly

Why this is happening I don't know. This could be a bug in the software..because this is not how it should work.

You can pass this to your TAC engineer and explain that this is where the call is failing..

Have you tested using MTP on the sip trunk now that you have sip integration. I am curios to know what happens..Ensure you reset the sip trunk once you have enabled require MTP

[Anthony Brandelli]

Really appreciate the detailed reply, I will pass this along to TAC. 

I tried requiring MTP on the trunk but still no ringback. 

Very bizarre, I don't know what else to even try at this point, but I appreciate the work put into this, so thank you again. 

If TAC is able to find the issue I'll post it here, otherwise I'm guessing there will be a bug opened on this. 

Anthony