Subject: Re: [MMUSIC] Comments/nits on draft-ietf-mmusic-sdp-media-capabilities-03.txt

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 6 Mar 2008 12:47:53 +0100

Hi

Slow response... Sorry
Some comments below

/Ingemar 

> -----Original Message-----
> From: Bob Gilman [mailto:[email-masked]] 
> Sent: den 29 februari 2008 19:28
> To: Ingemar Johansson S
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Comments/nits on 
> draft-ietf-mmusic-sdp-media-capabilities-03.txt
> 
> Ingemar-
> Thanks for your comments.  My specific replies are embedded below.
> -Bob
> -------------------------------------------------------------
> Bob Gilman         [email-masked]        303 898 9780
> 
> Ingemar Johansson S wrote:
> > Hi
> > 
> > Some comments/nits on the draft:
> > 
> > ==========
> > In general
> > "AMR/16000/1" should be replaced by "AMR-WB/16000/1" according to
>  > http://www.iana.org/assignments/media-types/
> > "AMR/8000/1" is correct however
> [rrg]: My error; I'll fix it.
> > 
> > ==========
> > Page 8:
> > The example :
> >              a=tcap:1 RTP/SAVP
> > ..
> >              a=pcfg:3 m=4 t=2 pt=4:18
> > 
> > Makes me believe that the tcap line should be something like
> > 
> >              a=tcap:1 RTP/SAVP RTP/AVP
> > 
> > or as an alternative "t=2" should be removed from the 
> "a=pcfg:3" line
> [rrg]: Your belief is correct - I left out the RTP/AVP term 
> in the tcap.
> > 
> > ==========
> > A comment on section 3.3.3 (mscap)
> > This attribute makes it possible to formulate SDP's like 
> m=audio 4321 
> > RTCP/AVP ...
> > ...
> > a=mcap:1 AMR
> > a=mcap:2 telephone-event
> > a=mscap:1 sendrecv
> > a=mscap:2 sendonly
> > ...
> [rrg]: Interesting observation!  I'll have to add a statement
>         that the resulting conventional SDP must be legal, or
>         perhaps I should reorder the discussion to say
>         "for any legal SDP attributes of the form
>             a=<att-name>:<fmt> <...> <parameters>
>         one may associate the attribute and parameters with one or
>         more media capabilities via a new mscap attribute of the
>         form
> 	   a=mscap:<media-caps> <att-name> <parameters>
>         where ..."
> > 
> > It may be troublesome however to formulate the 1st answer 
> SDP and the 
> > 2nd pass offer/answer. As a "plain SDP" cannot do this.
> > Is there a way to solve this issue or should similar tricks 
> be forbidden?.
> > This problem is BTW formulated in
> > http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_47/Docs/S4-080027.zip
> > I believe that this extra liberty in SDPCapNeg+SDPMedCapNeg 
> can yield 
> > some interop issues unless they are addressed (perhaps they 
> are, I'm a 
> > slow reader).
> [rrg:] We certainly didn't intend to modify existing SDP 
> attributes, or
>         indirecctly create new ones.  On the other hand, if you can
>         write some capability in an offer like
>             a=ecap:1 PCMU/8000
> 	   a=mscap:1 foo bar
> 	   a=pcfg:1 m=1 pt=1:0
> 	and get the answerer to respond
> 	   m=audio 54321 RTP/AVP 0
> 	   a=rtpmap:0 PCMU/8000
> 	   a=foo:0 bar
> 	   a=acfg:1 m=1 pt=1:0
>          and get the offeror to buy it, then more power to you :-)
>          This is one reason I wanted to look at the mapping 
> of capability
>          attributes to/from what I called "conventional" SPD 
> lines.  If
>          the conventional line isn't legal, then neither is the
>          corresponding cap line, and vice versa.  That way, capability
>          processing doesn't need to duplicate validations that SDP
>          processing already does.  Does this make sense?

[IJ] If I get it all correct, It is possible to write a 1st offer that
is not possible to write using "conventional SDP" semantics. The 1st
answer must however be possible to write using "conventional SDP" (not
quite sure I believe). 
However the only reason I see why this is requirement is needed is
because of the recommended 2nd offer answer. If this did not take place
there would not be any need to have this requirement and it would
perhaps open up for more "power" in the session setup. I can understand
the idea to be more conservative and cautious however...

