Subject: [MMUSIC] SDP Capability Negotiation: Updated solution document (-01)

From: Flemming Andreasen <[email-masked]>
Date: Sun, 28 Jan 2007 19:21:01 -0500

Greetings

I have just submitted an updated solution document as 
draft-ietf-mmusic-sdp-capability-negotiation-01.txt, which you can 
retrieve from 
http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capability-negotiation-01.txt 
until it appears in the archives.

The biggest change this time is to reduce the scope of the core 
framework to no longer include media capabilities - a solution for that 
will be provided in a separate document that will define it as an 
extension. Please refer to the change log for a more comprehensive list 
of changes

We will discuss this document in our next SDP Capability Negotiation 
design team call (1/30/07).

Thanks

-- Flemming

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 29 Jan 2007 09:12:12 +0200

Hi,

I would like to clarify that the design team based on email discussion has decided to divide the proposed solution for the capability negotiation, as specified in draft-ietf-mmusic-sdp-capability-negotiation-reqts-00 to a core part addressing mostly the profile negotiation and an extension that will be specified in a separate document addressing the media capabilities negotiation.

Note that the minimal implementation will need to support only the core part while extensions are optional.

Roni Even  

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Monday, January 29, 2007 2:21 AM
> To: mmusic
> Subject: [MMUSIC] SDP Capability Negotiation: Updated solution document (-
> 01)
> 
> Greetings
>

---

From: Joerg Ott <[email-masked]>
Date: Tue, 30 Jan 2007 01:03:00 +0200

Flemming,

thanks a lot for the updated document.  Looks good.
Two quick comments/questions:

Sect 2.1, example:

The answerer returns the following SDP:

    v=0
    o=- 24351 621814 IN IP4 128.96.41.2
    s=
    c=IN IP4 128.96.41.2
    t=0 0
    m=audio 4567 RTP/SAVP 0 18
    a=crypto:1 AES_CM_128_HMAC_SHA1_80
          inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4
    a=acfg: t=1 a=1

which means the desired shift from the backwards-compatible
plain AVP to SAVP, thus yielding best-effort SRTP.  In the
discussions around ICE there was consensus that, ultimately,
the m= lines should reflect what got actually negotiated (and
thus will be sent) to be kind-of-nice to middleboxes trying
to second-guess on what you are doing.  We should follow the
same approach here.

(In principle, we negotiate two independent RTP sessions,
so one direction might be protected while the other might
not, but this perception from observing just the m= lines
is not the semantics of the finally negotiated session.)

Do we want an updated offer/answer exchange (in 2.5.3)?

Sect 2.2.2, editorial?

The text states:

     When an entity does not support one or more required SDP capability
     negotiation extensions, the entity SHOULD proceed as if the SDP
     capability negotiation attributes were not included in the first
     place, i.e. all the capability negotiation attributes should be
     ignored.

Does this imply that the answerer SHOULD not provide any information
back to the offerer?  Wouldn't at least an a=csup: make sense?

Joerg

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 29 Jan 2007 20:50:04 -0500

> to second-guess on what you are doing.  We should follow the
Agreed - in general, there is more work to be done on the offer/answer 
procedures and I agree that the example should be updated accordingly to 
at least indicate that another O/A exchange should take place.
> is not the semantics of the finally negotiated session.)
Right  (although I disagree with the "two independent RTP sessions" 
part, but that's nit not worth arguing)
> Do we want an updated offer/answer exchange (in 2.5.3)?
Yes.
> back to the offerer?  Wouldn't at least an a=csup: make sense?
Yes - good point - will add in the next revision.

Thanks

-- Flemming
>> framework to no longer include media capabilities - a solution for 
>> that will be provided in a separate document that will define it as 
>> an extension. Please refer to the change log for a more comprehensive 
>> list of changes
>>