Help! SIP Trunk with new EA Support Pack

Answered Question

I just thought I would check here, are there any known issues with SIP in the new EA pack? I have installed it on the new system, and am having the following issues:


Outbound calls work for a period of 10 minutes or so after rebooting our DSL modem. After that, calls fail. After working with the trunk provider, it looks like our source ports are getting changed. The source port of the invite messages is very high when it is working, then when it stops working our invite messages are coming from a 5090-5092 port. The provider responds on that port, but it looks like we arent listening on it, so we do not get the replys. I have opened up our ACL to any UDP traffic from the provider, no change. I think the system is just not listening on the same port as the invites are going out on. Could be the DSL modem changing the ports, see my note about the modem below.


Inbound calls have never worked, failing with a 500 - internal server error coming from our UC520. Neither the sip provider or cisco TAC knows why this is happening so far.


I have had two TAC engineers working on it for about an hour each, they couldnt give me an answer. They didnt even see the port issue that the sip provider did.


I have not ruled out the DSL modem. it is a Motorola 3347, which looks like a newer version of the Netopia 3347. I have another voice install with the netopia modem working fine. It may have something to do with this motorola modem. I have disabled it's firewall, and also had to add our public ips to its statefull inspection 'exposed IPs' section just to be able to open inbound ports. I have never had to do this with a netopia router before.


Anyone have any idea?

Correct Answer by Maulik Shah about 7 years 10 months ago

So all this was via CLI - as I think the CCA config pushed down is different. If so - you want to add incoming SIP Trunk dial peers for the individual DID - example is below:


dial-peer voice 10000 voip
description ** Incoming call from SIP trunk (Generic SIP Trunk Provider) for DID 14085551000 **
voice-class codec 1
voice-class sip dtmf-relay force rtp-nte
session protocol sipv2
session target sip-server
incoming called-number 14085551000
dtmf-relay rtp-nte
ip qos dscp cs5 media
ip qos dscp cs4 signaling
no vad


Repeat for every DID (change the dial peer tag)

Correct Answer by Maulik Shah about 7 years 10 months ago

For starters,

- Can you provide the TAC case numbers

- Also the version, config and logs for any of the above failed cases (inbound or outbound) would also be useful


It appears from your description that as the SIP INVITEs from the UC520 use ephemeral or random source ports (anything from 1024 to 65535) the NAT router is not able to keep the pin holes active and things start failing. There is an option in CLI to force the source port on the UC520 to always be the listening port i.e. UDP 5060. Check section 4.4.12 on the below doc:


https://www.myciscocommunity.com/servlet/JiveServlet/previewBody/1560-102-1-1933/UC500-SIPTrunking-Wiki-062008.pdf


If the provider requires that SIP traffic always be sourced from the UC520 using TCP or
UDP port 5060, this can be changed at a system level as below:


sip-ua
connection-reuse


This may help with outbound - inbound I would need to check the logs.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Correct Answer
Maulik Shah Wed, 06/03/2009 - 09:15
User Badges:
  • Silver, 250 points or more

For starters,

- Can you provide the TAC case numbers

- Also the version, config and logs for any of the above failed cases (inbound or outbound) would also be useful


It appears from your description that as the SIP INVITEs from the UC520 use ephemeral or random source ports (anything from 1024 to 65535) the NAT router is not able to keep the pin holes active and things start failing. There is an option in CLI to force the source port on the UC520 to always be the listening port i.e. UDP 5060. Check section 4.4.12 on the below doc:


https://www.myciscocommunity.com/servlet/JiveServlet/previewBody/1560-102-1-1933/UC500-SIPTrunking-Wiki-062008.pdf


If the provider requires that SIP traffic always be sourced from the UC520 using TCP or
UDP port 5060, this can be changed at a system level as below:


sip-ua
connection-reuse


This may help with outbound - inbound I would need to check the logs.

Maulik Shah Wed, 06/03/2009 - 11:44
User Badges:
  • Silver, 250 points or more

Did the outbound calls work even after 10 mins by adding the CLI above?


For inbound calls, I think your SP is sending SIP messages from an IP address that is different from the proxy server you entered. Here is what you can do to mitigate this via CLI for now:


On the SIP INVITE look at the Contact or From header:


From: 100.1.1.1>;tag=SDhmg7001-gK0558eb81
....
Contact: 100.1.1.1:5060;transport=udp>


Look at the IP address after the @ sign (in red) - you need to add this to the access-list 1 (this was added to ensure only specific IP addresses can send SIP messages to the UC520)


no access-list 1

