I want to make it clear that I view draft-ietf-mmusic-sdp-capability-
negotiation as a better solution to the selecting RTP / SRTP problem
that the draft-jennings-sipping-multipart. (draft-jennings-sipping-
multipart was premised on the idea that the SRTP keys would be
transported with S/MIME which is not as good a solution as the DTLS
solutions). More importantly, the RTP/SEC bofs and MMUSIC WG selected
draft-ietf-mmusic-sdp-capability-negotiation as the way forward the
problem of saying you can do RTP and SRTP but would prefer SRTP. I
don't want to be opening that debate or anything about transitions to
the SDPng.
However, even thought we don't need multipart for the above problems
- I still think we need it so that we have some extensibility model
for SIP body parts.
Cullen <with my individual hat on>
PS ... The picking which body to use is not hard - for mutlipart/
alternative you use the last one that you understand.
On May 9, 2007, at 12:15 PM, 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
