> It's possible/probable/obvious (depending on who you talk to) that > multipart will have to be supported for emergency calling, in which > there is an SDP body and a Location message body... > > This doesn't mean UAs that *don't* establish voice/video dialogs will > have to support multipart, just for those UAs that do establish > voice/video dialogs with emergency response centers (again, depending > on who you talk to).
By support, you mean such a UA would need to be able to send an Invite with a multipart, right? That is, such a UA wouldn't need to necessarily receive or need to parse multipart for the purposes of emergency calling. (It's quite trivial to send multipart, and obviously more difficult to handle parsing it, especially nested multiparts. Not impossible -- it's been done for years and years by mail user agents, afterall, but it's also not slam-dunk easy.) -d > At 02:15 PM 5/9/2007, Dan Wing wrote: > >The now-expired draft > >http://tools.ietf.org/html/draft-jennings-sipping-multipart-0 > 2 explored > >multipart/alternative. One difficulty, however, is what > does it mean to say > >"can understand a part". > > > >This is easy if one part is SDP and another part is SDPng. If you > >understand SDPng, you process it; if you don't, you process the SDP. > > > >However, it's really hard if one part is SDP and another > part is also SDP -- > >in some cases we would like the answerer to "pick the better > SDP". At the > >time, we were considering multipart/alternative as a way to offer RTP > >(RTP/AVP) and SRTP (RTP/SAVP), but we found it doesn't work > well at all. > >Since then, draft-ietf-mmusic-sdp-capability-negotiation is > a superior > >solution to sending an offer containing RTP and SRTP. > > > >I suppose we could avoid the difficulty by prohibiting identical > >Content-Types in the alternatives. > > > >-d > > > > > > > -----Original Message----- > > > From: Christer Holmberg (JO/LMF) > > > [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, May 03, 2007 3:50 AM > > > To: [EMAIL PROTECTED]; [email protected] > > > Subject: RE: [Sip] Support for Multipart/MIME > > > > > > > > > Hi, > > > > > > Multipart/alternative is interesting. I guess that, for SDP, > > > it could be > > > used to provide different "offer alternatives". I think it > > > would be good > > > to compare it against some of the other grouping/alternative > > > mechanisms > > > we have defined for that purpose. > > > > > > Regards, > > > > > > Christer > > > > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > > Sent: 30. huhtikuuta 2007 19:13 > > > > To: [email protected] > > > > Subject: Re: [Sip] Support for Multipart/MIME > > > > > > > > From: Cullen Jennings <[EMAIL PROTECTED]> > > > > > > > > I think the WG should consider an update to 3261 (likely > > > > done through > > > > the process Keith has proposed) that makes this > multipart/MIME > > > > mandatory to implement. > > > > > > > > I assume that the requirement is that if a message has a > > > > multipart/alternative body, and the UA is capable of > > > > understanding one part of the body, then it must be able to > > > > extract that part and use it to process the message. > > > > > > > > Dale > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > >_______________________________________________ > >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 > _______________________________________________ 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
