[Home]

Summary:ASTERISK-03187: Asterisk SIP/SDP RFC Violation -> One way voice
Reporter:jkoop (jkoop)Labels:
Date Opened:2005-01-05 09:11:45.000-0600Date Closed:2005-02-13 19:29:32.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) brian_sip_debug.txt
( 1) digium.txt
( 2) mydiff.txt
Description:Asterisk is not taking over a specific rule in RFC 2327 (SDP), which in our situation causes one-way voice. We are using Asterisk in-between Cisco hardware, scenario:

IAD2431 <-> 7507 <-> Asterisk <-> AS5300 <-> PSTN

The IAD makes the call, it is NAT'ed on the 7507 into an inside address (which Asterisk uses and sees), and from there the traffic goes over onto the AS5300. ReINVITES are enabled in this scenario. The problem is that Asterisk is not implementing the rules in RFC2327 properly; it violates a rule concerning the Connection Data in the SDP header.

To start from the beginning, the SDP headers the IAD2431 sends contain two connection headers, one is the Session-Level-Address, and one is the Media-Description-Level-Address. They look like this &ASTERISK-7999;c=IN IP4 213.1670.207.2&ASTERISK-8000;. The 7507 translates only the Media-Description-Level-Address, because that is the actual media information that should be used from the SDP portion of the SIP packet (according to the RFC, read on).

But the real problem is that Asterisk picks the Session-Level address, and only puts that in the INVITE packet towards the AS5300, so the one-way voice scenario is created (that is a non-translated address, which the AS5300 cannot reach). Take note of this portion in RFC2327:

&ASTERISK-7999;A session announcement must contain one "c=" field in each media description (see below) or a "c=" field at the session-level.  It may contain a session-level "c=" field and one additional "c=" field per media description, in which case the per-media values override the session-level settings for the relevant media.&ASTERISK-8000;

If a Media-Description-Level-Address exists in the packet (it is optional), it should always use this address, and Asterisk does NOT do this. The Media-Description-Address is always on the place, which is shown in the packet sent by the IAD2431 below.

INVITE sip:000648790141@81.175.81.36:5060 SIP/2.0
Via: SIP/2.0/UDP  10.0.0.11:5060;branch=z9hG4bK2A221E5A
From: <sip:0368454535@81.175.81.36>;tag=289814F4-1687
To: <sip:000648790141@81.175.81.36>
Date: Fri, 08 Mar 2002 21:10:57 GMT
Call-ID: D1880B54-320F11D6-AC84C5F5-C2B7291F@213.160.207.2
Supported: 100rel,timer
Min-SE:  1800
Cisco-Guid: 3515313812-839848406-2894251509-3266783519
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1015621857
Contact: <sip:0368454535@10.0.0.11:5060>
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 295
o=CiscoSystemsSIP-GW-UserAgent 3717 2538 IN IP4 213.160.207.2
s=SIP Call
c=IN IP4 213.160.207.2 /* Original Session-Level-Address (nnon NAT&ASTERISK-7996;ted) */
t=0 0
m=audio 17348 RTP/AVP 8 100 101
c=IN IP4 10.0.0.11  /* NAT&ASTERISK-7996;ted Media-Description-Level-Address which SHOULD be used*/
a=rtpmap:8 PCMA/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

I have tried the sip.conf NAT=YES setting which ignores the portions from the packet, and sends everything to the address where the packets originated, but it did not work. Only in a non-NAT&ASTERISK-7996;ted situation that seems to have some success. Any other options are not known to me.

What should be fixed then?

Asterisk should:
1. Duplicate both the Session-Level-Address and the Media-Description-Level-Address in the INVITE packets towards the AS5300, which leaves the choice which one to use to the AS5300. Preferred situation in my opinion.
2. Use the Media-Description-Level-Address in the INVITE packets towards the AS5300 (if it exists, it is optional!) as the only Connection field existing in the packet.

Another example in the demo scenario, which demonstrates what happens:

Original SDP of an INVITE from the IAD to Asterisk (notice the per-media "c=" line):
v=0
o=CiscoSystemsSIP-GW-UserAgent 1186 5318 IN IP4 213.160.252.131
s=SIP Call
c=IN IP4 213.160.252.131
t=0 0
m=audio 17384 RTP/AVP 8 100 101
c=IN IP4 213.160.252.131
a=rtpmap:8 PCMA/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

This is the reINVITE SDP from Asterisk towards the AS5300:
v=0
o=root 26191 26192 IN IP4 213.160.252.131
s=session
c=IN IP4 213.160.252.131
t=0 0
m=audio 17384 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -

We can confirm from the production situation with NAT that the address in the second packet is the Session-Level-Address, which is the first c= line in the first INVITE from the IAD2431, and which causes the one-way traffic to appear.


****** ADDITIONAL INFORMATION ******

Resources:
http://www.faqs.org/rfcs/rfc2327.html
Comments:By: Kevin P. Fleming (kpfleming) 2005-01-05 13:36:29.000-0600

This is going to be a hard one to fix (although I agree that it should be done), because chan_sip currently assumes that there is only a _single_ RTP peer for every SIP call. In this case, there is still only a single peer, but there could just as easily be more than one, and if we start parsing/recording/emitting media-level SDP addresses, we better do it right :-)

In spite of that, this is not a "major" bug... this is caused by a specific configuration of your network, that Asterisk does not currently support. Major bugs are reserved for situations where Asterisk does not do what it is documented to do and there is no known workaround; since Asterisk is not documented to do this, I suspect this bug's severity should be reduced (although I'll leave it to another bug marshal to make that change). That doesn't mean it's not a major problem for you... it's just not Asterisk failing to do what it says it will do. In fact, it's reasonable to requesting that the proxy/device that is NATting this session modify the address in both c= lines, even though it is not mandatory (usual RFC practice applies: be liberal in what you accept, and strict in what you send).
By: Brian West (bkw918) 2005-01-05 14:00:02.000-0600

Question is asterisk natted?

bkw
By: () 2005-01-05 14:05:16.000-0600

I have the same exact problem. One-way audio with a Cisco 7200 between SIP device -> Asterisk -> Cisco 7200 w/ VXE+ card. We have been working on it for a month and have thought that it is cisco causing the problem. Apparently, cisco doesn't like the re-invites that Asterisk sends to it (when canreinvite=yes in both cisco and sip peer settings). Only difference in my case is that I always get one-way audio, whether we have an external IP or NAT'd IP. Also, Asterisk and 7200 is on an external IP.

edited on: 01-05-05 14:09
By: Brian West (bkw918) 2005-01-05 14:06:42.000-0600

Please post your sip.conf general section.... and let me know if asterisk is on the same rfc1918 space as the IAD.  If so you should have externip and localnet set so asterisk will behave in this setup correctly.

bkw
By: () 2005-01-05 14:24:42.000-0600

There's my sip debug (brian_sip_debug.txt) with a NAT'd SIP device.
By: nick (nick) 2005-01-05 14:41:01.000-0600

OK, I don't think brian's issue is exactally the same one as jkoop's...

jkoop, does everythink work OK if you have canreinvite=no for the NATed peer?
By: Brian West (bkw918) 2005-01-05 14:50:28.000-0600

NO after talking with brian on irc he has this problem with and without NAT I have put him to collecting sip debug info for this bug.

bkw
By: nick (nick) 2005-01-05 17:17:32.000-0600

After a lengthy, fun-filled IRC session, we came to the conclusion that reinvites were the problem, and that this *is* a NAT issue. Have a look at nick.pastebin.ca/3800 and head down to CSeq: 103.  It's reinviting with the wrong address even though both sides are set not to reinvite.

edited on: 01-05-05 17:26
By: Kevin P. Fleming (kpfleming) 2005-01-05 17:23:22.000-0600

There's really two problems here... one is a situation where Asterisk is reinviting when it shouldn't, and the other is it not paying attention to the multiple addresses in the SDP data.
By: jkoop (jkoop) 2005-01-05 18:32:13.000-0600

kpfleming:

First, thanks for your reply, appreciated. I fully understand your concern that this is not a function provided by Asterisk, but it still is something that violates the RFC. It should be something which might be interesting to spend some time on, or atleast provide something which should fix it quite easily, like method 2, which I suggested in my first post.

Here is some more requested info:
When RE-INVITES are disabled, it still works, but I guess this behaviour is expected because of the NAT=YES line in the SIP context. That ignores the information received in the packet, but will just use the ip address which Asterisk received former packets from. I will test friday if this line has any influence on one of these both scenario's on the NAT'ted platform.

Second, I don't see any problem with REINVITES appearing where they shouldn't, and please focus on the first case, because the second case seems to be somewhat different from this one, it needs more research from the poster before posting, anyway!

And about the both c= lines, I have had a long discussion with Cisco about this topic, and they don't think they should do that, they think that is not the behaviour that is described according to the RFC, because the second line should be used according to the RFC, anway. And I agree that they should stick to that, otherwise they will do everything to get it working (a special), which doesn't stick to the standards.

I will let you now asap about influence of the NAT=YES settings in sip.conf.

gewijzigd op: 01-05-05 18:33
By: nick (nick) 2005-01-05 19:02:45.000-0600

Just to be sure of what you're saying, there ISN'T a problem when you turn reinvites off, right?

Can you connect to irc.freenode.net and join #asterisk-bugs sometime so we can examine this down a little further? That seemed to work well for working brian23's problem.

Nick
By: () 2005-01-05 20:02:53.000-0600

Just so you know, I did my research jkoop. It seems to be a joint Asterisk-Cisco problem, that may be hard to solve because everybody seems to be following the standard their own way!
By: () 2005-01-05 20:22:04.000-0600

Does this patch have anything to do with this?

http://bugs.digium.com/bug_view_page.php?bug_id=0002358
By: Mark Spencer (markster) 2005-01-05 20:29:18.000-0600

I went ahead and added support for the secondary "c" lines if "pedantic=yes"
By: () 2005-01-05 20:39:23.000-0600

markster, can you post the diff so I can try it with stable?
By: jkoop (jkoop) 2005-01-06 06:23:07.000-0600

markster, thanks for your time. what exactly is the behaviour you think is correct in this situation, and what did you exactly implement? And pedantic=yes is a fix for sip.conf?

and, i'm on #asterisk-bugs now.

gewijzigd op: 01-06-05 06:26
By: () 2005-01-06 09:12:34.000-0600

I applied the patch to stable 1.0.3 and still have one-way audio:

http://nick.pastebin.ca/3824
By: jkoop (jkoop) 2005-01-06 09:42:04.000-0600

brian23, your ata186 only supplies one c= line, so i'm curious how you thought this fix could have possibly fixed your problem. Your problem more looks like a routing/nat issue.

gewijzigd op: 01-06-05 09:43
By: () 2005-01-06 10:54:45.000-0600

It's a NAT issue apparently between SIP device and Cisco. Cisco doesn't want to play nice. I did observe multiple c= lines previously which gave me the reason to apply the patch.
By: Mark Spencer (markster) 2005-01-11 16:59:40.000-0600

Okay, so this isn't an asterisk bug then and we can go ahead and close it out, leaving the secondary c= line in there just to be sure?
By: jkoop (jkoop) 2005-01-12 01:40:41.000-0600

markster, please keep it open for some extra time, we are going to test your written code this week. thanks!
By: Mark Spencer (markster) 2005-01-14 00:17:28.000-0600

Okay, so what's the remaining quesiton?
By: jkoop (jkoop) 2005-01-19 09:14:46.000-0600

markster, we have added this code to the 1.0.3 release (which opposed some modifications) and we see that the calls still run perfectly, however Asterisk did not send out both the c= lines. After a analyse of the code we found that it picks the latest line in the SDP packet that comes in, and replaces that, however we weren't able to proof this on the demo (without NAT, same equipment).

We are preparing a test on the production platform that is running CVS, and we hope to get it fixed.
By: Mark Spencer (markster) 2005-01-30 01:23:01.000-0600

Is this ready to be closed out?
By: Mark Spencer (markster) 2005-02-08 01:39:33.000-0600

Bug placer seems to have lost interest, but the original request has been met.
By: Russell Bryant (russell) 2005-02-13 19:29:32.000-0600

Another tough one ...

Since this wasn't something supported before, I think this can just be a new feature supported in 1.2.

If you feel otherwise, feel free to contact me on IRC.