Subject: RE: [Megaco] Open Issue #3: Reserve Value and Reserve Group

From: "Tom-PT Taylor"<[email-masked]>
Date: Wed, 23 Jan 2002 15:17:38 -0500

ReserveValue and ReserveGroup actually go a little beyond FID, I think.
Regardless, their use means that the MGC may have to do a translation
between the SDP sent to the MG and the SDP used in negotiating with the far
end.  I think a number of MGC vendors would prefer not to look at the
details of SDP, but just pass them through.

On DTMF, the choice of whether to handle in the signalling path or in the
media path is an old architectural issue.  We can't foreclose the RFC 2833
approach.

May I suggest that the defining characteristic of a media stream is that
only one media format (e.g. payload type) will flow in a given direction at
any given instant?

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Sunday, January 20, 2002 10:15 PM
To: Terry L Anderson
Cc: [email-masked]
Subject: Re: [Megaco] Open Issue #3: Reserve Value and Reserve Group

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

Troy Cauble wrote:
> 
> Terry L Anderson wrote:
> >
> > 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):
> >
> > 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.
> >
> > 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.
> 
> 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
> 
> _______________________________________________
> 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: "Tom-PT Taylor"<[email-masked]>
Date: Wed, 23 Jan 2002 15:17:38 -0500

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Sunday, January 20, 2002 10:15 PM
To: Terry L Anderson
Cc: [email-masked]
Subject: Re: [Megaco] Open Issue #3: Reserve Value and Reserve Group

G'Day Terry,

Regards, Christian

change a
intent of
a
line is
media
using a
stream
containing
sent to
FID and
set of
so a
description
in
so a
often means
description ("m="
single,
(e.g., RFC
distinct Stream
2.2
an