> -----Original Message-----
> From: Francois Audet [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 23, 2007 11:18 AM
> To: Gonzalo Camarillo
> Cc: Paul Kyzivat; [email protected]; 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:[EMAIL PROTECTED] SIP/2.0
Via: SIP/2.0/UDP sc10.nortelnetworks.com
From: sip:[EMAIL PROTECTED]
To: sip:[EMAIL PROTECTED]
Call-ID: [EMAIL PROTECTED]
CSeq: 1234 INVITE
Contact: <sip:[EMAIL PROTECTED]>
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:[EMAIL PROTECTED]
> > Sent: Wednesday, May 23, 2007 01:24
> > To: Audet, Francois (SC100:3055)
> > Cc: Paul Kyzivat; [email protected]; 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:[EMAIL PROTECTED]
> > >> Sent: Wednesday, May 16, 2007 05:18
> > >> To: Gonzalo Camarillo
> > >> Cc: Audet, Francois (SC100:3055); [email protected]; 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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
