Subject: RE: [Megaco] Reserve Value and Reserve Group

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 4 Jan 2002 10:56:32 -0500

I think we made a mistake when we added this IG item.  It will block us from
using the FID capability (draft-ietf-mmusic-fid-05.txt) that I refer to
below.  If other people feel the same way, we may want to modify the wording
to handle that case.

The same draft also provides a capability to indicate synchronization
dependencies between media streams.  Megaco will be unable to use this.
Back when we put the protocol together, I thought we would need something to
show which streams were related, but we chose to add a general requirement
for synchronization of streams emanating from the same context.  I think the
current work on MCU decomposition in SG 16 may come up with package-based
solutions for greater selectivity.

If ReserveGroup and ReserveValue are both true, the MG is expected to
reserve resources to cover every session description and, within each one,
every codec alternative offered.

-----Original Message-----
From: Usha Iyer [mailto:[email-masked]]
Sent: Wednesday, January 02, 2002 11:31 PM
To: Taylor, Tom-PT [CAR:B800:EXCH]; [email-masked];
[email-masked]
Subject: Re: [Megaco] Reserve Value and Reserve Group

Hi Tom, All

    Section  6.98 of  AVD-2128 doc ( H248IG) states that
--------------------
A Stream Descriptor specifies a single bi-directional media stream and so a
single session description MUST NOT include more than one media description
("m=" line).  Any additional media streams for a termination must appear in
distinct Stream Descriptors.
-----------------------
      Due to the above restriction ,you can't have multiple "m=" lines in
one session desc.
       One ques:  How do u resolve ReserveValue = True and also ReserveGroup
= True

Regards
Usha

----- Original Message -----
From: Tom-PT Taylor <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Thursday, January 03, 2002 12:54 AM
Subject: RE: [Megaco] Reserve Value and Reserve Group

> A "property group" is the same as a session description.
ReserveGroup=true
> says to reserve resources to support all of the session descriptions
> presented.
>
> ReserveValue=true definitely says that if multiple payload types are
> presented on the same m= line, resources should be reserved for all of
them.
> The grey area is if there are multiple m= lines within the same session
> description.  I propose the interpretation that ReserveValue=true reserves
> all resources within the same session description.
>
> I believe a further interpretation is needed as follows:
>
>   ReserveValue=true, ReserveGroup=false, multiple session descriptions
> presented:
>   --------------
>  means that the MG chooses its preferred session description, then
reserves
> all resources specified therein.
>
>   ReserveValue=false, ReserveGroup=true, multiple session descriptions
> presented:
>   --------------
>  means that the MG reserves resources for every session description, but
> within each session description, where any m= line presents alternative
> payload types, the MG chooses just one of the alternatives.
>
> I suspect it may be simpler to use the FID mechanism
> (draft-ietf-mmusic-fid-05.txt) when it is finished.
>
> As for the missing s=, o=, and t= lines, RFC 3015 makes them optional in
the
> MGC-to-MG direction.
>
> -----Original Message-----
> From: Sudhir Kumar Appana [mailto:[email-masked]]
> Sent: Saturday, December 29, 2001 1:27 AM
> To: [email-masked]
> Cc: Sudhir (E-mail)
> Subject: [Megaco] Reserve Value and Reserve Group
>
>
> Hi,
> In the RFC 3015, following is given in section 7.1.8 (Local and Remote
> Descriptors):
> "If ReserveGroup is true, the MG reserves the resources required to
> support any of the requested property group alternatives that it can
> currently support.  If ReserveValue is true, the MG reserves the
> resources required to support any of the requested property value
> alternatives that it can currently support."
>
> In the above statement, I want to know "what is property group and what is
> property value". Where can I get more information on this. I referred
> SDP RFC 2327, in that Session level Description and Media level
Description
> are differentiated. But I could not conclude from this.
>
> In RFC 3015 Appendix-A section-A.1.2 Step-12, Local Descriptor defines two
> Session level descriptions. Can anybody mail me how can I interpret this,
> as property groups or as property values. I will be happy, if somebody
> explains this with some example packets.
>
> One more doubt regarding SDP Paramters:
> In SDP RFC 2327, it is given that following fields are mandatory:
> For 'Session description':
> v=  (protocol version)
> o=  (owner/creator and session identifier).
> s=  (session name)
> For 'Time description':
> t=  (time the session is active)
>
> For 'Media description':
> m=  (media name and transport address)
>
> But in call flows given in RFC 3015 Appendix A and in 'draft-madhu-megaco-
> callflows-00.txt', I haven't found fields 'o=' and 's='. Are this fields
are
> not required.
>
>
> Thanks,
> Sudhir
>
>
> _______________________________________________
> 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

