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".
The creator of the multipart/alternative has the job of picking which is
the better one. By definition they alternatives are ordered with the
preferred one last. (There is an assumption the the the preferred one is
the least widely implemented, and the least preferred one is the most
widely implemented.) You are supposed to process the *last* one that you
are *capable* of processing.
But your point still remains. If there are two SDP alternatives, how do
you decide if you can implement the last one? You are allowed to ignore
much of SDP if you don't understand it. But is that supporting it?
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.
Or just clearly define what it means to support one in an alternative.
Paul
-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
