SIP connection have no ring back for incoming calls

[rramlal]

Hi Guys,

I have a SIP connection to a ITSP and incoming and outgoing calls work fine however for the incoming calls I am getting no ring back.

The call flow is as follows:

PSTN-->SIP Line-->CUBE GW-->SIP Trunk-->CUC (AA prompt)-->dial an extension-->hear wait while i transfer your call-->extension rings but from the PSTN side no ring back is heard.

I have opened a case with Cisco and they have reviewing logs and can't seem to figure out why the ANN is not working.

The logs they provided are as follows:

Call flow: PSTN > SIP > GW > SIP > CUCM > CTI CFA VM > Auto Attendant > Dial Ext > Phone Rings but there is no ring back > Call is answered and there is 2 way audio without any problems.

Ringing from IP phone.

14565694.002 |14:48:14.994 |AppInfo  |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 192.168.8.35 on port 51189 index 2960 with 957 bytes:
[914751,NET]
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP 192.168.0.167:5060;branch=z9hG4bK970f4a83d1d8
From: <sip:+18683611756@192.168.0.167>;tag=314026~60db65cc-10e7-7296-2078-aecac853473e-31792203
To: <sip:2206@192.168.0.167>;tag=0c11672374b1da5378b28c04-1be8199c
Call-ID: 8fff080-84a1fc6e-8e6e-a700a8c0@192.168.0.167
Date: Fri, 09 Dec 2016 18:48:22 GMT
CSeq: 101 INVITE
Server: Cisco-CP8841/10.3.1
Contact: <sip:8b237013-41e8-d9d2-f679-3d555ff59df3@192.168.8.35:51189;transport=tcp>
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE,INFO
Remote-Party-ID: "2206" <sip:2206@192.168.0.167>;party=called;id-type=subscriber;privacy=off;screen=yes
Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-7.0.0,X-cisco-xsi-8.5.1
Allow-Events: kpml,dialog
Content-Length: 0

There is an ANN that is allocated to play the ring back tone back to the PSTN. As you can see in the section below CUCM is telling the GW to connect to 0.0.0.0 and a=inactive. This is why you are not hearing ring back.

14973229.001 |14:48:15.001 |AppInfo  |ARBTRY-ConnectionManager-wait_MediaConnectRequest(31792198,31792205)

14973377.001 |14:48:15.149 |AppInfo  |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 192.168.8.7:[5060]:
[857417,NET]
ACK sip:+18683611756@192.168.8.7:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.162:5060;branch=z9hG4bK7b2b308a781c
From: <sip:6500@192.168.0.162>;tag=296165~60db65cc-10e7-7296-2078-aecac853473e-31792198
To: <sip:+18683611756@192.168.8.7>;tag=B5B6560-1C78
Date: Fri, 09 Dec 2016 18:48:15 GMT
Call-ID: DA9ADF6E-BD7611E6-9D5BDB82-DDEACA22@192.168.8.7
User-Agent: Cisco-CUCM11.0
Max-Forwards: 70
CSeq: 103 ACK
Allow-Events: presence
Session-ID: 2b99b9444c0daa316c507a75aa314026;remote=65c3858d9c7460b9f2f53128ab296165
Content-Type: application/sdp
Content-Length: 223

v=0
o=CiscoSystemsCCM-SIP 296165 4 IN IP4 192.168.0.162
s=SIP Call
c=IN IP4 0.0.0.0
b=TIAS:64000
b=CT:64
b=AS:64
t=0 0
m=audio 19586 RTP/AVP 0
a=X-cisco-media:nomedia
a=ptime:10
a=rtpmap:0 PCMU/8000
a=inactive

Any ideas?

[Dennis Mink]

can you do a debug ccsip messages on your CUBE and simulate a call that has no ring back.  and add it to the post.

also, does the problem only occur when you call into the AA or when you call from PSTN into a phone, without the AA in the path?

cheers 

[rramlal]

Hi Dennis,

I have attached the debugs for both debug ccsip and debug ccapi.

I haven't tested the PSTN to phone, I will try that tomorrow and let you know the results. The strange thing is that I have an E1 also connected to the same GW using the same sip trunk and the ring back works.

[Dennis Mink]

can you tell me what number you dialed I see 6120279 and 6500 in two invites, what is what?

[rramlal]

6120279 is the pilot number and this is being translated to 6500 which is the AA extension.

[Dennis Mink]

Looks like your inbound call from your ITSP uses Early offer and your leg between cube and cucm uses delayed offer. Try to change your sip trunk to your cucm into EO as well.

maybe also use media flow through on your cube if not already doing so

[anchichov]

I had the same problem. We switched from PRI(MGCP) to SIP and get no ring back during transfer. I read many suggestions for trunk/cube but none of them helped me. I saw a recommendation about locale but did not want to install locale update without cisco support (I have 8.6 that is not supported anymore). Call manager has network locale Canada

I collected trace from Cisco call manager and Cisco IP Voice Media Streaming App in RTMT. Found the time when call transfer in the first trace and check that time range in Media Streaming. The result:

16:43:51.424 |-->CANNAudio::GetAnnouncement() 16:43:51.424 |-->CANNAudio::GetCodecString(4) 16:43:51.424 |<--CANNAudio::GetCodecString(4) 16:43:51.424 |   CANNAudio::GetAnnouncement() LocaleID(1) CountryID(6) AnnID(36) payload(.ulaw) 16:43:51.424 |   CANNAudio::GetAnnouncement() Ann(Alertingtone) AnnRingBack.wav(NW) AnnRingBack.wav(NW) 16:43:51.424 |-->CANNAudio::isFileExist(AnnRingBack.wav) 16:43:51.424 |   CANNAudio::isFileExist(AnnRingBack.wav) isUserLocale(F) UserLocale(1) nwLocale(6) isCustom(F) 16:43:51.424 |   CANNAudio::isFileExist(AnnRingBack.wav) *ERROR* Announcement network locale not found ID(6) 16:43:51.424 |<--CANNAudio::isFileExist(AnnRingBack.wav) 16:43:51.424 |   CANNAudio::GetAnnouncement() Ann file missing (AnnRingBack.wav) UserLocale(1) Country(6) 16:43:51.424 |   CANNAudio::GetAnnouncement() Ann(Alertingtone) File(/usr/local/cm/tftp/) 16:43:51.424 |<--CANNAudio::GetAnnouncement()

I checked TFTP and there are no files for Canada Location. Only files for United State.

I have a separate device pool for SIP trunk and changed network locale to United State (not <none>) and problem disappear.

[R0g22]

This is working as designed. Once CUC answers the call, a final response is sent towards the GW by CUCM over SIP. Once this is done, neither the CUCM nor the CUC will send a 180/183 once the call is transferred. This is just the way that SIP is. There are a couple of options -

1. Annunciator does a proxy ring back on the transfer
2. Use H.323 so that the ring back notification is done through a h225-notify natively.

What we are trying to accomplish here is not possible with SIP natively.

If annunciator is being invoked then ring back should be relayed taken the fact correct IP address is shared and the media status is not set to inactive, in that case sdl traces will need to be analyzed to see why the allocation does/does not happen either at all or correctly.