> -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 09, 2007 6:55 PM > To: Dan Wing; [EMAIL PROTECTED] > Cc: [email protected] > Subject: RE: [Sip] Support for Multipart/MIME > > > Hi, > > >The now-expired draft > http://tools.ietf.org/html/draft-jennings-sipping-multipart-02 > >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". > > It doesn't always have to be about picking what is best. > > For example: > > Assume a terminal supports audio and video. If both audio and > video are > used, it supports codecs audio_X and video_X. > > However, if only audio OR video are used, the terminal has more > resources available, to it could use the more-resource-using codecs > audio_Y and video_Y. > > In this case I don't think it's about picking based on what > is "better", > it's about picking based on what will be used for the session. > > Now, I am sure there are other ways of doing this, but this solution > would not require support of any SDP extensions (multipart/alternative > would of course have to be supported), and the same port > number could be > used for the audio and/or media m= lines in all alternatives.
Using the same port number on multiple m= lines has been, and continues to be, a direct violation of several SDP specifications. Even the SDP grouping specification explicitly calls this out as illegal. Draft-ietf-mmusic-sdp-capability-negotiation is 100% backwards compatible with endpoints that don't understand it. Multipart/ alternative will never share that characteristic; the last SIPIT showed how poorly multipart is supported today and there is no way, when you build an offer, to know if all of the answerers will understand multipart/alternative. HERFP rears its head, too. I had thought there was consensus around the need for draft-ietf-mmusic-sdp-capability-negotiation -- I am mistaken? -d > Regards, > > Christer > > > > > > > >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
