CME SIP Trunk no ringback incoming pstn calls

[chevymannie]

I'm in the process of testing a sip trunk for a cutover and I've been having an issue with ringback.  When a user dials in from the PSTN, the IP Phone rings, but no ringback is heard by the PSTN caller.  If we dial outgoing to the PSTN, everything works fine.

[Ayodeji Okanlawon]

I think I can see something here..

This call goes to a hunt pilot and 3 numbers are selected..2001,2002,2003.

From the traces...only extension 2002, 2003 are responsding with ringback..From the traces call id 3334 and 3335 is assigned to this call to entension 2002 and 2003...and as you can see they both respond and alert is sent to PSTN.

++++Callid 3333 is the call leg to CCME++++

+++callid 3334 is calleg to extension 2002

+++callid 3335 is for extension 2003++++

+++callid 33332 is for inbound leg from PSTN+++

++here we see CCME sending alert t CCAPI++++

Interface=0x2BB023DC, Progress Indication=NULL(0)
010884: Jun  4 06:16:02.898: //33333/8137389D864F/CCAPI/cc_api_call_alert:
   Interface=0x2BAFDA18, Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)
010885: Jun  4 06:16:02.898: //33333/8137389D864F/CCAPI/cc_api_call_alert:
   Call Entry(Retry Count=0, Responsed=TRUE)
010886: Jun  4 06:16:02.898: //33334/8137389D864F/CCAPI/cc_api_call_alert:
   Interface=0x314C5668, Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)
010887: Jun  4 06:16:02.898: //33334/8137389D864F/CCAPI/cc_api_call_alert:
   Call Entry(Retry Count=0, Responsed=TRUE)
010888: Jun  4 06:16:02.898: //33335/8137389D864F/CCAPI/cc_api_call_alert:
   Interface=0x2BB023DC, Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)
010889: Jun  4 06:16:02.898: //33335/8137389D864F/CCAPI/cc_api_call_alert:
   Call Entry(Retry Count=0, Responsed=TRUE)

010890: Jun  4 06:16:02.898: //33332/8137389D864F/CCAPI/ccCallProceeding:
   Progress Indication=NULL(0)

+++Here we see CCAPI sending alert to the PSTN++++

010891: Jun  4 06:16:02.898: //33332/8137389D864F/CCAPI/ccCallAlert:
   Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)
010892: Jun  4 06:16:02.898: //33332/8137389D864F/CCAPI/ccCallAlert:
   Call Entry(Responsed=TRUE, Alert Sent=TRUE)

Does this work with a single extension if you call it directly rather than hunt pilot? can you try. Why is extension 2001 not responding?

Please rate useful posts

[chevymannie]

Yes that is a hunt pilot, but the ring back issue happens with any DID.  I tried directing it to a single extension with no luck.

[Ayodeji Okanlawon]

Ok can you send a debug ccsip messages...again lets see when ringing and 200 ok is occuring

Please rate useful posts

[Gregory Garrian]

I see this:

Jun  1 21:14:36.606: //21314/A038A84A97B6/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 180 Ringing

The 180 tells me that the ringback is out of band.  So your CUCME is telling your provider that the phone is ringing but your provider needs to generate the ringback.

You can either touch base with your provider or change your config to make the ringback inband, in which case you would see a 183 Ringing.

I'm looking into how to do that now. (Unless someone else corrects me first).

[chevymannie]

Thanks.  Please let me know if you find anything.  I'm looking at it right now also.

[chevymannie]

aokanlawon,

Here is the ccsip messages you requested.

013291: Jun  4 11:51:01.140: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:6019444813@10.1.8.200:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 208.149.73.5:5060;rport;branch=z9hG4bK-730b814200bbacb0ef864e4b3e373c5f-208.149.73.5-1
Allow-Events: message-summary, refer, dialog, line-seize, presence, call-info
Max-Forwards: 70
Call-ID: F92ABA32@208.149.73.5
From: <6012781848>;tag=208.149.73.5+1+417e1+9d7f7625;isup-oli=61
To: <6019444813>
CSeq: 439527053 INVITE
Expires: 180
Organization:
Supported: 100rel
Content-Length: 167
Content-Type: application/sdp
Contact: <6012781848>;isup-oli=61
P-Asserted-Identity: <6012781848>

