[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
Ingemar-
My comments below.
-Bob
-------------------------------------------------------------
Bob Gilman bob_gilman at comcast.net 303 898 9780
Ingemar Johansson S wrote:
> 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...
[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?
>
> /Ingemar
>
>
>
>
>>> Regards
>>> Ingemar
>
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic