>Personally, I think we should treat parallel just like mixed >when received.
I agree. And, maybe forbid the usage of parallel with SIP, unless we really can come up with a valid use-case where it is needed. Regards, Christer >And continue to use mixed for sending, at least for things >that exist already (like QSIG/ISUP). > >I would be surprised if parallel was really used in the wild... > > But I do agree we could say something about it. > > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:[EMAIL PROTECTED] > > Sent: Monday, May 28, 2007 00:58 > > To: Dan Wing; Audet, Francois (SC100:3055); Gonzalo > Camarillo (JO/LMF) > > Cc: Paul Kyzivat; [email protected] > > Subject: RE: [Sip] Support for Multipart/MIME - order of bodies > > > > > > Hi, > > > > One question is when "parallel" should be used instead of "mixed". > > > > When mixed is used, the order of the bodies is significant, > which is > > not the case for parallel. And, for ISUP or QSIG, is there a > > difference in which order the ISUP/QSIG and SDP bodies are > presented? > > > > I know that support of ISUP/QSIG bodies are implemented > using mixed, > > and I am not proposing to change that. But, I think the > draft should > > maybe talk a little more about the differences between parallel and > > mixed. > > > > In most cases I guess it doesn't matter which one would use. > > At least I can't think of any SIP use-case where the order of the > > bodies would be significant. > > > > Regards, > > > > Christer > > > > > > > > > -----Original Message----- > > > From: Dan Wing [mailto:[EMAIL PROTECTED] > > > Sent: 23. toukokuuta 2007 22:53 > > > To: 'Francois Audet'; Gonzalo Camarillo (JO/LMF) > > > Cc: 'Paul Kyzivat'; [email protected]; Christer Holmberg (JO/LMF) > > > Subject: RE: [Sip] Support for Multipart/MIME > > > > > > Yes, I expect RFC3204's syntax and semantics work fine > between two > > > implementations that implement RFC3204. > > > > > > My question if it the choice of multipart/mixed in RFC3204 > > was correct > > > or if multipart/related would have been more appropriate > > for RFC3204. > > > I have this question because the QSIG (and ISUP) are > > directly related > > > to the SDP, and the QSIG/ISUP data provides additional > information > > > about that outgoing PSTN call leg that assists it in being set up. > > > > > > My underlying question is what guidance we want to provide for > > > Gonzalo's document. If RFC3204's use of multipart/mixed > is what we > > > want to do in SIP when there are bodyparts that have a > relationship > > > with each other, then Gonzalo's document will need to > > discourage use > > > of multipart/related. > > > > > > -d > > > > > > > -----Original Message----- > > > > From: Francois Audet [mailto:[EMAIL PROTECTED] > > > > Sent: Wednesday, May 23, 2007 12:22 PM > > > > To: Dan Wing; Gonzalo Camarillo > > > > Cc: Paul Kyzivat; [email protected]; Christer Holmberg (JO/LMF) > > > > Subject: RE: [Sip] Support for Multipart/MIME > > > > > > > > > > > > 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:[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
