I have looked in detail at

Anthony Brandelli · ‎09-18-2014

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
!

Anthony Brandelli · ‎09-21-2014

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.

Carlo Poggiarelli · ‎09-21-2014

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"

Anthony Brandelli · ‎10-14-2014

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

Anthony Brandelli · ‎10-14-2014

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

Carlo Poggiarelli · ‎10-15-2014

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"

Anthony Brandelli · ‎10-15-2014

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

Carlo Poggiarelli · ‎10-15-2014

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"

Anthony Brandelli · ‎10-15-2014

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

Gustavo Moreschi · ‎10-15-2014

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

Anthony Brandelli · ‎10-15-2014

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 :)

Gustavo Moreschi · ‎10-15-2014

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.

Anthony Brandelli · ‎10-15-2014

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.

Ayodeji Okanlawon · ‎10-15-2014

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

Anthony Brandelli · ‎10-15-2014

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

No Ringback from SIP Provider after Unity Transfer