Subject: [MMUSIC] SDP Capability Design Team: Topics for discussion

From: Flemming Andreasen <[email-masked]>
Date: Tue, 20 Mar 2007 14:06:32 -0400

Topics for discussion

_Core SDP Capability Negotation_

·        To add replace, or delete attributes

·        Inconsistent media-level selection of session-level attribute 
capabilities

·        One option is to explain the issue and recommend that people 
avoid using session-level capabilities for cases where such 
inconsistencies may occur.

·        At most one "tcap" attribute at the session and/or media-level, 
or one or more "tcap" attributes at the session and/or media-level ?

·        Does 3PCC introduce a need to always include "creq" with base 
option tag  (currently, we just look for "pcfg" attributes).

·        Extensions: Do we need to say more about their syntax and 
semantics than we currently do, and if so what ?

·        Media before answer - do we want to say more than what is in 
there (e.g. Jonathan's STUN proposal, or possibly other mechanism ?)

·        Second offer/answer exchange.

·        MAY, SHOULD or MUST ? ICE is at MUST - why ?

·        General procedure for creating offer SDPs using SDP capability 
negotiation (use of various attributes)

·        Rename "tcap" to "tpcap" ?

_Media Capabilities_

·         

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

---

From: "Franceschini Guido" <[email-masked]>
Date: Tue, 20 Mar 2007 19:27:07 +0100

Just my 2 cents.
 
Given that the goal is to combine in a single SDP the combination of N possible alternatives, it is maybe more human and machine friendly to have an assertive syntax instead of a differential one.
 
I mean:
instead of (in the SDP):
- listing the default attributes
- listing with an explicit identifier the extra attributes
- listing in the configuration line the identifiers of the extra attributes plus the rules to deal with the inconsistencies
and in the SDP decoder:
- taking the default attributes
- adding the attributes indicated by the configuration
- applying the rules to deal with the inconsistencies
 
organize the flow as follows:
- define rules to assign to each default attribute an implicit identifier
(in the SDP):
- list the default attributes (each one will get an implicit Id)
- list with an explicit identifier the extra attributes
- list in the configuration line both the implicit identifiers of the default attributes and the explicit identifiers of the extra attributes
and in the SDP decoder:
- use the attributes indicated by the configuration
 
Best regards
Guido

________________________________

From: Flemming Andreasen [mailto:[email-masked]]
Sent: Tue 3/20/2007 7:06 PM
To: mmusic
Subject: [MMUSIC] SDP Capability Design Team: Topics for discussion

Topics for discussion 

Core SDP Capability Negotation

·        Inconsistent media-level selection of session-level attribute capabilities 

·        One option is to explain the issue and recommend that people avoid using session-level capabilities for cases where such inconsistencies may occur.

·        At most one "tcap" attribute at the session and/or media-level, or one or more "tcap" attributes at the session and/or media-level ? 

·        Does 3PCC introduce a need to always include "creq" with base option tag  (currently, we just look for "pcfg" attributes). 

·        Extensions: Do we need to say more about their syntax and semantics than we currently do, and if so what ? 

·        Media before answer - do we want to say more than what is in there (e.g. Jonathan's STUN proposal, or possibly other mechanism ?)

·        General procedure for creating offer SDPs using SDP capability negotiation (use of various attributes)

 

Media Capabilities

·         

--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [email-masked].

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 20 Mar 2007 16:00:42 -0400

The problem with implicit identifiers is that any kind of middle-box 
that either adds, deletes, or reorders these attributes will completely 
mess it up. That's why we have explicit capabilities and identifiers for 
everything we use.

Thanks

-- Flemming