SIP Trunking Issues

Unanswered Question
Jul 18th, 2009

Hello Everyone,

I am having an issue with SIP Trunking. The topology of my network is the UC520 sitting behind an SR520ADSL router. The connections section of the SIP packet is showing the FA0/0 port on the UC520 (10.201.14.34). NAT is verified and working with the correct translations, port 5060. I have tried using the: CommRTR(conf-serv-sip)#bind all source-interface interface. I have set this to a loopback which is configured with the public address. The binding information appears correctly under sip-ua. However, registration with the registrar server goes down. When binding is not configured, the call is connected but audio is dropped in both directions.

I am new to SIP, so my question is: Does anyone know how to bind my public address to the "connection" section inside the packet. I'm not sure if I'm pointed in the right direction.


Thanks for your help. Regards...Matt

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Maulik Shah Sun, 07/19/2009 - 09:27

Its hard to say much from the info given as would need configuration & version on both the UC500 & SR520 for starters. You seem to indicate 2 different issues:

- registrations do not stay up - it maybe the firewall pinhole on the SR520 being closed after no messages are sent for a certain period of time. Do you have a static NAT entry for port 5060 on the SR520 - something like:

- calls have no audio - do you have a debug of sniffer capture of this? There are typically 2 levels for the connection information in the SIP SDP - session level and media level. If the media level is getting NATTED correctly by the SR520, you should be OK as the media level takes precedence over the session level (see example below)

c=IN IP4 10.1.10.2                    << SESSION LEVEL
t=0 0
m=audio 16792 RTP/AVP 0 18 101
c=IN IP4 10.12.25.201                << MEDIA LEVEL   

One other comment, I did see the SR520 was not doing both c-lines till IOS 12.4(24)T1 so that maybe an option to test.

mbram1313 Sun, 07/19/2009 - 11:11

Maulik:

Thanks for your info. The registration connection is only going down when sip-sbc is applied to the SR520. Both devices have the most current packages. Wireshark at the carrier is indicating that the connections section is showing my private address. I've included a screenshot taken from the SIP carrier and the printout from both routers. They are looking for authentication, not my public IP address. Thanks for your help. Regards...Matt

Maulik Shah Sun, 07/19/2009 - 11:36

Get rid of the NAT-SBC CLIs - that is not meant for deployments with UC520, it is meant for home routers with a SIP phone going to a Vonage for example.

On the static NAT statement on the SR520 for port 5060 - remove the extendable keyword at the end

On the UC520 - add the below:

sip-ua

  connection-reuse

Make sure you restart registration after theabove

Your sniffer capture is cut off - I cannot see the 2nd c= line (below the m= line) which is what the SP should use for RTP as I mentioned in my previous post. Can you try all of the above, re test and send the complete wireshark capture INVITE from the UC520?

Maulik Shah Sun, 07/19/2009 - 12:59

Its hidden in that IOS release - just type it in as is:

sip-ua

  connection-reuse

mbram1313 Sun, 07/19/2009 - 13:23

Thank you Maulik:

It did not work at first. Then I added the nat symmetric check-media-src and the nat sysmmetric role active command from within sip-ua on the UC520. Works great. Thanks for all of your help!

Regards,

Matt

Maulik Shah Mon, 07/20/2009 - 09:13

Am wary of using the last 2 CLI you put in as there maybe issues going to voicemail. I wold check that and make sure.

On a side note - not sure what exactly the cause of this RTP not going across is - can yo see if enabling this CLI on the SR520 helps any:

ip nat service enable-sym-port

You need to disable / enable NAT for this CLI to take effect (remove ip nat inside / outside on the interfaces and re apply)

mbram1313 Mon, 07/20/2009 - 11:03

Yes, thank you Maulik. I am having issues where the VM is not recording messages. Calling in hits the AA, and you can hear the mailbox greetings. However, no recoding is happening from inbound calls and calls from the 7965 station when leaving messages for other users and even recording VM Names. I just did an upgrade since the mailboxes were installed, so I thought that this might be the issue. Have you had experience with this problem, or are the NAT symmetric commands causing the VM to not work at all. Can you explain why the NAT symmetric commands do not allow VM traffic?

SIP Registration was restarted after the reuse command was tried with no luck. I will try the ip nat service enable-sym-port and remove the Nat commands on the UC520 to see if everything works.

Regards...Matt

mbram1313 Mon, 07/20/2009 - 11:41

Maulik:

I have confirmed that the sip-ua nat commands are disabling the ability to record to VM. However, without them, NAT traversal at the SR520 is not working for audio. I have implemented the nat service command you advised. Beforehand I shut nat down on the interfaces, then enabled after the command was installed. Not sure what to do. Thanks for your help...Matt

Maulik Shah Mon, 07/20/2009 - 14:16

Since there were a lot of changes, this may sound painful but we need to go one step at a time:

- On the SR520 - can you permit RTP explicitly:

class-map type inspect match-any SDM-Voice-permit
  match protocol rtp

- with the current settings, can you gather a wireshark capture off the SR520 WAN port for a SIP call that has no audio? I presume this happens for all calls.

- are there any SIP registration issues after you removed the nat-sbc CLI on the SR520?

- if you can also attach the latest config as there were a lot of changes we made

mbram1313 Thu, 07/23/2009 - 08:38

Hello Maulik:

I will be working on this over the weekend. Thank you for your help. The UC520 has multiple pre-configured SIP Trunk providers built into the CCA. One thought I had was to takedown my current trunk and all SIP-UA configs, then bring up one of the pre-configured trunks. This way I can note all and any SIP-UA configs that are placed by the CCA. What are your thoughts? I would like to isolate the issue to either the UC520, or the SR520. Thanks again for your help...Matt

