Subject: FW: Cisco SG16: Local negotiation

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 3 Feb 2000 19:07:25 -0500

Resend.

> -----Original Message-----
> From: Taylor, Tom-PT [CAR:B904:EXCH]
> Sent: Thursday, February 03, 2000 3:08 PM
> To:   'Chip Sharp'; [email-masked]
> Subject:      RE: Cisco SG16: Local negotiation
>
> Responses to the points below:
> (1) Current text definitely supports asymmetry.  Local and Remote can
> specify different codecs, both of which are supported.  However, if
> multiple alternatives are presented in Local and Remote, the selection
> procedure is biassed toward symmetry.
>
> (2) Proposed third alternative (report all capabilities, reserve for only
> one) seems like an optimization.  It isn't really consistent with SDP.
>
> (3) SDP itself says that multiple entries on the m= line must all be
> supported:
>
>      When a list of payload formats is given, this implies that all of
>      these formats may be used in the session, but the first of these
>      formats is the default format for the session.
>
>
> -----Original Message-----
> From: Chip Sharp [SMTP:[email-masked]]
> Sent: Tuesday, January 25, 2000 7:47 PM
> To:   [email-masked]
> Subject:      Cisco SG16: Local negotiation
>
> Section:        7.1.8, second paragraph
> Category:       Open Issue
> Issue:          The draft text specifies that "Local is the capability of
> the local
> MG and is typically sent from MG to MGC, and subsequently used as part of
> a
> capability negotiation between two MGCs. Remote contains the parameters
> describing the flows the remote MG will send/receive, is typically sent
> from MGC to MG, and is the result of the capability negotiation". The
> details of this negotiation as well as how it interacts with
> LocalControlDescriptor and the network package defined in Annex E.9 is
> unclear and needs further clarification. In particular, it is not clear:
>
> *       that the specification adequately supports media streams with
> asymmetric
> send and receive capabilities.
> *       when negotiated media resources are reserved and they are
> available for use
> It should be noted, that this particular issue has been the subject of
> much
> debate on the IETF Megaco mailing list since the white contribution was
> developed, and that at time of writing, no resolution had been found.
> Discussion:             Given the fact, that solving this issue is at the
> heart of the
> very purpose of the protocol, it is recommended that additional work to
> develop a solution that satisfies the protocol requirements [1] in this
> area is done.
>
> v13 Status:             Modified. INADEQUATE. Above text has been removed
> and replaced
> with extensive new text, incl. description of "Reserve" parameter in
> Section 7.1.7 which provides for:
> *       Return all alternatives supported and currently capable, and
> reserve
> sufficient resources for any one of those.
> *       Return one alternative, and reserve sufficient resources for that
> one.
> In addition to these two options, a third option is proposed:
> *       Return all alternatives supported and currently capable, but only
> reserve
> sufficient resources for one alternative selected.
> This will allow each endpoint to learn the capabilities of the other
> without requiring that simultaneous support for each alternative. This may
> be required when codecs (or other associated resources, e.g. external
> resource reservation) can not be activated nearly instantaneously.
> Also, how does this interwork with SIP, etc., i.e. other protocols that
> use
> SDP ? For example, it does not seem to be legal to only support a subset
> of
> the codecs listed in an "m=" line which is somewhat problematic.
>
>
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 7 Feb 2000 20:06:59 -0500

Hi Tom

We've taken another look at the media negotiation text in v14 and have the
following comments:

1. The MG should be required to return RFC 2327 conformant SDP (the MGC on the
other hand obviously cannot be required to send conformant SDP)

2. The MG should be allowed the MG to select a subset of codecs in a given "m="
line rather than requiring all or nothing.

3. Do not attempt to force synchronous coding, but let the order of first Local
and then Remote guide the process instead. Possible (and probably better)
alternatives here include:
- Add a LocalControl parameter that can specify if symmetry is required or not
- Consider Local and Remote to be pairs, i.e. if Local number X is chosen then
Remote number X is chosen as well.

I've added a couple of comments below.

> > procedure is biassed toward symmetry.

That is somewhat unfortunate as you are dictating policy in the protocol. As it
turns out, there are actually some cases where you do not want symmetric codecs
(maybe not so surprising after all when we consider the typical bandwidth
asymmetry we find on Cable and xDSL)

> > one) seems like an optimization.  It isn't really consistent with SDP.

You're right. We'll defer that one.

> >      formats is the default format for the session.

Maybe I lost track of the thread, but there doesn't seem to be an issue here.

> > Support NetAid!  http://www.netaid.org

Regards

        Flemming

--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------