RE: [Sip] Support for Multipart/MIME

["Dan Wing" <[e-mail]>]

 

> -----Original Message-----
> From: Christer Holmberg (JO/LMF) 
> [mailto:[e-mail]] 
> Sent: Wednesday, May 09, 2007 6:55 PM
> To: Dan Wing; [e-mail]
> Cc: [e-mail]
> 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:[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