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