v=0
o=- 3093099203 3093099203 IN IP4 208.149.73.12
s=-
c=IN IP4 208.149.73.12
t=0 0
m=audio 33356 RTP/AVP 2 0 101
a=rtpmap:101 telephone-event/8000
a=ptime:20

013292: Jun  4 11:51:01.152: //34962/4CB746519040/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 208.149.73.5:5060;rport;branch=z9hG4bK-730b814200bbacb0ef864e4b3e373c5f-208.149.73.5-1
From: <6012781848>;tag=208.149.73.5+1+417e1+9d7f7625;isup-oli=61
To: <6019444813>
Date: Mon, 04 Jun 2012 16:51:01 GMT
Call-ID: F92ABA32@208.149.73.5
CSeq: 439527053 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0

013293: Jun  4 11:51:01.152: //34962/4CB746519040/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 208.149.73.5:5060;rport;branch=z9hG4bK-730b814200bbacb0ef864e4b3e373c5f-208.149.73.5-1
From: <6012781848>;tag=208.149.73.5+1+417e1+9d7f7625;isup-oli=61
To: <6019444813>;tag=32CF7B60-15A0
Date: Mon, 04 Jun 2012 16:51:01 GMT
Call-ID: F92ABA32@208.149.73.5
CSeq: 439527053 INVITE
Require: 100rel
RSeq: 3520
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <6019444813>
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0

013294: Jun  4 11:51:01.204: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
PRACK sip:6019444813@10.1.8.200:5060 SIP/2.0
Via: SIP/2.0/UDP 208.149.73.5:5060;branch=z9hG4bK-a6f79b84c004283e6e13b22d435f1ee0-208.149.73.5-1
Allow-Events: message-summary, refer, dialog, line-seize, presence, call-info
Max-Forwards: 70
Call-ID: F92ABA32@208.149.73.5
From: <6012781848>;tag=208.149.73.5+1+417e1+9d7f7625;isup-oli=61
To: <6019444813>;tag=32CF7B60-15A0
CSeq: 439527054 PRACK
RAck: 3520 439527053 INVITE
Organization:
Supported: 100rel
Content-Length: 0

013295: Jun  4 11:51:01.204: //34962/4CB746519040/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 208.149.73.5:5060;branch=z9hG4bK-a6f79b84c004283e6e13b22d435f1ee0-208.149.73.5-1
From: <6012781848>;tag=208.149.73.5+1+417e1+9d7f7625;isup-oli=61
To: <6019444813>;tag=32CF7B60-15A0
Date: Mon, 04 Jun 2012 16:51:01 GMT
Call-ID: F92ABA32@208.149.73.5
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 439527054 PRACK
Content-Length: 0

013296: Jun  4 11:51:02.620: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
CANCEL sip:6019444813@10.1.8.200:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 208.149.73.5:5060;rport;branch=z9hG4bK-730b814200bbacb0ef864e4b3e373c5f-208.149.73.5-1
Allow-Events: message-summary, refer, dialog, line-seize, presence, call-info
Max-Forwards: 70
Call-ID: F92ABA32@208.149.73.5
From: <6012781848>;tag=208.149.73.5+1+417e1+9d7f7625;isup-oli=61
To: <6019444813>
CSeq: 439527053 CANCEL
Expires: 180
Organization:
Supported: 100rel
Content-Length:   0
Contact: <6012781848>;isup-oli=61
P-Asserted-Identity: <6012781848>

013297: Jun  4 11:51:02.624: //34962/4CB746519040/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 208.149.73.5:5060;rport;branch=z9hG4bK-730b814200bbacb0ef864e4b3e373c5f-208.149.73.5-1
From: <6012781848>;tag=208.149.73.5+1+417e1+9d7f7625;isup-oli=61
To: <6019444813>
Date: Mon, 04 Jun 2012 16:51:02 GMT
Call-ID: F92ABA32@208.149.73.5
CSeq: 439527053 CANCEL
Content-Length: 0

013298: Jun  4 11:51:02.624: //34962/4CB746519040/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 487 Request Cancelled
Via: SIP/2.0/UDP 208.149.73.5:5060;rport;branch=z9hG4bK-730b814200bbacb0ef864e4b3e373c5f-208.149.73.5-1
From: <6012781848>;tag=208.149.73.5+1+417e1+9d7f7625;isup-oli=61
To: <6019444813>;tag=32CF7B60-15A0
Date: Mon, 04 Jun 2012 16:51:02 GMT
Call-ID: F92ABA32@208.149.73.5
CSeq: 439527053 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Reason: Q.850;cause=16
Content-Length: 0