Maulik Shah Sun, 07/26/2009 - 22:53

I do apologize for not replying earlier as I was out of the office on Friday and missed the below message. I agree with your approach of using the re configuring the UC520 SIP trunk via CCA from scratch & then adding extra CLI - how did that go?

Who is the SP you are testing with by the way?

mbram1313 Mon, 07/27/2009 - 00:15

Hello Maulik:

I'm not getting anywhere and am a little frustrated. If I turn the nat symmetric under Sip-ua off on the UC520, audio drops but registration stays up. If I turn it on, it cuts the audio out on the VM recording. I can hear it ok, but cannot record. I verifed that the dial peers for the VM and AA are configured as outbound SIP proxy. SIP SBC is off on SR520, SNAT is configured for SIP on the SR520. Just no audio. I'm not getting Connection addressing changed at layer 7 without the SIP-UA symmetric NAT turned on on the UC520. Not sure what elese to do. Changing over to the SIP trunks did not help. I'm using Broadvox. Quality is great, but generic configuration data behind NAT is lacking on the Cisco site. I'm going to have to open a TAC case on it. Thanks for all of your help. Best Regards, Matt

Maulik Shah Mon, 07/27/2009 - 21:54

The nat symmetric CLI is not meant for the SIP Trunking scenario - it was developed for another test case and should not be used. I do not think its the c= line as I mentioned earlier - you only need this changed at the session level which it was doing per what I understood. Any case, a TAC case may help debug this in real time - will see if can track or PM (private message) me the TAC case #.

mbram1313 Sun, 08/02/2009 - 21:06

Maulik:

Thank you for all of your help with this issue. The TAC is amazing! The engineer had the problem resolved within 2-hours. It turns out the UC520 was issuing to "c" fields in the STP data. He resolved with a special voice-class which was applied to all of the appropriate dial-peers. The only problem I'm having now is that the MWI is not working. I can live with that for a while.

The SR520 was working fine. The problem is that even the latest ver does not support STP reformating when there are additional parameters. The default is to ignore the STP when all of the parameters are not met.The second c line is in the RFQ, so they will need to work on it for future releases.

Thanks again for all your help. If you have any suggestions on the MWI issue, I would appreciate it.

Best regards,

Matt

Maulik Shah Mon, 08/03/2009 - 09:25

Thanks for the update and glad to hear all is working now. The feature request for NATing the c= line is part of the roadmap on the SR520 side - having said that this issue is also caused by the SP side being non RFC3261 compliant as the RFC clearly states that the SIP end points must honor the 2nd c= line over the 1st c= line in the SDP (1st and 2nd are with respect to the position in the SDP).

If you do have a snippet of the config - feel free to add it in here removing any unique customer info.

mbram1313 Mon, 08/03/2009 - 10:04

Hello Maulik:

Do you have any idea why my MWI would go out? The profile is not on the dial-peers that deal with the cue. I think they are 1003,1005, 2001 & 3000.

Thanks...Matt

PS - Do you know when the SR520 issue is going to be resolved?

ROBERT THOMPSON Wed, 10/07/2009 - 09:42

Dear Maulik,

We have the same issue with our SR520 and UC520 - IE - one way voice with SIP provider where SR520 is the router

Can you advise and fix for this?

Kind regards,


Rob

Maulik Shah Wed, 10/07/2009 - 12:15

The root cause is your SP is not following the SIP RFC - if this is the same issue as described in thread where the SR520 NAT does not translate all the c= lines in the SIP message from UC520 - here is a workaround you can add using CLI on the UC520 (need SW Pack 7.0.x or higher):

voice class sip-profiles 1
request ANY sdp-header Connection-Info remove
response ANY sdp-header Connection-Info remove

Add this to all SIP trunk dial-peer


dial-peer voice xxxx voip
voice-class sip profiles 1

See if that works for you.

ROBERT THOMPSON Thu, 10/08/2009 - 00:18

Dear Maulik and Matt,

Thanks to both of you for actually posting the initial issue. Also, thank you for both your replies. This has worked perfectly!

I can safely say that working with Cisco equipment since 1999, this was not the most obvious cfg. I could not find the documentation on this one. The only time I have ever been challenged like this before was on my CCIE lab back 2002.

Cheers for your help!

Kind regards,


Rob

mbram1313 Thu, 10/08/2009 - 08:31

No problem Rob,

Hopefully Cisco will release a new 12.4 that fixes this issue on the SR520 SDP/NAT, SIP RFC issue. The same version, 12.4(24) works fine on other equipment...Matt

sethschmautz Wed, 03/03/2010 - 23:55

Just wanted to comment for anybody reading this thread that this same problem can exist on an SA500 in front of a UC500.  I was experiencing this problem only occaisionally to specific phone numbers.  Some would always work (cell phones), some would sometimes work (my corporate PBX), and others would never work.  My thread is here:

https://www.myciscocommunity.com/message/38184

Sip Trunk Provder: NexVortex

Thanks,

Seth

mbram1313 Wed, 10/07/2009 - 16:03

Robert,

After you apply the sip-profiles to the inbound and outbound dial-peers, you will notice that the MWI and message notification will be wiped out. Work around is to put the service module on the same subnet as the voice subnet. This is not done by default by SDM, witch puts it on 10.1.10.2, or something like that. My service module is now on 10.1.1.2. This should fix the issue.

Hope that helps,

Matt

Actions

This Discussion

Related Content