[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
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
> -----Original Message-----
> From: Bob Gilman [mailto:bob_gilman at comcast.net]
> Sent: den 6 mars 2008 21:45
> To: Ingemar Johansson S
> Cc: mmusic at ietf.org
> Subject: 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