access-list 1 permit 10.1.10.1
access-list 1 remark CCA_SIP_SOURCE_GROUP_ACL
access-list 1 remark SDM_ACL Category=1
access-list 1 permit 100.1.1.1 <<<< ADD ANY OTHER IP ADDRESSES SUCH AS PROXY SERVER BEFORE DENY STATEMENT
access-list 1 deny   any

Yes, they are sending the voice calls from another IP address, i noticed that this morning.


Just added that to acl 1, no change. There are no hits on ACL 1, i do not think it is applied anywhere? where should it be applied?


Outbound calls appear to be fine now. have been working all morning.


I just put the DSL modem in bridge mode and setup PPPoE on the UC520. Everything looks good, still no incoming calls. so we can rule out the DSL modem as the issue i think.

Maulik Shah Wed, 06/03/2009 - 12:44
User Badges:
  • Silver, 250 points or more

You may not see hits against the access-list - is the debug output exactly the same (can you send me your updated config / debug for a failed call)?


Removing the voice source group is not a good idea so make sure you add that back in and keep the access-list 1 with all the relevant IP addresses in there.

Maulik Shah Wed, 06/03/2009 - 13:03
User Badges:
  • Silver, 250 points or more

The call does go further - see a new issue though. The provider is sending calls to you with a DID of 1 + 10 digits:


Received:
INVITE sip:14085550459@1.1.1.1 SIP/2.0


I do not think your DID defined via CCA includes the 1 - hence the call fails. Can you confirm the exact DID that is sent from the SP (whether it includes the 1 or not) and change the mappings on CCA for DID to extension mapping?

That should be fine, i updated their call routing to include the 1, and included it on my end. I did this because i have another customer with a similar setup, and wanted everything to be as similar as possible.


I have the DID numbers setup as a secondary number on a shared DN that the call should ring into. you should see it in the new configs i sent you. I updated to include a 1 there.

Correct Answer
Maulik Shah Wed, 06/03/2009 - 13:27
User Badges:
  • Silver, 250 points or more

So all this was via CLI - as I think the CCA config pushed down is different. If so - you want to add incoming SIP Trunk dial peers for the individual DID - example is below:


dial-peer voice 10000 voip
description ** Incoming call from SIP trunk (Generic SIP Trunk Provider) for DID 14085551000 **
voice-class codec 1
voice-class sip dtmf-relay force rtp-nte
session protocol sipv2
session target sip-server
incoming called-number 14085551000
dtmf-relay rtp-nte
ip qos dscp cs5 media
ip qos dscp cs4 signaling
no vad


Repeat for every DID (change the dial peer tag)

I've had this problem before; due to the nature of UDP it's stateless; after the initial conversation (from UC520 to SIP provider) everything works fine. Then when this connection goes down, or another call is initialted the provider "calls you" in another conversation and it fails. Ask your provider if they can do a "keepalive" each calls this something different, so when you call them (initially) the keep alives will hold this line up and use it for all calls.


This happens a lot on firewalls with more that one IP address on the public side.


There are a couple of another scenerios that can help this but the above mentioned one is the quickest and the best unless they will not provide you with this. Please post your results.


Bob

Finally fixed it. Everything is working now.


The outbound call issues must have been a combination issues, number one being that the DSL modem (a new Motorola 3347) was doing statefull packet inspection on our public IPs. Disabled inspection, then ended up setting it to bridge mode anyway to take it completely out of the picture. the 'connection-reuse' command may have helped as well, especially if we kept the DSL modem running it's inspection.


the inbound call issue turned out to be one simple command. Under our incoming dial peer, CCA had put a command 'permission term' which apparently sets the dialpeer to be restricted to only being a terminating peer. I do not know why, but removing this command fixed the issue and the incoming calls to it now work fine. Discovered this by letting CCA create some new DID dialpeers, and it did not use the permission term command. it only used it on the default dial peer. No idea why.

Maulik Shah Wed, 06/03/2009 - 14:38
User Badges:
  • Silver, 250 points or more

Glad to hear this is working. For outbound calls - moving the routing / NAT / firewall to UC520 was the key. If you did not do that, connection-reuse would help.


For inbound - that is why I sent the dial-peer CLI to you in my previous post - the way this works in CCA is:

- for every DID on the system, create an inbound dial peer (incoming called-number CLI) without the permission term CLI

- have a catch all inbound dialpeer with permission term so that all other calls from the SIP Trunk are failed. This would prevent attacks where the SIP packet may come from a user spoofing the SP IP address as calls to non DID numbers would be blocked.


I would re add the permission term on dial-peer voice 1000 and make sure CCA configures all your DIDs.

Actions

This Discussion

Related Content