013299: Jun  4 11:51:02.672: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:6019444813@10.1.8.200:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 208.149.73.5:5060;rport;branch=z9hG4bK-730b814200bbacb0ef864e4b3e373c5f-208.149.73.5-1
Allow-Events: message-summary, refer, dialog, line-seize, presence, call-info
Max-Forwards: 70
Call-ID: F92ABA32@208.149.73.5
From: <6012781848>;tag=208.149.73.5+1+417e1+9d7f7625;isup-oli=61
To: <6019444813>;tag=32CF7B60-15A0
CSeq: 439527053    ACK
Expires: 180
Organization:
Supported: 100rel
Content-Length:   0
Contact: <6012781848>;isup-oli=61
P-Asserted-Identity: <6012781848>

[Ayodeji Okanlawon · Accepted solution]

After much investigation here is what I have concluded is going on..

First of all we need to understand how ringback is played with SIP..

1. if a 180 (Ringing) has been received but there are no incoming
         media packets (i.e 180 without SDP), generate local ringing.

2. If  "183 Session Progress" with SDP is received it will then expect to receive the

ringback tone as RTP packets from the remote server, and generates no ringback tone.

So in your scenario, 180 ringing without SDP is sent to your provider, this implies that according to RFC 3960 your provider should generate its own local ringback. But this is not happening..

Now what I think is going on is this, your provider wants SDP in your 180 ringing so that ringback is heard from your end or they want you to send a 183 with SDP. This is also acceptable in RFC 3960.

So this is not a CCME problem like I have said before and the traces show.

You need to speak with your provider to know why they are not generating their own ringback. Or you need to find away to send 180 with SDP to your provider as this is what they can accept.. I am not sure I know how to configure CCME to send 180 with SDP or send 183 with SDP..You can ask on the forum..but I strongly suggest yo speak with your ITSP first.

Can you confirm on the outbound call if your provider sends 180 with SDP or 183 or just 180...

Please rate useful posts

"I am complete in God, God completes me"

[wayne]

I am having a similar problem. Here is the wierd part. I can call from my cell phone and the phones ring and I hear ring back on my end, however, if I call from my house phone there is dead air and then it goes to a busy signal and sometimes disconnect. I am having alot of people complain of not hearing the phone ring when they call this clients number but the phone rings at the clients office.

[etmarcof]

Hi Wayne,

I am having a similar problem. Have you maneged to solve your problem?

Thanks

Best Regards

Mc

[UC Guy]

Hi MC,

yes, the UC box was not generating ringtone. The SIP provider had to make a change on their end so it would send the ring tone. I wish I could tell you what exactly they did, but looking back at the logs, I didn't enter the resolution for this. IF I find it, I will let you know.

[saifuddin.miyaji]

Hi,

I have seen several posts on the related subject. My question is very simple, can we force Cisco IOS to send 180 Ringing with SDP? or can we force it to send 183 instead.

Scenario: We have C3825 RTR with latest IOS. It terminates the ISDN E1s and has SIP trunk towards CUCM. The traces show that the GW send 180 without SDP and hence CUCM provides local ring back. This is undesirable in our scenario because we would like to playback the early media.

Please advise.

[Jay Schulze]

Hello Saifuddin,

Unless I'm not understanding. It should be enabled by default. If you do a show sip-ua status. You have this line?

SIP early-media for 180 responses with SDP: ENABLED

[Ayodeji Okanlawon]

As far as I know Cisco gateways do not send 180 with SDP. What they do is send 183 with SDP. To play early media such as announcement on the ISDN circuit, you will need to enable PRACK between gateway and CUCM. This will enable the gateway cut through audio on session progress....

[saifuddin.miyaji]

Yes aok, you are correct. 180 with SDP in SIP-UA is applicable to incoming calls only. The traces clearly show that GW sends 180 Ringing wihtout SDP.

Could you pls tell me how to enable PRACK in GW and CUCM or share some documents that talk about it?

Saif

[saifuddin.miyaji]

Thanks

Its resolved by enabling the PRACK in the SIP Profile.

Saif