It's possible/probable/obvious (depending on who you talk to) that
multipart will have to be supported for emergency calling, in which
there is an SDP body and a Location message body...
This doesn't mean UAs that *don't* establish voice/video dialogs will
have to support multipart, just for those UAs that do establish
voice/video dialogs with emergency response centers (again, depending
on who you talk to).
At 02:15 PM 5/9/2007, Dan Wing wrote:
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". 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
_______________________________________________
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
