Asterisk SIP/SDP RFC Violation -> One way voice 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 “c=IN IP4 213.1670.207.2”. 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: “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.” 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: ;tag=289814F4-1687 To: 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: 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’ted) */ t=0 0 m=audio 17348 RTP/AVP 8 100 101 c=IN IP4 10.0.0.11 /* NAT’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’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. Resources: http://www.faqs.org/rfcs/rfc2327.html