RE: [Sip] Support for Multipart/MIME

["Christer Holmberg \(JO/LMF\)" <[e-mail]>]

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:[e-mail]]
> > > > Sent: Thursday, May 03, 2007 3:50 AM
> > > > To: [e-mail]; [e-mail]
> > > > 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: [e-mail] [mailto:[e-mail]]
> > > > > Sent: 30. huhtikuuta 2007 19:13
> > > > > To: [e-mail]
> > > > > Subject: Re: [Sip] Support for Multipart/MIME
> > > > > 
> > > > >    From: Cullen Jennings <[e-mail]>
> > > > > 
> > > > >    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 
> > > > > [e-mail] for questions on
> > current sip Use
> > > > > [e-mail] 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 
> > > > [e-mail] for questions on 
> current sip Use 
> > > > [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip