Subject: RE: [AVT] Please review and comment on "in-band" RTP signaling me thodology

From: "Even, Roni" <[email-masked]>
Date: Wed, 6 Mar 2002 09:41:30 +0200

Colin,
The text is from the SG16 WP2 meeting report. The MOIP group (Modem Over IP)
came with the requirement and proposal to have signalling in the RTP to
enable faster response (switch between modes) and they felt that H.245 will
not give them the right timing. There were some discussion about this
suggestion but WP2 could not give a better solution. There were also concern
about signalling going through different routes and abusing the GK control
as well as keeping the GK without knowledge of the changes in the media. 
Regards

Roni Even

**********************************************
Roni Even
VP Product Planning -CTO Office
Polycom Network Systems
Tel: +972-3-9251200
Mobile: +972-55-481099
Fax: +972-3-9211571
Email: [email-masked]

D.204 - Generic Content and SDP Representation of V.MoIP Capability and
Session Data (Cisco)
There was a comment that a profile would have to be defined for the SPRT
transport.  Some coordination will have to occur with the AVT working group
within the IETF relating to the assignment of the MIME type for "tmr".  Some
work also needs to be done to work properly with H.248: what is there may or
may not be suitable.  There is nothing that addresses the binary encoding in
H.248, so we need to also address that issue.

Ad-hoc Meeting on H.323 MoIP Signaling
We opened the meeting with a brief introduction to the problem that we're
trying to solve.  Initially we will focus on H.323 and work on H.248 at a
later point.  It was mentioned that switching between streams quickly is
absolutely vital, so H.245 signaling to change channels may not be
appropriate.  Additionally, there is a requirement for forward error
correction (FEC) and redundancy.  There is a need to have multiple
"sub-channels" wherein each of the media steams are delivered to the same IP
address and port number.

It was noted that the syntax in D.204 was taken from an Internet Draft and
we need to understand this syntax, so that we can properly map this to
H.323.  The SDP syntax in this document is only for guidance for developing
H.245 syntax.

Does it make sense to say that an endpoint supports "FEC" or supports "FEC
for G.711"?  The FEC data has a payload type, but is associated to an
existing audio stream.  The FEC under consideration is RFC 2733, but we may
use different FEC schemes in the future.

Redundancy is described in RFC 2198 and needs to be incorporated.

There are several ways of encoding streams that may be opened:
1)	Media stream with a single payload type
2)	Media stream + redundancy (three payload types: "master", codec PT,
redundancy PT) 
3)	Media stream + FEC (two payload types: codec PT and FEC PT)
4)	Media stream + redundancy + FEC

There was a question of whether FEC is used to support a single payload type
or multiple payload types.  This needs to be explored as the drafting team
is working on syntax for H.245.

There are up to four "elementary streams" that may be opened simultaneously
to support MoIP:
1)	Audio
2)	VBD
3)	SSE
4)	SPRT

The thinking is to define a single channel and allowing multiple "elementary
streams" within that channel.  Endpoints may switch on a packet-by-packet
basis between the payload types for each stream.

It was mentioned that we might have GWs that will not require all of the
aforementioned streams.  It is possible, for example, that a GW may open
only VBD and SPRT streams.

The feeling of the group is that we should require support for VBD, whereas
SPRT is required only for modem relay.  This is an open issue that will be
resolved by Q.11.  It is noted that "modem relay" has a special meaning,
which is narrower than just the "transfer of modem signals".

A team was formed to draft text for proposed changes to H.245 and toward
Annex P/H.323.  This text appears in TD-66 (WP2).

TD-66 - Proposed changes to H.245 and Input toward Annex P/H.323 (Q.2
Rapporteur)
This document presented the proposed data structures for H.245 to support
modem over IP.  There was a comment that SSE signaling may or may not be in
alignment with Q.11's notion of the use of SSE.  This issue will be taken
offline.  There was a concern that the dataType is recursive now.  This is
more complicated and we need to address this either in the syntax or in
Annex P/H.323.  One person commented that we should describe the usage in
Annex P and leave the data structures as-is within H.245 without usage
guidelines.  Another person felt that we should change the syntax to limit
what can be done.  Another comment was that we should limit the transport
addresses that can be used.  For example, we should not allow mixing of RTP
with other traffic.  It is believe that the data structures do address the
latter concern, as there is no means of signaling a different transport
address.

