RE: [Sip] Support for Multipart/MIME

["Francois Audet" <[e-mail]>]

Hi Dan, 

To answer your question about the Multipart usage for ISUP/QSIG
tunnelling.

No, it does not set-up two calls. It sets-up ONE call.

The SDP is mandatory.

The QSIG or ISUP is optional. If supported it provides additional
information for the softswitches for legacy PSTN interop or other
features.
If not it should be safely ignored.

So 3204 operates exactly as it should. Works fine. Has been working fine
for years (except for implementations that have problems with Multipart
MIME,
which has forced the use of B2BUA that strip off these MIME bodies.)

> > -----Original Message-----
> > From: Francois Audet [mailto:[e-mail]]
> > Sent: Wednesday, May 23, 2007 11:18 AM
> > To: Gonzalo Camarillo
> > Cc: Paul Kyzivat; [e-mail]; Dan Wing; Christer Holmberg (JO/LMF)
> > Subject: RE: [Sip] Support for Multipart/MIME
> > 
> > This is great Gonzallo. Thanks for doing this.
> > 
> > Here are some comments:
> > 
> > - In section 4, another example that I think you should list for 
> >   Multipart/Mixed is RFC 3204 which actually has examples of 
> >   INVITEs with Multipart/Mixed (one for SDP, the other for 
> >   QSIG/ISUP tunnelling). That spec also illustrates the content-
> >   disposition mechanism (i.e., "optional" for QSIG/ISUP).
> 
> I wasn't aware of that usage in RFC3204.  In both section 4.1 
> and its example, though, I don't think it's using 
> multipart/mixed correctly.  Here is its example (section 4.1 
> is similar):
> 
>    To illustrate the use of the 'application/QSIG' media 
> type, below is
>    an INVITE message which has the originating SDP information and an
>    encapsulated QSIG SETUP message.
> 
>    Note that the two payloads are demarcated by the boundary parameter
>    (specified in RFC 2046 [4]) which in the example has the value
>    "unique- boundary-1". This is part of the specification of MIME
>    multipart and is not related to the 'application/QSIG' media type.
> 
>          INVITE sip:[e-mail] SIP/2.0
>          Via: SIP/2.0/UDP sc10.nortelnetworks.com
>          From: sip:[e-mail]
>          To: sip:[e-mail]
>          Call-ID: [e-mail]
>          CSeq: 1234 INVITE
>          Contact: <sip:[e-mail]>
>          Content-Length: 358
>          Content-Type: multipart/mixed; boundary=unique-boundary-1
>          MIME-Version: 1.0
> 
>          --unique-boundary-1
>          Content-Type: application/SDP; charset=ISO-10646
> 
>          v=0
>          o=audet 2890844526 2890842807 5 IN IP4 134.177.64.4
>          s=SDP seminar
>          c=IN IP4 MG141.nortelnetworks.com
>          t= 2873397496 2873404696
>          m=audio 9092 RTP/AVP 0 3 4
> 
>          --unique-boundary-1
>          Content-type:application/QSIG; version=iso
> 
>          08 02 55 55 05 04 02 90 90 18 03 a1 83 01
>          70 0a 89 31 34 30 38 34 39 35 35 30 37 32
>          --unique-boundary-1--
> 
> Per the semantics of multipart/mixed, both of those bodies 
> are interpreted by the recipient -- wouldn't that cause two 
> calls to be set up?  Or does the SDP describe the VoIP leg 
> and the QSIG describes the PSTN leg?  If the latter, I do 
> feel multipart/related would have been a better choice.  
> 
> [[As MIME parsers are supposed to interpret unrecognized 
> multipart/* as multipart/mixed, a MIME-compliant parser that 
> currently has the RFC3204-described behavior 
> <quote>should</quote> work correctly if it received a 
> multipart/related instead of multipart/mixed.]]
> 
> > - I like your text on Multipart/Alternative.
> 
> Yes, that section is very well written and captures exactly 
> the problem with multipart/alternative.
> 
> ...
> > - I believe that the following text in section 4 is not 
> strong enough:
> > 
> >    If a UAS does not support multipart bodies and receives one, the 
> > UAS
> >    SHOULD return a 415 (Unsupported Media Type) response.
> > 
> >   Instead, it should read as follows:
> > 
> >    If a UAS does not support multipart bodies and receives one, the 
> > UAS
> >    MUST return a 415 (Unsupported Media Type) response, and it MUST 
> >    return a list of acceptable formats as specificed in 
> > [RFC3261]/21.4.13.
> > 
> >   I believe this is in line with RFC 3261/8.2.3. I will 
> point out that
> >   we have found in the field that if a UAS does NOT send a
> > 415 and just
> >   "ignores" the Multipart body altogether, what happens is that the 
> > receiver of the
> >   INVITE interprets the INVITE as having NO initial Offer, 
> and sends 
> > an an
> >   Offer of it's own in the 200/18X. This is interpreted by 
> the sender 
> > of the
> >   INVITE as an Answer, resulting in all hell breaking loose.
> 
> That's awful.  You could detect this situation by requiring 
> the answerer to insert a reference to the Content-ID they're 
> answering; if an ACK comes back without that Content-ID, 
> you'll know you encountered such a defective implementation.
> 
> -d
> 
> 
>  
> > > -----Original Message-----
> > > From: Gonzalo Camarillo [mailto:[e-mail]]
> > > Sent: Wednesday, May 23, 2007 01:24
> > > To: Audet, Francois (SC100:3055)
> > > Cc: Paul Kyzivat; [e-mail]; Dan Wing; Christer 
> Holmberg (JO/LMF)
> > > Subject: Re: [Sip] Support for Multipart/MIME
> > > 
> > > Hi,
> > > 
> > > I have taken a stab at writing a quick draft about both issues (I 
> > > agree it makes sense to tackle them in a single 
> document). Until it 
> > > appears in the archives, you can fetch it from:
> > > 
> > > http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-h
> > > andling-00.txt
> > > 
> > > I have marked a few open issues so that we can continue 
> discussions 
> > > around those on the list (this is, of course, just an initial 
> > > draft).
> > > 
> > > Cheers,
> > > 
> > > Gonzalo
> > > 
> > > 
> > > Francois Audet wrote:
> > > > My preference is one document. 
> > > > 
> > > >> -----Original Message-----
> > > >> From: Paul Kyzivat [mailto:[e-mail]]
> > > >> Sent: Wednesday, May 16, 2007 05:18
> > > >> To: Gonzalo Camarillo
> > > >> Cc: Audet, Francois (SC100:3055); [e-mail]; Dan
> > Wing; Christer
> > > >> Holmberg (JO/LMF)
> > > >> Subject: Re: [Sip] Support for Multipart/MIME
> > > >>
> > > >> Hi Gonzalo,
> > > >>
> > > >> I guess the question is whether we want to write a document 
> > > >> specifically focused on Content-Disposition, or if we want
> > > to combine
> > > >> work on that with work on specifying use of multipart.
> > > >>
> > > >> They aren't the same thing, but content-disposition 
> becomes more 
> > > >> significant when there are multiple body parts, so 
> there is some 
> > > >> justification for combining the work.
> > > >>
> > > >> 	Paul
> > > >>
> > > >> Gonzalo Camarillo wrote:
> > > >>> Hi,
> > > >>>
> > > >>> yes, Paul and I talked about writing a draft to clarify a
> > > >> few issues
> > > >>> that relate to content dispositions in SIP a while ago. We
> > > >> were quite
> > > >>> busy at that point and did not have time to write it, but
> > > >> maybe it is
> > > >>> time to do it now.
> > > >>>
> > > >>> Cheers,
> > > >>>
> > > >>> Gonzalo
> > > 
> > > 
> 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip