Hi, >>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.
Yes. But in the multipart/alternative example I gave you (and which is ilustrated in a simple form below) would have 3 individual SDP bodies, and the same port number would not be used within a single SDP bodies. But, the same port number would be used in each indivudual SDP body, and as far as I know there is no specification which forbids that. -----boundary m=audio 9999 audio_x m=video 7777 video_x -----boundary m=video 7777 video_y -----boundary m=audio 9999 audio_y -----boundary-- Regards, Christer >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
