Prevent multiple c= (Connection Info) fields in SIP/SDP message

[ofwegen]

Hello,

For my home/personal study I have two routers.

Internet -- Cisco 1841 -- Cisco 1751-V

The 1841 is a ADSL router with NAT, the 1751-V has two FXS and one FXO ports for the connection of PSTN phones. I've configured the sip-ua client (connecting to my ISP) in the 1751-V and that works for 90%. I get the famous one-way-audio problem. After some wiresharking I've found the issue. Multiple c= (connection information) fields are present in the SIP/SDP Invite message my 1751-V is sending. Normally this is not an issue. The NAT SIP service in the 1841 should translate all the entry's within the SIP/SDP Invite message and all would work fine. One entry is for session level and one entry is for media level. But in the 1841 (IOS= 12.4.(20)T) there is a nasty bug (CSCsv43242) which only translates (ip nat service sip) the first entry of an SIP message. Since this bug is present in almost any version available to this router and Cisco has given the priority "6" to this bug, I don't expect a quick solution. The workaround suggested is to prevent multiple c= fields to be send out by the SIP device. Now that's my question, how can I only send out one c= field from the 1700? Since this router is not supported in IOS version 12.4(20)T I can not use sip-profiles to strip the content. Anybody else has an idea? I've tried to modify the c= field with the bind command to a lo0 adapter (with my internet ip on it). But that does not seem to work. Since I'm pretty new to SIP/IPT some help in the right direction would be much appreciated!

Regards,

Leon

[ofwegen]

Can someone explain what part is the Session level and what part is the Media level?

v=0
o=CiscoSystemsSIP-GW-UserAgent 2078 222 IN IP4 10.55.60.60
s=SIP Call
c=IN IP4 10.55.60.60
t=0 0
m=audio 19442 RTP/AVP 0 8 101
c=IN IP4 84.245.39.xyz
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

Seems like the Cisco 1841 is only translating the last record in the SDP message. But my ISP is connection to one of the other (10.55.60.60) ip addresses. According to the RFC, the SIP server should connect to the Media level c= field in case of multiple entries.

[Steven Holl]

For anyone hitting this bug:

Because this has never worked in the Cisco NAT code, it is  considered a 'feature enhancement request' by our development team.   They need a strong business case to get this bug fix on the roadmap so  that it can be fixed.

I STRONGLY encourage you to contact your Cisco account team and have them file a PERS request to get this bug on the roadmap with development so that it can be fixed.  That is the proper avenue to getting sev6 bugs pushed through and worked on by development for a future release.  The more customers that get PERS filed for this, the quicker it will get addressed.

-Steve

[ofwegen]

Hi Steven,

Thank you for your comment. As you might have read, this is my home setup. I don't have a Cisco support contract on this. The customers I work for do have Cisco contracts, but I think it's not right to file a case on their name for my home equipment. To bad that this is the only way to put presure on a fix. I see a lot of 8xx serie router (home) users with similair issue's on the internet. If they ever find the reason why their audio is only working one-way, they will not file a case with Cisco for the same reason I can't.

Regards,

Leon

[Steven Holl]

Leon,

Even if you don't have a support contract, in my opinion, it still warrants a reason for you to request this feature.  You're trying to do something that you've experienced your customers' networks need to be able to do, and you aren't able to do it.  You don't need a support contract on this device to contact your account team and let them know you would like to see development addressthis bug.

Note that I'm not asking you to open a TAC case.  That would not be the appropriate measure to get a feature request pushed through (we don't have a strong means to present business cases to development for new features from a TAC perspective).  You should contact your account manager/SE and have them file a PERS request, which is the way that we track feature requests internally between customers and the business units.

-Steve

[ofwegen]

Hello Steven,

I don't run into this issue with a customer, just at home. I don't have an account manager/SE at Cisco for my personal setup.

Regards,

Leon