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

From: "Ingemar Johansson S" <[email-masked]>
Date: Fri, 29 Feb 2008 08:42:16 +0100

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

==========
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

==========
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
...

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).

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
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Bob Gilman <[email-masked]>
Date: Fri, 29 Feb 2008 11:27:53 -0700

Ingemar-
Thanks for your comments.  My specific replies are embedded
below.
-Bob
-------------------------------------------------------------
Bob Gilman         [email-masked]        303 898 9780

Ingemar Johansson S wrote:
> "AMR/16000/1" should be replaced by "AMR-WB/16000/1" according to
 > http://www.iana.org/assignments/media-types/
[rrg]: My error; I'll fix it.
[rrg]: Your belief is correct - I left out the RTP/AVP term in the tcap.
[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 
> 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?