Hi, Comment at the end.
> > >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-- > > This can be expressed with MMUSIC's capabilities negotiation, > though -- and can be expressed better than with > multipart/alternative because MMUSIC's capability negotiation > defines preferences of each m= and each a= line, whereas > multipart/alternative can only ever allow simple "take all of > this SDP" or "take none of this SDP". > > (With the specific example you show, of course, you don't > even need MMUSIC's capabilities negotiation -- an answerer > that doesn't support video (or doesn't support audio) can > already indicate that in its SDP answer.) The point is that, depending on what media the answerer chooses, different codecs can be used for chosen media streams. Yes, "vanilla" SDP allows me to offer audio and video, and the answerer can incdicate what it does/doesn't support. But, vanilla SDP does not allow the offer to say: "Here is audio and video. If you accept both then let's use these codecs, but if you only choose audio then let's use theis other codec". Regards, Christer > > -d > _______________________________________________ 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
