Subject: RE: [Megaco] Clarification on MG handling of Local & RemoteDescriptors

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 6 Jul 2005 15:05:21 -0400

Underspecification is allowed in the MGC->MG direction, as stated in
clause 7.1.8 of H.248.1.

Kevin 

-----Original Message-----
From: Pascal Lambers [mailto:[email-masked]] 
Sent: Wednesday, July 06, 2005 2:49 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Kamitses, Jerry; [email-masked]
Subject: Re: [Megaco] Clarification on MG handling of Local &
RemoteDescriptors

Hi,
I thought that underspecifiying the codec list as done below by means of
"m=audio 5000 rtp/avp $ " is not a valid syntax, according to RFC 2327?

Kind regards,
Pascal

----- Original Message -----
From: "Kevin Boyle" <[email-masked]>
To: "Kamitses, Jerry" <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 06, 2005 5:18 PM
Subject: RE: [Megaco] Clarification on MG handling of Local &
RemoteDescriptors

> Comments inline. [KJBII]
>
> Kevin
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Kamitses, Jerry
> Sent: Wednesday, July 06, 2005 11:02 AM
> To: [email-masked]
> Subject: RE: [Megaco] Clarification on MG handling of Local &
> RemoteDescriptors
>
> ... additional comment on this topic (after additional research and
> discussion) ...
>
> A particular case for the MG supplying information in the returned
Local
> Descriptor beyond that which was present in the received Local
> Descriptor occurs when the received Local Descriptor is underspecified
> through use of CHOOSE in a property value (as discussed in Section
7.1.8
> Local and Remote descriptors).
>
> So for the payload selections in the "m=audio ..." parameter, if the
MGC
> sends $ as the payload list,
>           m=audio 5000 rtp/avp $
> then the MG can return as many payload numbers as it likes, ordered by
> preference.
> In particular, if the MG wishes to include 2833 as an option, it would
> return the info necessary in the SDP along with whatever other codecs
it
> may wish to choose.
>
> Consequently the gist of original question is now:
>
> (1) whether there are any other instances where the MG can exercise
this
> option to supply payload numbers beyond those in the Local Descriptor
> from the MGC, and
> [KJBII] The MG may only choose options within the constraints set by
the
> MGC.  If the MGC sends $, then the MG can choose whatever it wants.
>
> (2) for the particular example of CHOOSE above, are their any
guidelines
> or additional implied requirement for the MG when responding to such a
> choose?
> For example, should/must the MG attempt to include payload values
> present in the last received Remote descriptor.
> [KJBII] There is no requirement to do so, though many MGs do try to
> align the Remote and Local descriptors.
>
> One final question pertains to the following text from the standard
> (from Section 7.1.7 LocalControl descriptor)
>
>    If the value of a Reserve property is False, the MG SHALL choose
>    one of the alternatives specified in the Local descriptor (if
> present)
>    and one of the alternatives specified in the Remote descriptor (if
>    present).  ... Finally, the MG shall send a reply to the MGC
>    containing the alternatives for the Local and/or Remote descriptor
>    that it selected.
>
> Is the above text claiming that the MG can send a Remote Descriptor as
> well as Local Descriptor in the reply message ?
> [KJBII] If the Remote descriptor is underspecified, then yes.
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
Behalf
> Of Kamitses, Jerry
> Sent: Tuesday, July 05, 2005 7:48 PM
> To: [email-masked]
> Subject: [Megaco] Clarification on MG handling of Local & Remote
> Descriptors
>
>
>
> A question has arisen during interop testing regarding the extent
> to which the content of Local and Remote Descriptors sent to an MG
> termination by the MGC are intended to limit the content of any
> Local Descriptor returned by that MG termination in a response
message.
>
> The question concerns whether the Local Descriptor in the MG
> termination's
> response must always be a subset of the last Local Descriptor sent to
> that
> termination or whether there are circumstances where the MG
termination
> is
> free to include additional information in the response Local
Descriptor.
>
> For example, are there situations where the content of the Remote
> descriptor
> must or may effect the content of the Local Descriptor the MG returns?
>
> In particular, if the last received Remote descriptor contains
> information
> not present in the last received Local descriptor then is the MG free
to
>
> use any/all of the Remote Descriptor contents in addition to the
> last received Local Descriptor when selecting the Local Descriptor to
> return?
>
> Specifically, what are the rules regarding SDP media parameters in the
> response.
> If, for example, the Local and Remote descriptors
> sent to the MG are
>      Local {
>           v=0
>           o=- $ 0 IN IP4 $
>           c=IN IP4 $
>           m=audio $ RTP/AVP 8
>      },
>      Remote {
>           v=0
>           o=- 0 0 in ip4 100.23.14.82
>           c=in ip4 100.23.14.82
>           m=audio 5000 rtp/avp 18 101
>     a=rtpmap:101 telephone-event
>           a=fmtp:101 0-15
> }
>
> then can the MG choose to return the following Local Descriptor?
>      Remote {
>           v=0
>           o=- 0 0 in ip4 98.14.23.123
>           c=in ip4 98.14.23.123
>           m=audio 6348 rtp/avp 18 101
>     a=rtpmap:101 telephone-event
>           a=fmtp:101 0-15
> }
>
> Do dynamic payloads based on RFC 2833 handled require any special
> treatment
> in this regard? For example, if the Remote Descriptor contains a
> telephone-event
> rtpmap and the Local Descriptor does not, then can the MG choose to
> include
> a telephone-event rtpmap in the Local Descriptor it returns?
>
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco
>
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco
>
>
>
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco
>
>

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco