I have someone who is trying to send me SIP-T messages through a SER system that acts as a PSTN gateway. The destination PSTN switch can accept either SIP or SIP-T as can the originator of the INVITE.

The SIP-T message appears to pass through SER in both directions with the SIP-T data apparently intact.

However, there are problems with the SDP payload. The functions in modules/nathelper that locate the SDP payload (mainly in check_content_type() in nhelpr_funcs.c) appear to be coded to never work properly with multi-part MIME in the message headers, nor deal with section boundary markers in the message body. So when the headers contain a:

Content-Type: multipart/mixed;boundary=tekBoundary

instead of the expected*:

Content-Type: application/sdp

nathelper gets confused and says things like: May 22 21:25:56 ser1 ser[24905]: ERROR:check_content_type: invalid type for a message May 22 21:25:56 ser1 ser[24905]: ERROR: extract_body: content type mismatching May 22 21:25:56 ser1 ser[24905]: ERROR: force_rtp_proxy: can't extract body from the message

* (nhelpr_funcs.c also tests for Content-Types beginning with "icat", "ion" and "appl" in addition to sdp but doesn't know how to deal with any others, including a "multipart/mixed" and the resulting nested message body.

Subsequently, calls to the various force_rtp_proxy() and related functions when processing the INVITE, 183 Session Progress or 200 OK replies do not substitute in the new IP address provided by rtpproxy (because it can't find the start of the body or a known body type), and so the party receiving this message will get the uncorrected IP address and audio for the call fails due to an unreachable IP address.

This limitation is noted in ser-2.0.0-rc1.

Has anybody done any development to make check_content_type() and the related functions in nhelpr_funcs.c capable of dealing with multi-part MIME sections? Ideally, SER should allow the entire message body even with more than one section to pass without comment or complaint. Meanwhile, nathelper should be able to find the sdp section and allow parsing and editing of it as would have been done if the body contained only one section.

In reading RFC 3261, it appears that multi-part MIME is allowed and so it appears that nathelper is violating the RFC by not coping with this. Here is the passage on this subject that caught my attention:

7.4.1 Message Body Type (RFC 3261)

The Internet media type of the message body MUST be given by the Content-Type header field. If the body has undergone any encoding such as compression, then this MUST be indicated by the Content- Encoding header field; otherwise, Content-Encoding MUST be omitted. If applicable, the character set of the message body is indicated as part of the Content-Type header-field value.

The "multipart" MIME type defined in RFC 2046 [11] MAY be used within the body of the message. Implementations that send requests containing multipart message bodies MUST send a session description as a non-multipart message body if the remote implementation requests this through an Accept header field that does not contain multipart.

SIP messages MAY contain binary bodies or body parts. When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined to have a default charset value of "UTF-8".

Thanks in advance to any pointers to newer nathelper code that deals with this RFC-permitted message body format.

Here is an example of the INVITE message that caused the problem:

INVITE sip:9712345678@230.123.45.67:5060 SIP/2.0 Via: SIP/2.0/UDP 225.67.89.1:5060;branch=z9hG4bKfi0cjdk0qb8sv24f18ki1ddao4 To: sip:9712345678@230.123.45.67:5060 From: sip:8005551212@225.67.89.1;tag=11775339 Call-ID: 1241812549-66096587@SIP CSeq: 1 INVITE Max-Forwards: 69 Contact: sip:8005551212@225.67.89.1:5060;transport=udp Supported: 100rel Expires: 330 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, PRACK, REFER, SUBSCRIBE, NOTIFY, UPDATE, REGISTER P-Asserted-Identity: sip:8005551212@8.4.99.59 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary=tekBoundary Content-Length: 426

--tekBoundary Content-Type: application/sdp

v=0 o=- 321533952 1243026447 IN IP4 225.67.89.1 s=- c=IN IP4 225.67.89.1 t=0 0 a=sendrecv m=audio 49168 RTP/AVP 18 101 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=yes a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20

--tekBoundary Content-Type: application/isup; base=ansi92; version=ansi

..x ..x...x..x.Pxx ....x@xp.xx..xx..

--tekBoundary--