/Ingemar

> > Regards
> > Ingemar
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Bob Gilman <[email-masked]>
Date: Thu, 06 Mar 2008 13:45:10 -0700

Ingemar-
My comments below.
-Bob

> the idea to be more conservative and cautious however...
[rrg] On further thinking about it, I think there shouldn't be any new
       rule about what "conventional" SDP line(s) a capability attribute
       might produce.  The only rule is that the escap itself should be
       well formed.  Here's my thinking:
       1. Any session or stream that is offered and accepted must be
          expressible via conventional (non-capability) SDP lines.
          Capability negotiation doesn't add anything to the final
          stream(s) that couldn't have been offered and accepted using
          conventional SDP; it just adds alternatives and "futures".
       2. Different SDP implementations may recognize different SDP
          attributes as "legal"; the unrecognized ones are to be ignored.
          Therefore, any acap attribute that generates an unrecognized,
          malformed, or undefined attribute would, in effect, be ignored.
          It's my  suggestion that this effect would be a natural fallout
          of processing the capabilities in stages:
              a) translate to conventional SDP records,
              b) process each SDP record as usual.
          If any attributes are unrecognized or malformed in the second
          step, they are simply ignored as usual.  (That might be a
          problem for declarative attributes, but that problem is not
          unique to capability negotiation.)
       3. Just because one can use a cap neg attribute such as mscap
          to generate a heretofore unknown SDP attribute line shouldn't
          make that line legal or recognizable by the receiver of the
          SDP.  On the other hand, we've tried to make the capabilities
          attributes general enough that they don't need to be changed
          if new attributes, or new parameters for existing attributes,
          are defined by some new RFC.

Although your example tying directional attributes to media encodings
rather than the stream as a whole seems intriguing, I don't think we
should make it possible by simply using
          a=mcap:1 PCMU/8000
          a=mscap:1 sendonly
and assuming that's the same as if we could say
          a=sendonly:0
If we want to do such a thing, then we should legitimize the payload
type as a parameter to the sendonly attribute (and its kind), from which
the use of mscap for sendonly would be appropriate.
Is this more clear?

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Mon, 10 Mar 2008 15:41:16 +0100

Hi

My understanding of this is that it should suffice to have a (strict?)
requirement formulated like: 
"For _any_ 1st offer SDP using _any_ potential configuration as an
actual configuration in a subsequent 1st answer, it should be possible
to formulate valid "convetional" 2nd offer/answer SDP's regardless if
the 2nd offer anwer os used or not"
Does this sound like a reasonable rule ?.
Now the "devil" inside me would like to skip such a rule or only make it
"recommended" but then there is a big risk that a relaxed requirement
regarding this may lead to future interop issues.
Moreover, regardless what the conclusion is regarding this issue I
beleive that this belongs to the core draft rather than the media
capabilities draft.

Regards
Ingemar 

> Sent: den 6 mars 2008 21:45
> To: Ingemar Johansson S
> Cc: [email-masked]
> >> [rrg]: Your belief is correct - I left out the RTP/AVP term in the 
> >> tcap.
> >>> ==========
> attributes, 
> >> or
> >>          This is one reason I wanted to look at the mapping of 
> >> capability
> >>          attributes to/from what I called "conventional" 
> SPD lines.  
> >> If
> > because of the recommended 2nd offer answer. If this did not take 
> > place there would not be any need to have this requirement and it 
> > would perhaps open up for more "power" in the session setup. I can 
> > understand the idea to be more conservative and cautious however...
> Although your example tying directional attributes to media 
> encodings rather than the stream as a whole seems intriguing, 
> I don't think we should make it possible by simply using
>           a=mcap:1 PCMU/8000
>           a=mscap:1 sendonly
> If we want to do such a thing, then we should legitimize the 
> payload type as a parameter to the sendonly attribute (and 
> its kind), from which the use of mscap for sendonly would be 
> appropriate.
> Is this more clear?
> > 
> > /Ingemar
> > 
> > 
> >   
> > 
> >>> Regards
> >>> Ingemar
> > 
> 
> 
> 
>