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

[Bob Gilman <bob_gilman at comcast.net>]

Ingemar-
Thanks for your comments.  My specific replies are embedded
below.
-Bob
-------------------------------------------------------------
Bob Gilman         bob_gilman at comcast.net        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?
> 
> Regards
> 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)8 4043042
> ECN: 850-43042
> ECC: 850-43074
> Mobile: +46 (0)730 783289
> *******************************************
>   
> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic at ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> 


_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic