Subject: [MMUSIC] Comments on draft-ietf-mmusic-sdp-media-capabilities-06

From: "Ingemar Johansson S" <[email-masked]>
Date: Tue, 24 Feb 2009 11:15:22 +0100

Hi

I have read through the last version of the SDP media Capabilities negitiation draft. 
Some comments below. 

That said...., it pains me to see that the interest in this is soooo low. 
I believe that the authors would welcome more response to make this become an RFC, it would be really sad if this work eventually shares the same fate as SDPng just because the rest of the world did not see the immediate benefit.
You may not see the killer use cases today, perhaps there are no killer use cases around but I have a strong feeling that the strengths of SDPCapNeg and its extensions will show up when whe start to look at capability exchange and negotiation of "richer media".

Regards
Ingemar

==============================
I believe the draft is in a good shape. 
Possibly I wonder if it is not a better idea after all to move the a=bcap (bandwidth capability) back to this draft ?, this because I beleieve bandwidth capabilities is strongly related to this draft anyway.

1) Section 3.3.4.1 : 
 I believe the ABNF is correct, however I believe that the line
  m=["+"]<med-cap-list> *["|"<med-cap-list>]
 should read
  ["+"]m=<med-cap-list> *["|"<med-cap-list>]  ?
2) Section 3.3.4.2 : 
 I believe 1*WSP should be removed ?

3) Section 3.3.5 :
  [Editors note: it could simplify processing if
   all capabilities referenced by latent or potential configurations
   became media-level attributes/capabilities when transformed into
   media configurations.  Are there examples where session-level
   attributes must be negotiated at the media level?  Perhaps we need
   some sort of "session configuration" or "scfg=" to handle the
   session-level fields.  Perhaps that could be somehow added to the
   sescap attribute defined below.]
  Personally I don't see the use case.

4) Section 3.3.8
   [Editors' note: We have considered a form of the lcfg: attribute that
   would permit an offerer to indicate that the configuration is
   available for immediate acceptance via an answer with a corresponding
   (new) m-line in the answer.  This would permit the establishment of
   the media streams to take place in one SDP exchange; at the same
   time, non-negotiating endpoints could be offered a simple
   configuration as in the above example.  Ultimately, when all
   endpoints understand the current specification, this would permit an
   offer with latent configurations only, and an answer with the m-lines
   for the accepted media streams.]
  I would believe that this could be specified in a future version, 
  possibly with a new option tag especially as the (new) m-line thing can cause some havoc elsewhere.

/Ingemar
******************************************* 
Ingemar Johansson 
Senior Research Engineer, IETF "nethead" 
EAB/TVP - Multimedia Technologies 
Ericsson Research Ericsson AB 
Box 920 S-971 28 Luleå, Sweden 
Tel: +46 (0)10 7143042 
ECN: 852-43042 
ECC: 852-19042
Mobile: +46 (0)730 783289 
Visit http://labs.ericsson.com !
*******************************************

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 24 Feb 2009 12:25:31 -0800

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ingemar Johansson S
> Sent: Tuesday, February 24, 2009 2:15 AM
> To: [email-masked]
> Subject: [MMUSIC] Comments on 
> draft-ietf-mmusic-sdp-media-capabilities-06
> 
> Hi
> 
> I believe that the authors would welcome more response to 
> make this become an RFC, it would be really sad if this work 
> eventually shares the same fate as SDPng just because the 
> rest of the world did not see the immediate benefit.
> You may not see the killer use cases today, perhaps there are 
> no killer use cases around but I have a strong feeling that 
> the strengths of SDPCapNeg and its extensions will show up 
> when whe start to look at capability exchange and negotiation 
> of "richer media".

I strongly support draft-ietf-mmusic-sdp-media-capabilities.  It
is necessary to allow negotiating AVP versus AVPF versus SAVP 
versus SAVPF (and whatever is defined later), and as you say
will help complex combinations of audio and video media -- which
we are all anxious to deploy and use.

Unlike SDPng, SDP Capabilities Negotiation is backwards 
compatible with plain SDP.  To deploy SDPng, every SIP 
element (UA, B2BUA, SBC, proxy) on the path had to handle
multipart MIME, but supporting multipart MIME wasn't required 
in RFC3261.  Hence, SDPng could never see deployment for
years and years after multipart MIME was declared mandatory.

SDP Capabilities Negotiation does not suffer from SDPng's
flaw.  SDP Capabilities Negotiation should be advanced.

-d

> Possibly I wonder if it is not a better idea after all to 
> move the a=bcap (bandwidth capability) back to this draft ?, 
> this because I beleieve bandwidth capabilities is strongly 
> related to this draft anyway.
> 
> 1) Section 3.3.4.1 : 
>   possibly with a new option tag especially as the (new) 
> m-line thing can cause some havoc elsewhere.
> 
> /Ingemar
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Bob Gilman <[email-masked]>
Date: Tue, 24 Feb 2009 14:33:01 -0700

