The called phone does ring if - Page 3

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
!

Ayodeji Okanlawon · ‎10-16-2014

I forgot to ask. Do you get ring back on the sip 8841 ip phone? Is it just the pstn user that doesn't get ring back?

Please rate all useful posts

Anthony Brandelli · ‎10-16-2014

The called phone does ring if that's what you mean? Otherwise if I call the CUC call handler DN from an 8841 internally I do get ringback after a transfer.

The PSTN user gets no ringback, everything else seems to behave as intended. Audio is two way when the call is connected, the called phones rings appropriately.

Gustavo Moreschi · ‎10-16-2014

after reading the amazing explanation from my friend Deji....

try to check this option below under your SIP Profile to CUBE: Require SDP Inactive Exchange for Mid-Call Media ChangeThis might change to sendonly...and hopefully it will get fixed.

Just make sure this option is unchecked "Send send-receive SDP in mid-call INVITE" because it will override the above option...

At least I have this setting and I was able to get the ringback to the PSTN for incoming calls working after I added the ANN into MRGL to CUBE...

I also would try to put the ANN into MRGL between CM and CUC, not sure if that will make any difference, but doesn't harm anything...

If still not working, I also would open a case at Telco in order to check it as well...

Anthony Brandelli · ‎10-16-2014

I gave this a shot, and unfortunately it still did not make a difference. I also tried adding an MRGL with an ANN to the trunk facing CUC, no dice.

I don't know if at this point its worth getting the ITSP involved, because from how I understand it CUCM is not sending what it should to make the ring back be played to the caller. CUCM needs to handle the ringback in this case, not the ITSP, I believe.

Really hoping I get some traction with TAC on this now, this is a bigger issue than one might expect because when there is just dear air during the transfer callers assume the call was dropped and hang up.

Thanks,

Anthony

Ayodeji Okanlawon · ‎10-17-2014

Anthony,

Can you do a test call with a sip phone dialling the call handler and xfer to another sip phone. Then send me the cucm (SDL) traces for that call. Lets look at how ring back is played in this scenario..

EDIT:

This not an ITSP issue. There are two ways you play ring back in SIP: 180/183. However you cannot send 180/183 for an established call, hence the need for an annunciator. It is cisco cucm who should play ring back through the annunciator.

Did you assign the ANN to the unity connection SIP trunk as well? is there a MRGL that has ANN for that sip trunk?

++A work around while this is on-going++

Within the call handler, under transfer rules, there is an option to check for "play the "wait while I transfer your call" prompt", that will give the callers something to listen to

Please rate all useful posts

Anthony Brandelli · ‎10-17-2014

Attached are traces from a test call at 5:46AM. Called the call handler from Ext. 270 and transferred to Ext. 259, ringback worked as expected in this case as mentioned.

I did assign an ANN to the CUC trunk as well, I had the same MRGL on both the CUBE and CUC trunk at the same time, still no ringback sadly.

Thanks,

Anthony

Gustavo Moreschi · ‎10-17-2014

When you did that test, did you uncheck the MTP on all Trunks? If I did not get lost, you have unchecked already the MTPs once you removed the TLS, right?

Not sure why you are using "disable-early-media 180" under sip-up in your CUBE...in this case I would tick this as well under your SIP Profile. If still not working remove both CUBE and SIP Profile...

I also would remove: midcall-signaling passthru in your CUBE and give it a shot...

Anthony Brandelli · ‎10-17-2014

Require MTP was unchecked on both trunks during the test, yes. I have left it like this since disabling TLS.

I have removed the two suggested params from CUBE, and as well on the CUCM side for the disable early on 180, ringback is still not present.

Thank you,

Anthony

Ayodeji Okanlawon · ‎10-17-2014

Sorry I am replying late..Been busy

This log does not contain any transfer to extension 259. All I see is a call from 270 to 800 and another call from 270 to 600..

Have you gotten any update from TAC?

Please rate all useful posts

Anthony Brandelli · ‎10-17-2014

No worries, I appreciate any and all help received so far.

I must have not picked the right timeframe in RTMT. Time of new call is 12:57PM, checked that the SDL logs actually have this... Sorry.

No update from TAC.

Ayodeji Okanlawon · ‎10-17-2014

I can confirm that the internal call does not use ANN to play ring back. There is no ANN involve in this call. So looks like the issue is with ANN/CUCM process..

I am not sure why TAC is taking forever to respond..escalate to P1 and you should get an engineer on the line..

Please rate all useful posts

Suresh Subramanian · ‎10-17-2014

I think I understand the impact and priority of the issue and hence It cannot be P1 Deji, as the calls are connecting successfully and issue lies on the ringback tone only.

Very interesting thread, but no CSC expert could resolve it. So something new to TAC as well. It needs to be escalated only when it misses the SLA.

//Suresh Please rate all the useful posts.

Suresh Subramanian · ‎10-17-2014

Escalating to P1 doesn't mean to get quicker resolution, customer has to understand cisco support like the way cisco understand their customers. Hope I'm not wrong. Cheers. Have a nice weekend to one and all.

//Suresh Please rate all the useful posts.

Ayodeji Okanlawon · ‎10-17-2014

This is service impacting and if it were me I would escalate this especially since I have had no update for over 2 days now. Infact I am almost tempted to open a case for Anthony and get an engineer right away!! Escalating means I will get someone to look at it right away..It shouldn't take 72hrs for cisco to respond

Please rate all useful posts

Suresh Subramanian · ‎10-17-2014

Wish you could have already done it on Anthony's behalf and let the CSC know the solution. I'd have rated with 5 stars. ;-)

//Suresh Please rate all the useful posts.

No Ringback from SIP Provider after Unity Transfer