Subject: [MMUSIC] Some Questions on cap-negotiation draft and media-cap draft

From: "David Oz" <[email-masked]>
Date: Wed, 17 Sep 2008 19:57:28 +0300

Hi,

I would like to ask a few questions regarding the drafts:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-capability-negotiation-
09.
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-media-capabili
ties-05.txt

1.	I don't fully understand the relationship between these 2
drafts. On the one hand, the sdp-cap-negotiation is the general
framework and the basis for the new offer-answer model and the 2nd draft
(media-capabilities) is more detailed and applicative. But when getting
into details of the 2 drafts, there are some contradictions between
them. It seems that media-cap draft is more mature and practical. The
questions are: 
		Does anyone know of a real application based on cap-nego
draft (and not relying media-cap draft)? How does the working-group plan
to settle the contradictions between the 2 drafts?
2.	It is not clear what is the goal of sending the extra re-INVITE
with the actual offer-answer (using existing SDP format) for
intermediaries (section 3.12 of sdp-capability-negotiation):
a.	It is optional.
b.	If the intermediary needs to be on the flow of the media, it
will quite surely miss the beginning of the media-transmission, when it
receives the media-info only at this stage (the re-INVITE), as SIP model
allows starting sending media as soon as you know your peer's
capabilities.
3.	And one general question, what is the motivation to moving to
these drafts? Which applications can be based on them? (besides the few
examples that are in the drafts)

Thanks,
David O.
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Bob Gilman <[email-masked]>
Date: Wed, 17 Sep 2008 13:20:07 -0600

David-
I'll try to answer your questions; I'm trusting Roni and Flemming will
pitch in and clarify/correct any of my errors and/or omissions.
-Bob

David Oz wrote:
> _http://tools.ietf.org/html/draft-ietf-mmusic-sdp-capability-negotiation-09_.
> 
> _http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-media-capabilities-05.txt_
> 
> 1.      I don’t fully understand the relationship between these 2 
> framework and the basis for the new offer-answer model and the 2^nd 
> draft (media-capabilities) is more detailed and applicative. But when 
> getting into details of the 2 drafts, there are some contradictions 
> between them. It seems that media-cap draft is more mature and 
> practical. The questions are:
> 
>             draft (and not relying media-cap draft)?
[rrg]: The initial requirement - the ability to offer media with or
        without encryption - is satisfied by the CapNeg draft, which
        permits negotiation of transport protocol (e.g., RTP/SAVP or
        RTP/AVP) and crypto attributes (or lack thereof.)
 >
>               .... How does the
>             working-group plan to settle the contradictions between the
>             2 drafts?
[rrg]: Can you be more specific about the contradictions?  BTW, it's OK
        for an "extension specification" to override aspects of the base
        spec (e.g., as specified for certain media attributes in the
        Media-Cap draft.)
> intermediaries (section 3.12 of sdp-capability-negotiation):
[rrg]: It's not necessary for the end parties, but it's intended to
        inform any intermediaries such as firewalls which don't
        understand the capability negotiations.  It doesn't solve all
        of the problems that old intermediaries can cause, but it helps.
> a.      It is optional.
[rrg]: Eventually, the second exchange should be redundant in all cases.
        Right now, it's certainly redundant if the answerer chooses the
        base configuration.  Ultimately, firewalls and NATs must be
        able to understand the cap exchange items if they are to function
        at their best.
> allows starting sending media as soon as you know your peer’s capabilities.
[rrg]: My own feeling is that the second exchange should be done only
        when necessary.  But it's not clear to me how an endpoint
        discovers such an exchange is necessary.  I suppose the receipt
        of an answer before any media or an expected DTLS-SRTP exchange
        might indicate that a firewall wasn't happy, but who knows?
> these drafts?
[rrg]: The problem of negotiating encrypted or clear media is real and
        current, and was deemed sufficient to justify the work of the
        base draft.  The media-cap draft was motivated by the desire to
        solve several problems, among them the negotiation of complex
        codec parameter combinations, flexible media configurations,
        and preferences.
>          ...  Which applications can be based on them? (besides the few 
[rrg]: Who knows?  We tried to be sufficiently general to permit known
        uses, without restricting what might be done in the future.  We
        wanted to include most of the capabilities available in "heavy"
        protocols like H.245, without incorporating all the baggage.
        For example, one can offer a media session with multiple media
        streams, along with supportable media encodings and parameters,
        etc., and the answerer can select the preferred configuration
        and indicate which offered media streams, encodings, and
        parameters it can support - all in one exchange.  You can't do
        that in H.245 - even with H.460.6.
> Thanks,
[rrg]: You're welcome.  I hope this answers your questions.
> 
> David O.
> 
> 
> ------------------------------------------------------------------------
> 

-------------------------------------------------------------
Bob Gilman        [email-masked]      +1 303 898 9780

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 18 Sep 2008 07:39:00 +0200

Hi

As regards to use cases for the SDP Capability Negotiation Framework you
may want to have a look at the 3GPP document below.
http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_50/Docs/S4-080503.zip 
The use cases for SDP Media Capability negotiation is not clear yet.
There are for sure use cases but they must be weigthed against factors
such as implementation complexity and impact on other functions in the
network

Regarding the need for a 2nd offer/answer I have always understood it as
that the 2nd offer/answer is only needed if the actual configuration
(a=acfg) and the 1st answer SDP is uncorrelated, if an intermediate node
for some reason rewrites the m line in the 1st answer the SDP and the
actual configuration is uncorrelated and it is quite easy to detect
this. Sofar I have not found any error in that assumption, please let me
know if I missed some important fact here.

Contradictions: I have really tried to read the drafts front to back and
although the framework may be complex to grasp in the beginning I have
not found too many contradictions, the only one I can remember is about
the tcap numbering which is unique for each media in one draft and
unique for the whole SDP in the other.

Regards
/Ingemar

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bob Gilman
> Sent: den 17 september 2008 21:20
> To: David Oz
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Some Questions on cap-negotiation draft 
> and media-cap draft
> 
> David-
> I'll try to answer your questions; I'm trusting Roni and 
> Flemming will pitch in and clarify/correct any of my errors 
> and/or omissions.
> -Bob
> 
> David Oz wrote:
> > Hi,
> > 
>         RTP/AVP) and crypto attributes (or lack thereof.)  >
> >               .... How does the
> > will quite surely miss the beginning of the 
> media-transmission, when 
> > it receives the media-info only at this stage (the 
> re-INVITE), as SIP 
> > model allows starting sending media as soon as you know 
> your peer's capabilities.
> >          ...  Which applications can be based on them? (besides the 
> > few examples that are in the drafts)