---

From: Terry L Anderson <[email-masked]>
Date: Fri, 18 Jan 2002 15:41:08 -0500

I am designating this issue as open issue #3.  Tom suggests that we change a
statement that is proposed for the IG 6.98 (not yet approved).  The intent of
the statement was that multiple media streams in SDP should not occur in a
single H.248 StreamDescriptor, but defining this in terms of a single m line is
too restrictive.
(1) FID allows grouping multiple media lines (m lines) into a single media
stream and this should be allowed in a single H.248 StreamDescriptor.
(2) RFC 2833 supports DTMF (and other telephone event tones) being sent using a
distinct payload.  It also supports sending this payload to a different
ipaddr/port than that used for voice.  This in essence "forks" the media stream
coming from one termination (eg. PSTN) into two output streams, one containing
voice RTP and the other containing DTMF (or other telephone event RTP, sent to
(possibly) two different ipaddr/ports.  This is similar in concept to FID and
again requires multiple media (m) lines in the SDP.

The current IG draft adds the following to 7.1.8 (right under the first set of
bullets):

Perhaps we could change this to read:

A Stream Descriptor specifies a single bi-directional media stream and so a
single session description MUST NOT specify multiple streams.  This often means
that the session description will contain only a single media description ("m="
line).  However, where media descriptions are grouped and refer to a single,
logical media stream but where payload packets may be sent to different
transport addresses, multiple media description lines may be required (e.g., RFC
2833).  Any additional, non-grouped media streams MUST appear in distinct Stream
Descriptors.
--------
If we refer to RFC 2833, a reference will have to be added to section 2.2
Informative References, but I think this helps clarify the intent with an
example.  We cannot refer to FID as it is not yet an RFC.

Tom, does this meet your intent or do you have an alternate re-wording?

--

------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

---

From: Terry L Anderson <[email-masked]>
Date: Fri, 18 Jan 2002 15:41:08 -0500

--

---

From: Troy Cauble <[email-masked]>
Date: Fri, 18 Jan 2002 16:30:03 -0500

> example.  We cannot refer to FID as it is not yet an RFC.

I have no problem with the intent of this change.  You have to 
change the language to allow certain cases.  But the language 
is getting very fuzzy.

How do I tell a "single, logical media stream" from "multiple streams"?

Why is voice & RFC2833 DTMF a "single, logical stream", when 
audio + video is "multiple streams"?

When would an MG be handling multiple streams on a termination
that are not "logically" related in some way?

Doesn't this really mean I can put as many "streams" as I want
in my SDP and have just one StreamDescriptor?

-troy

---

From: Troy Cauble <[email-masked]>
Date: Fri, 18 Jan 2002 16:30:03 -0500

-troy

---

From: Christian Groves <[email-masked]>
Date: Mon, 21 Jan 2002 14:14:46 +1100

G'Day Terry,

We already have this functionality in H.248 "Reserve Group" and "Reserve
Value". It allows the FID concept (group ID). With regards to sending
DTMF I thought that we used the signal mechanism for that. So I don't
think we need a change.

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Mon, 21 Jan 2002 14:14:46 +1100

G'Day Terry,

Regards, Christian

---

From: Terry L Anderson <[email-masked]>
Date: Mon, 21 Jan 2002 23:07:20 -0500

Christian Groves wrote:

> Value". It allows the FID concept (group ID).

Perhaps I do not understand some mechanism in Reserve Group and Reserve Value, but I
thought they they simply allowed MGC to specify whether MGC should choose one choice or
all choices it can support  among alternatives in a single stream (as well as reserving
the resources for those in reply).  I've always assumed that this was simply a first
step in negotiation and before the call was fully setup a single Group would be chosen
by a later Modify with ReserveGroup=false. All examples I've seen do this.  Do you
believe that a call will function with multiple groups still present?  If so, where do
we specify the semantics?  With Local, would we mix the RTP received in each group?
With Remote, would we send to ALL groups?

I think Reserve Group and Reserve Value are in the subject line only because the
original question on this topic lead to the noticing the single m line restriction and
FID was an additional reason for concern about this.  I should have changed the subject
before continuing the discussion of multiple m lines.

I don't see that ReserveGroup/Value has anything to do with FID, where multiple RTP
streams are grouped into a single media stream (or streams are coordinated such as video
and audio for lip sync), but let's look at the grouping of RTP streams.  The
archetypical example, given in the FID draft is where a single audio media stream is
split into seperate RTP sessions, one carrying DTMF and the other voice, using different
encoding and sent to different ipaddr/port locations (or the reverse where to RTP
sessions are combined into one.

I don't seen how Reserve Group and Reserve Value help with this, but there may be a
question of whether H.248's Context is sufficient to provide the FID functionality.  FID
specifies that an inbound media stream is sent using all m lines in the flow (group).
This is essentially equivalent to using distinct terminations for each m line and
putting all the terminations in the same context with appropriate topology descriptor.
FID does have some restrictions on the use of each m line that are a little different.
It assumes that the flow will be encoded using a single codec and sent only to the m
lines supporting that codec.  This seems to be intended to separate things like DTMF -
if phone-event is used for DTMF tones, then those RTP packets are sent ONLY to the m
lines containing phone-event and not to those with only voice codecs.  I don't see how
to indicate this behavior with additional terminations in the context, where it would
seem that the DTMF tone should be sent to all indicated terminations with corresponding
codec (that is, telephone-event to one AND codec encoded tone to other).

The media synch use of FID (lip synch etc) would not seem to need multiple m lines in a
single SDP description.  I would think that audio and video whould still need to be in
distinct Stream Descriptors but fid used to link them for synch.  I would think we'd
need some statement how to do this in H.248 since we do NOT want the entire session in a
single Stream Descriptor.

Tom Taylor and Brian Rosen both suggested we needed to support FID.  Perhaps they can
suggest other reasons we need it or how it would be used.

> With regards to sending

I believe that there is need for both mechanisms: sending DTMF through signaling channel
(events & signals) or media channel (RTP using RFC 2833).  This is equivalent to the
H.323 case where DTMF can be sent using H.245 signaling (UserInputIndication) or RTP.
The RTP method is often preferable when DTMF is being passed through to far PSTN and
there is no need to process it in a MGC (or routing GK).  It travels much faster and is
much easier to coordinate time when regenerating the tones in the media channel.  There
is currently no mechanism (that I know of) like the recent additions to H.245 to carry
the RTP timestamp in the event notification and signal descriptor, in order to re-insert
the DTMF at the correct time in the media channel.

--

---

From: Terry L Anderson <[email-masked]>
Date: Mon, 21 Jan 2002 23:07:20 -0500

--

---

From: Christian Groves <[email-masked]>
Date: Tue, 22 Jan 2002 15:56:46 +1100

G'Day Terry,

Reserve Group and Reserve Value give you the ability to support all
choices in a single stream. One use is in the case of negotiation but
the text doesn't limit you to this case. I see FID can be implemented
with reserve group because you can have seperate RTP in different groups
being part of the one logical stream. One group can specify DTMF,
another can specify audio codec and you can set  them to different
IP/port combinations if you wish but these will all be part of the same
stream descriptor.

If we map the FID groups into different H.248 stream IDs then we don't
have the problem with the ("m=") that was in the email that kicked off
this discussion. I don't see the reason why to use distinct terminations
for each m= line. In terms of specifying synchronisation, a statement
was already added in v1 7.1.4 "Multiple streams exiting a termination
shall be synchronized with each other."

Thus I don't a reason to make changes.

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Tue, 22 Jan 2002 15:56:46 +1100

G'Day Terry,

Regards, Christian

---

From: Terry L Anderson <[email-masked]>
Date: Tue, 22 Jan 2002 17:31:37 -0500

Ok, but this is a totally new concept to me.  I see nothing in the description of groups in
7.1.8 or elsewhere that specifies the meaning of multiple groups that are never reduced
through a later Modify.  I can see an advantage to using this feature rather than FID,
although we would be going a different direction that other protocols using SDP (SIP, etc)
just as we are for negotation.  But I think that the semantics need to be specified in the
protocol.

If a Stream has multiple groups:
1) in Local, does MG choose one to send a media packet or duplicate the media packet and sent
to all?  It IS stated that
    "(c) If multiple gropus of properties are present in a Local or Remote descriptor or
multiple values within a group, the order of preference is descending."

I assumed that this was preference for choosing for the reply, but if media begins to flow
with multiple groups present this could be interpretted as preference for deciding which to
use for a media packet.

If multiple payload types (ReserveValue = true) exist on a single m line, one does NOT send
using all codecs, one can send using any of them but left most is preferred.  Is this your
interpretation of multiple groups as well: send to one, first preferred?  When would you send
to other than first?  Only when the first did not have a payload suitable?

2) In Remote, this requires receiving packets on multiple ports and mixing them.  An MG that
cannot support mixing can set root/MaxTerminationsPerContext to 2 to indicate this.  But how
can it indicate that it cannot accept multiple groups that would require mixing?

