UC540 - No Ringing Tone or AA on Incoming Calls

[tobyweston]

Hi,

We have recently set up a UC540 over SIPs. Incoming and outgoing calls are working fine at the moment, the problem lies when a call comes in from an external number.

If the UC540 is called from an external number then the phones will ring fine if it is set to ring a phone(s) on an incoming call but the caller will not actually hear any ringing on their end. Once it gets to the VM period the call will then terminate.

The same appears to happen when the external caller phones in and AA is active on incoming. They hear dead noise and then the call terminates about 20 seconds later.

If this is all done internally it works fine, you can dial the AA and hear it fine, or dial the VM or get directed to a VM no problems. Its only when someone rings in.

I have attached the running config.

Any help would be appreciated.

[Darren DeCroock]

Hello Toby,

I don't see anything in you config that is jumping out..  I do see that you are in the UK.  Does you SIP provider use G711ulaw, or G711alaw?  Not sure exactly why regular calls would work if they are using G711alaw, since it is not configure on the UC500, and neither is transcoding.  Either way, we probably need more information to figure out what is going on here.  Can you get a debug of an incoming call that is going to the AA?

debug voice ccapi inout

debug ccsip messages

Thank you,

Darren

[tobyweston]

Hi,

Thanks for getting back to me.

I have attached the logs for you to see.

I have noticed that if i set it up so that an extention rings after no answer in the AA then it will ring for a split second on the phone. Although the caller will still hear no AA or ringing tone their end.

[Darren DeCroock]

I reviewed the debugs, and it looks like you are getting a "500 Internal Server Error".  This normally means that the ACL applied to the external SIP call is not allowing the call though.  But you ACL looks to be correct.  Two things I would try: 

1.  As a test, removed the ACL for the incoming SIP call.

     conf t

       voice source-group CCA_SIP_SOURCE_GROUP_EXTERNAL

         no access-list 2    (If this has no effect, I would add this line back, to prevent toll-fraud)

2.  Manually configure the Codec used for the incoming call.  The incoming call on your debug is hitting Dial-Peer 3000, but there is no Dial-Peer 3000 in the running config.  I would try modifying that dial-peer, and remove the "voice-class codec 1", and add "codec g711ulaw".

Thank you,

Darren

[tobyweston]

Hi Darren,

Thanks for the reply.

I have tried those two things and the results are still the same unfortunatly.

I have attached an updated running config, the original one that was posted may of not included the AA setup. It had a DID to a extension, although the problem was similar as there was no ringing tone when calling in.

The current running config does have Dial-Peer 3000 in and i notice the following lines when showing the dial-peer through CLI:

Last Disconnect Cause is "66  ",

Last Disconnect Text is "recovery on timer expiry (102)",

Not sure if they are able to offer any clues. I cant seem to see anything related to these errors around the interwebs.

[ADAM CRISP]

Toby.

There's something odd going on here. I'm sure it's not your Cisco. It's sending the 180 ringing ok, would expect the network to generage  ringback IF it's receiving the message.

Is there a network device in between your UC and the Internet which could be filtering packets ?

You could try firing up xlite on your PC to see if this behaves in a similar manner.

Adam

[tobyweston]

Hi Adam,

Thanks for the input.

We currently have a Netgear DG834 sitting between the UC and the net. The UC has an external IP on the WAN port and the netgear is setup as a modem with NAT disabled. I have played around with the SIP ALG settings too to see if that makes any difference.

Not sure if there are any known problems with this router as I know they can be a pain sometimes.

Will give the xlite thing ago in the meantime.

[tobyweston]

Hi,

Just an update.

Tried xlite while connected to the same netgear as the UC is and it works fine, incoming calls ring as normal and sound is transmitted.

[ADAM CRISP]

Hi Toby,

Please can you post the output of debug ccsip messages fora fresh incoming call - I'm interested in the lack of ringback.

thanks

Adam

[tobyweston]

Hi Adam,

Please see the attached file of the debug logs.

[ADAM CRISP]

Toby,

This is just broken at the moment.

The 500's are are generated because you have a voice source group, but don't have the IP address of the ITSP within access list

Adam

[tobyweston]

Hi Adam,

Sorry you are right, i missed an IP. I added it to the access list and re run the call to get a new debug log.

[ADAM CRISP]

Hi Toby,

1. The missing "ring ring" tone not heard by the caller.

The Cisco is sending this to the network:

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP 87.127.215.242:5060;branch=z9hG4bK0d092f9f;rport

From: "************" <>;tag=as4da6485b

To: <>;tag=1931E40C-FFFFDB86

Date: Mon, 05 Sep 2011 11:43:44 GMT

Call-ID: 0a7bf831343dbfdc15ed1a217f593995@87.127.215.242:5060

CSeq: 102 INVITE

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

Allow-Events: telephone-event

Contact: <398>

Server: Cisco-SIPGateway/IOS-12.x

Content-Length: 0

So this means the network should be generating ringback.

If you're not hearing this, it's because the 180 is NOT being processed by the Service Provider OR the SP isn't receiving it.

2. The 200 OK from the Cisco to the Network is NOT ACKed, which is why it's re-trasmitted. The call will stop working after typically 32 seconds.

The missing ACK could be caused by a problem with the SP, or again the SP is not receivcing the 200 OK.

Note the ACK should be sent to your contact address in the 200, which we can't see because you've masked it out. You might want to double check you WAN access list.

What is odd about all of this, is Xlite is OK.

Adam

[tobyweston]

Thanks for the reply Adam,

The contact address is the correct sips number / IP / port.

I have passed some of this information on to the SP to see if they can make use of any of it to troubleshoot the issue.

I double checked the WAN access list again and it all appears to match the IPs given by the SP.

Hopefully will have an update shortly.

Thanks

[tobyweston]

Hi,

Response from the SP is

"I have just been in with the VoIP team and they have tested this by temporarily diverting the IP that our systems send the calls to and trying it on a test PBX.

The test PBX has a sound that is played when a call is connected into it and this test worked therefore the only thing that can be causing the issues you are experiencing must be the Cisco device configuration."

Doesn't look like they will be helping much.

Stuck on ideas my self.