[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] Comments/nits on draft-ietf-mmusic-sdp-media-capabilities-03.txt
Hi
Slow response... Sorry
Some comments below
/Ingemar
> -----Original Message-----
> From: Bob Gilman [mailto:bob_gilman at comcast.net]
> Sent: den 29 februari 2008 19:28
> To: Ingemar Johansson S
> Cc: mmusic at ietf.org
> 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 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?
[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
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic