Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

No Ringback from SIP Provider after Unity Transfer

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
!

 

Everyone's tags (4)
98 REPLIES
New Member

Tried enabling rel1xx on both

Tried enabling rel1xx on both CUBE and CUCM to always send PRACKs, didn't help. 

Also tried disabling early media on 180, also did not help. 

I found a lot of other threads referencing similar problems, but most seem to have had H323 somewhere in the mix, which I do not. 

Any help is appreciated, I'll keep digging as well. 

 Hi.Can you please try to add

 

Hi.

Can you please try to add what follows

Under voice service voip 

no supplementary service sip moved-temporarily 

no supplementary service refer

Try these two commands and let me know 

Thanks 

Regards 

Carlo 

Please rate all helpful posts "The more you help the more you learn"
New Member

Hi Carlo,After playing with

Hi Carlo,

After playing with this I gave up and opened a case with TAC, currently waiting for them to provide a fix or more insight. 

I really couldn't find what the issue was...

Thanks,

Anthony

New Member

To be specific as I should

To be specific as I should have been in the first place I did try these commands and they had no effect seemingly. 

Hi.Just to give a try, can

Hi.

Just to give a try, can you please change the transfer type on UC call handler from "Supervise Transfer" to "Release Switch" and see if it makes differences..

Please after this change post a debug ccsip message from your CUBE

 

Thanks

 

Regards

 

 

Carlo

 

Please rate all helpful posts "The more you help the more you learn"
New Member

Hi Carlo,CUC is already set

Hi Carlo,

CUC is already set to release to switch mode:

I can't even seem to set this to a supervised transfer, unless I am looking in the wrong place?

http://i.imgur.com/9XJV4mz.png

Thank you,

Anthony

Hi Anthony.From your

Hi Anthony.

From your screenshot you are looking in a wrong place.

You should first look at call handler with original called number than as transfer rule you should find the destination internal number.

There you should find the option switch release.

If you want you can post a screenshot of current configuration.

Let me know 

Regards

Carlo

Please rate all helpful posts "The more you help the more you learn"
New Member

Hi Carlo,I don't quite

Hi Carlo,

I don't quite understand where I should be looking, I'm not as familiar with CUC as I would like to be. 

The only transfer rule that is enabled in the call handler is "standard" which is the page I screenshotted earlier. 

I see that I can change the transfer type in the caller input screen if a caller presses a key, right now this is all set to release to switch. 

Thanks,

Anthony

New Member

In my case, I was able to fix

In my case, I was able to fix it yesterday night adding the ANN into the MRGL between CM and CUBE.

It looks like is necessary to reconnect the audio stream to the ANN to emulate a ringback tone...

I hope it helps you...

New Member

You would be correct here,

You would be correct here, CUCM should be providing the ringback through the use of an announciator, but for some reason it's not... The MRGL has an announciator in it, and the announciator shows as registered. 

It's really strange. 

Glad to hear you fixed your issue though :)

New Member

I would reset all the ANNs,

I would reset all the ANNs, and do not forget to reset the Trunk as well...since it is simple and it will not hurt even we know is showing as registered...I would give it a try...

Another possibility would be to change from SCCP to SIP between your CM and CUC because this is the only difference from your scenario to mine...not sure if it might be a bug, but in my case using all the way SIP, adding ANN has fixed it.

 

New Member

I did try resetting the ANNs

I did try resetting the ANNs and trunks earlier in the troubleshooting process and it didn't seem to make a difference. 

I have toyed with the idea of moving to SIP integration from CUC to CUCM, I don't think it's a laborious process, just been putting it off in hopes that this would be fixed.

VIP Super Bronze

I have looked in detail at

I have looked in detail at your logs and here is what I observed..

+++CUCM indeed selected an annunciator for the call+++

08056608.001 |08:30:17.452 |AppInfo  |AnnDControl::waiting_PolicyAndCACRegisterRes - Device Name = ANN_2, Ann CI = 25208342, RSVP Success
08056608.002 |08:30:17.452 |AppInfo  |AnnDControl::handleAnnSuccess Annunciator successfully allocated for CI= 25208344

8056614.001 |08:30:17.453 |AppInfo  |ARBTRY-ConnectionManager-wait_MediaConnectRequest(25208335,25208344)

 

+++However something strange happened here. When cucm told announciator to start playing announcement (ringback in this case), the remote ip address was to itself++++

This is the OLCAck. Note that the port number is different and ip is the same++

08056668.001 |08:30:17.457 |AppInfo  |AnnDControl(ANN_2) - star_StationOpenReceiveChannelAck - Received from ANN Device Status=0, PartyId=16778504, IP=213878538, Port=27948
08056676.002 |08:30:17.457 |AppInfo  |DET-AgenaInterfaceBase-(474)::setDeviceOLCAckInfo, lcn=1, ip=10.135.191.12, port=27950
 

++here we see where ANN is sending its announcement to, same ip but different port number+++

08056679.001 |08:30:17.457 |AppInfo  |AnnDControl::star_MediaExchangeStartTalking StartAnnoucement locale =1 AnnID=36= playMode=2 endAnnAck=0
08056680.000 |08:30:17.457 |SdlSig   |MediaPartyConnectInfoInd               |interfacesEstablished          |MediaExchange(1,100,145,636)     |AgenaInterface(1,100,244,326)    |1,100,14,140069.19268^10.135.191.12^MTP_2 |[R:N-H:0,N:2,L:0,V:0,Z:0,D:0]  CI =25208344 EXPECT_CONNECTINFO_FROM_ALL_HOPS Unspecified MediaSecurity=F MMCap=0x1 Aud Info[ RecvRtpTa= ipAddrType=0 ipv4=10.135.191.12:27948 ActiveLineStackIdx=0 Codec=4 64 Kbps 20 Msec V4] No Main Video No Sec video
08056681.000 |08:30:17.457 |SdlSig   |StationOutputStartMediaTransmission    |waiting                        |AnnDControl(1,100,242,6)         |AnnDControl(1,100,242,6)         |1,100,14,140069.19268^10.135.191.12^MTP_2 |[R:N-H:0,N:2,L:0,V:0,Z:0,D:0] ConfId=25208344 remoteIpAddr=.type=0 .addr=0x{a,87,bf,c,0,0,0,0,0,0,0,0,0,0,0,0}(10.135.191.12) Port=27950 PacketSize=20 PayloadType=4 CI=25208344 DiffServ=0xb8 (DSCP=0x2e) Silent=0 MaxFrms=0 G723BitRate=0 PartyId=0x1000508 RFC2833PayloadType=0 mixingMode=0 partyDir=0
08056681.001 |08:30:17.457 |AppInfo  |AnnDControl - stationOutputStartMediaTransmission TCPPid = [1.100.14.140071] myIP: cbf870a (10.135.191.12)
08056681.002 |08:30:17.457 |AppInfo  |AnnDControl - RemoteIpAddr: cbf870a (10.135.191.12) RemoteRtpPortNumber: 27950 msecPacketSize: 20 compressionType: 4
08056682.000 |08:30:17.457 |SdlSig   |StationStartAnnouncement               |waiting                        |AnnDControl(1,100,242,6)         |AnnDControl(1,100,242,6)         |1,100,14,140069.19268^10.135.191.12^MTP_2 |[R:N-H:0,N:1,L:0,V:0,Z:0,D:0]  ConferenceId=25208344 Locale =1 Country =6 AnnId =36 AnnAckReq=0 AnnPlayMode=2 HearingMask=0
08056682.001 |08:30:17.457 |AppInfo  |AnnDControl - star_StationOutputStationStartAnnouncement ConferenceID: 25208344, TCPPid = [1.100.14.140071] myIP: cbf870a (10.135.191.12)

 

To confirm this, I contrasted this with my working solution and here is what I see, observe that remote ip and port number is different from myip and port number++++

In an ideal scenario like this one below the remote ip should be pointing to the gateway like mine is.

62753747.001 |16:32:58.443 |AppInfo  |AnnDControl - stationOutputStartMediaTransmission TCPPid = [28.100.13.419] myIP: 1028690a (10.105.40.16)
62753747.002 |16:32:58.443 |AppInfo  |AnnDControl - RemoteIpAddr: 4a28690a (10.105.40.74) RemoteRtpPortNumber: 25540 msecPacketSize: 20 compressionType: 11
62753748.000 |16:32:58.443 |SdlSig   |StationStartAnnouncement               |waiting                        |AnnDControl(28,100,232,1)        |AnnDControl(28,100,232,1)        |28,100,13,99714.20012^10.105.40.74^*     |[R:N-H:0,N:3,L:0,V:0,Z:0,D:0]  ConferenceId=485031105 Locale =33 Country =63 AnnId =36 AnnAckReq=0 AnnPlayMode=2 HearingMask=0
62753748.001 |16:32:58.443 |AppInfo  |AnnDControl - star_StationOutputStationStartAnnouncement ConferenceID: 485031105, TCPPid = [28.100.13.419] myIP: 1028690a (10.105.40.16)

 

So here are my suggestions:

1. Restart CUCM service

2. Restart IPVDMS service

3. You can try using sip for integration  but if this behaviour continues, then it wont make any difference

 

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

Thanks for the suggestions. I

Thanks for the suggestions. I restarted the two mentioned services but no difference was observed in behaviour. 

At least I have a better idea of what's going on with this. In your opinion does this look like a bug? Or is it still possible I've managed to misconfigure something?

Thanks,

Anthony

Hi Anthony.Please let me know

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

Please rate all helpful posts "The more you help the more you learn"
New Member

CUCM 10.5.1.10000-7CUC

CUCM 10.5.1.10000-7

CUC Version 10.5.1.10000-7

IOS Version 15.2(4)M6a

Thanks,

Anthony

New Member

What as your final resolution

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.

~~~ Rate helpful posts Blog - http://tripplehelix.net
New Member

This turned out to be a bunch

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

New Member

My issue was with the Media

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.

VIP Super Bronze

One thing I observed which I

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..

 

 

 

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

Changing to a SIP integration

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

VIP Super Bronze

Can you confirm that your sip

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

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

The SIP security profile does

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. 

VIP Super Bronze

The issue you are having is

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.

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

I have removed TLS from both

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

VIP Super Bronze

Do you still have issues with

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

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

Still no ringback, attaching

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

Thanks,

Anthony

VIP Super Bronze

To give you an update and

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

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

Really appreciate the

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

5270
Views
100
Helpful
98
Replies