It was pointed out that the SSE "commands" would be defined in V.MoIP.

We should consider whether we should have an "SSE" as a separate dataType,
rather than buried inside the VMoIPProfile structure.  This would allow SSEs
to be used separately, possibly for Fax in the future.

We need to consult with the experts of Question 14 to see if these data
structures lead us in a direction that is suitable for fax switching.

It was noted that we still need to address signaling between the endpoint
and the GK so that the GK knows when a modem/voice switch occurs.  We need
to consider whether the endpoint simply informs the GK or it needs to get
permission from the GK when performing the switch.  We have three options:
1)	Endpoints switch without alerting the GK
2)	Endpoints switch and alert the GK
3)	Endpoints seek GK permission before the switch

These structures were generally acceptable and work will progress on
developing procedures that utilize these structures.

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Wednesday, March 06, 2002 5:11 AM
> To: Rajesh Kumar
> Cc: [email-masked]
> Subject: Re: [AVT] Please review and comment on "in-band" RTP 
> signaling methodology 
> 
> 
> Rajesh,
> 
> Can you comment on the status of this work in TIA TR.30.1 and 
> ITU SG16?
> Colin
> 
> 
> 
> --> Rajesh Kumar writes:
> >AVT colleagues,
> >
> >The draft 
> >http://search.ietf.org/internet-drafts/draft-rajeshkumar-avt-
> sse-00.txt 
> >describes an in-band signaling method that is being actively 
> considered by 
> >the TIA TR.30.1 and ITY SG16 groups. Since this is based on 
> RTP, these 
> >groups have considered it appropriate to review it in the IETF.
> >
> >Please review and comment. We can request a slot for 
> discussing issues at 
> >the Minnesota or the Yokohama meetings, depending on the 
> volume and nature 
> >of the responses. Thanks,
> >
> >Rajesh Kumar
> >Cisco Systems
> >
> >
> >
> >_______________________________________________
> >Audio/Video Transport Working Group
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/avt
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
> 

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 7 Mar 2002 08:49:28 +0200

Hi,

I think that we also need to look at using RTP for call control or call
state control before we select a method, maybe this should be done in RTCP
from the sender based on the feedback draft.

Regards
Roni Even
Polycom

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, March 06, 2002 6:56 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Please note that there is another proposal for "mode 
> switching" that is
> being considered by the TR-30.1 and ITU-T Q11/16 modem experts for use
> with MoIP.
> 
> Perhaps it is premature for the IETF to consider SSE until the modem
> experts are closer to deciding which method they would 
> prefer? Or perhaps
> the alternate method (known as the "reliable state update 
> protocol", or
> "RSUP") should also be run past the IETF?
> 
> If there is desire for the latter, I would be happy to submit the RSUP
> proposal as an internet draft for IETF consideration. Because 
> of timing,
> it could not be discussed at an IETF meeting until Yokahama.
> 
> Comments expected and welcome.
> 
> Jim Renkel
> 
> 
> 
> 
> 
> Rajesh Kumar <[email-masked]>@ietf.org on 03/05/2002 05:58:50 PM
> 
> Sent by:  [email-masked]
> 
> 
> To:   [email-masked]
> cc:
> Subject:  [AVT] Please review and comment on "in-band" RTP signaling
>       methodology
> 
> 
> AVT colleagues,
> 
> The draft
> http://search.ietf.org/internet-drafts/draft-rajeshkumar-avt-s
se-00.txt
describes an in-band signaling method that is being actively considered by
the TIA TR.30.1 and ITY SG16 groups. Since this is based on RTP, these
groups have considered it appropriate to review it in the IETF.

Please review and comment. We can request a slot for discussing issues at
the Minnesota or the Yokohama meetings, depending on the volume and nature
of the responses. Thanks,

Rajesh Kumar
Cisco Systems