Ingemar-
Thanks for looking at this draft.  My responses below.
-Bob

Ingemar Johansson S wrote:
> Possibly I wonder if it is not a better idea after all to move the a=bcap (bandwidth
> capability) back to this draft ?, this because I beleieve bandwidth capabilities is
> strongly related to this draft anyway.
> 
> 1) Section 3.3.4.1 : 
[rrg]: You're correct.

>  I believe 1*WSP should be removed ?
[rrg]: Do you mean section 3.3.4.3?  If so, you're correct.
>   Personally I don't see the use case.
[rrg]: Are you saying it would be OK to restrict capabilities referenced
        by potential or latent configurations to media level only?
>   can cause some havoc elsewhere.
[rrg]: I have no problem with deferring such work until such time as
        capability negotiation is ubiquitous.
> /Ingemar

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

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 24 Feb 2009 23:08:55 +0100

Hi, 

>I strongly support draft-ietf-mmusic-sdp-media-capabilities.  It is necessary to allow negotiating AVP versus AVPF versus SAVP versus SAVPF (and whatever is defined later), and as you say will help 
>complex combinations of audio and video media -- which we are all anxious to deploy and use.
>
>Unlike SDPng, SDP Capabilities Negotiation is backwards compatible with plain SDP. 
>
>To deploy SDPng, every SIP element (UA, B2BUA, SBC, proxy) on the path had to handle multipart MIME, but supporting 
>multipart MIME wasn't required in RFC3261.

I think the SIP body handling draft does require it, doesn't it?

Regards,

Christer

> Possibly I wonder if it is not a better idea after all to move the 
> a=bcap (bandwidth capability) back to this draft ?, this because I 
> beleieve bandwidth capabilities is strongly related to this draft 
> anyway.
> 
> 1) Section 3.3.4.1 : 
>   m=["+"]<med-cap-list> *["|"<med-cap-list>]  should read

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 24 Feb 2009 14:17:51 -0800

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: Tuesday, February 24, 2009 2:09 PM
> To: Dan Wing; Ingemar Johansson S; [email-masked]
> Subject: RE: [MMUSIC] Comments on 
> >I strongly support draft-ietf-mmusic-sdp-media-capabilities. 
>  It is necessary to allow negotiating AVP versus AVPF versus 
> SAVP versus SAVPF (and whatever is defined later), and as you 
> say will help 
> compatible with plain SDP. 
> >
> >To deploy SDPng, every SIP element (UA, B2BUA, SBC, proxy) 
> on the path had to handle multipart MIME, but supporting 

Yes.  But nothing requires someone to implement that once
it becomes an RFC.  Multipart MIME should have been a MUST
in RFC3261; this was an oversight (I can only guess).

-d

> >    endpoints understand the current specification, this 
> would permit 
> > an

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Wed, 25 Feb 2009 08:20:08 +0100

Hi

Comments to the ed. note in section 3.3.5. 

Regards
Ingemar

> From: Bob Gilman [mailto:[email-masked]] 
> Sent: den 24 februari 2009 22:33
> To: Ingemar Johansson S
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Comments on 
> > You may not see the killer use cases today, perhaps there 
> are no killer use cases around but I have a strong feeling 
> that the strengths of SDPCapNeg and its extensions will show 
> up when whe start to look at capability exchange and 
> negotiation of "richer media".
> > 
> > Regards
> > Ingemar
> > 
> > a=bcap (bandwidth
> > capability) back to this draft ?, this because I beleieve bandwidth 
> > capabilities is strongly related to this draft anyway.
> > 
> > 1) Section 3.3.4.1 : 
Yes :-)

>  [rrg]: Are you saying it would be OK to restrict capabilities 
>   referenced by potential or latent configurations to media level only?
Not sure if I overlook something, as far as I can see I don't see any problem with this restriction.I don't currently see any need for a session configuration. Also, isn't there a risk in letting session level attributes be negotiated on the media level. What happens if a potential configuration for one media implies a change on a session level attribute that also has a meaning for another media. That said I suspect that I don't perhaps see the full picture, hope that others chime in. 

> would permit an

---

From: Bob Gilman <[email-masked]>
Date: Thu, 26 Feb 2009 13:47:02 -0700

Ingemar-
Your concern about conflicting session-level fields arising from
media-level choices is what prompted me to suggest the restriction
of capabilities to the media level.  I certainly don't want capability
processing to be burdened with choosing a set of media options in
such a way that no conflicts arise at the session level.
-Bob
-------------------------------------------------------------
Bob Gilman        [email-masked]      +1 303 898 9780