SIP TO SIP CALLS UC540

[GARY GRAY]

We have two clients both using the UC540 with nexVortex SIP Trunking and they are unable to call each other but can make and receive calls to anyone or anywhere else with any issues. Does anyone have any idea's on where the problem is. We have been on the phone with Cisco SMB support and nexVortex support for hours trying to debug this issue with no luck.

Thank you for any ideas!

[David Trad]

Hi Gary,

Are the two clients the same entity?

Are the two clients on the same Internet access I.E shared offices?

Are the two clients calling each other with the SIP number from the ITSP or the DID number provided by the ITSP?

If the latter then there is a good chance the ITSP may not be routing the calls properly, this happens often and sometimes can be easily resolved by the ITSP. Have you done some debugging and see what it is coming up on the system?

If you can give us an idea of the landscape so I can see how the calls are supposed to be routing between each other, then I can possibly offer more suggestions.

A network diagram maybe?

Cheers,

David.

[GARY GRAY]

Hi David,

Not the same entity....

Not the same ISP....

Not the same SIP number...

We did debug and found the calls are being routed to the IP address and ringing busy upon termination. All the other calls are working fine. The debug shows the call leaving and being routed to the destination just fine. (see attached)

Thank you for your time.

Gary

[David Trad]

Hi Gary,

Thanks for posting that document.

First of all, please give me some time to go over it as it contains the debug info required thanks for that

Secondly, please take the document down and remove the SIP/DID number and other sensitive stuff and then repost it for others to possibly assist, it is just a precaution thing from my perspective, whilst I would like to say everyone on the Cisco forums could be trusted the simple fact is we don't know most of them and thus should never take risks

There is one thing that has stuck out straight away:

"SIP/2.0 500 Internal Server Error"

Reason: Q.850;cause=63

I would like to investigate this further...

This is what that error means:

503 Service unavailable

63

Service or option unavailable

Will get back to you soon after I have a good look at it.

Cheers,

David.

[GARY GRAY]

K

[David Trad]

Hi Gary,

What I see is two separate errors showing up, you have the Internal Server Error "500" with a cause code of 63 and then you have a Cause code 41 being generated directly after, which is a temporary failure but still within the 500 range of errors.

Without looking at your configuration and also how the network is configured I.E edge router (WAN) and how the sip-ua config is setup by CCA I can only advise of the following.

• If there is a WAN router you may possible need to do port forwarding on it, but since the ITSP says the calls are not even hitting their network this may not be the problem, but still would be good to do for testing purposes.
• If the system is configured with CCA it would be wise to see what ACL config it has applied, there could be a possibility that the system is locked down to excessively which does happen with CCA generated SIP-UA configurations, it is done for toll fraud reasons and is understandable. Two methods to test this theory out is to remove the firewall altogether and test it, one way is to use CCA and the other is to do it via CLI making sure you do a full and complete backup of the running configuration prior to doing it, if this yields a positive result then we have a foundation to work from
• Finally if you can, possibly provide the configuration of the CME in txt file format, this will allow all the friendly folk on here to put forward their opinions and see if there is any problems sticking out that are related to the configuration, we need to know or see the following:
  
  - Translation rules applied
  - How the SIP-UA is configured
  - How the Dial-Peers are configured
  - How the DN is configured that maintains the SIP registration (If used?)
  - Possibly a "show sip reg stat" command done on the CLI to show us the registered status

This will suffice for now, I am certain some of the other professional folk will join in on this, although I am surprised that SMB support was not able to come to a conclusion, this means there is no definitive indication as to wether the problems solely exists on the UC-540 or if it is a combination of the ITSP configuration at the SBC and the UC-540 SIP implementation or if it is completely an ITSP configuration issue, it would be good to have some indication on this.

Cheers,

David.

[bwilliams24]

Gary,

I ran into this issue myself with customers that have the UC540 and nexVortex as their ISP.  If you go into CLI and remove the following commands the system will work without issue.

config t

no voice source-group CCA_SIP_SOURCE_GROUP_CUE_CME

no voice source-group CCA_SIP_SOURCE_GROUP_EXTERNAL

Hope this helps.

Barbara