[Serusers] Nathelper doesn't support multipart MIME even though allowed by RFC 3261?

[Frank Durda IV]

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 at 230.123.45.67:5060 SIP/2.0
Via: SIP/2.0/UDP 225.67.89.1:5060;branch=z9hG4bKfi0cjdk0qb8sv24f18ki1ddao4
To: <sip:9712345678 at 230.123.45.67:5060>
From: <sip:8005551212 at 225.67.89.1>;tag=11775339
Call-ID: 1241812549-66096587 at SIP
CSeq: 1 INVITE
Max-Forwards: 69
Contact: <sip:8005551212 at 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 at 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 at xp.xx..xx..

--tekBoundary--