I cannot see how all this

--

---

From: Terry L Anderson <[email-masked]>
Date: Tue, 22 Jan 2002 17:31:37 -0500

--

---

From: Terry L Anderson <[email-masked]>
Date: Tue, 22 Jan 2002 17:42:26 -0500

"(c) If multiple groups of properties are present in a Local or Remote descriptor or

If multiple payload types (ReserveValue = true) exist on a single m line, one does NOT send
using all codecs, one can send using any of them but left most is preferred.  Is this your
interpretation of multiple groups as well: send to one, first preferred?  When would you send
to other than first?  Only when the first did not have a payload suitable?  [FID supports
sending to multiple if they have the same payload.]

2) In Remote, does this requires receiving packets on multiple ports and mixing them?  An MG
that cannot support mixing can set root/MaxTerminationsPerContext to 2 to indicate this.  But
how can it indicate that it cannot accept multiple groups that would require mixing?

If is what H.248 intends with ReserveGroup it seems that the behavior must be much more
specified than it is in 7.1.8.

--

---

From: Terry L Anderson <[email-masked]>
Date: Tue, 22 Jan 2002 17:42:26 -0500

--

---

From: Christian Groves <[email-masked]>
Date: Wed, 23 Jan 2002 13:51:47 +1100

G'Day Terry,

See my replies below.

Christian

> just as we are for negotation.  But I think that the semantics need to be specified in the

[CHG] Can you point out the text in 7.1.8 where it says that you should
do a modify after reserve group? I'm puzzled on what semantics need to
be added. The note in 7.1.8 gives an example that the MG can encode /
decode according to the groups. You could see DTMF as one codec, GSM EFR
RTP as the other.

> with multiple groups present this could be interpretted as preference for deciding which to

[CHG] I think this is where the confusion lies. ReserveGroups True -
means that the MG supports all the groups. It is not overloading a
descriptor so that the MG chooses one of the groups. ReserveGroup False
- means that the MG chooses one alternative.

> sending to multiple if they have the same payload.]

[CHG] Yes this is my interpretation - groups enables the MG to choose to
send/receive the preferred codec however it should reserve resources in
case it receives another format ie. DTMF

> how can it indicate that it cannot accept multiple groups that would require mixing?

[CHG] No it does not involve mixing.

---

From: Christian Groves <[email-masked]>
Date: Wed, 23 Jan 2002 13:51:47 +1100

G'Day Terry,

See my replies below.

Christian