[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] VoIP Shim for RTP Payload Formats
Hi
I agree that capabilities should be exhanged (eg. SDP) in order to
decide if Shim should be allowed.
The main application is point to point communication.
Of the cases below I belive that in case 1 and 2 Shim should be avoided.
In case 3 it may be possible to use Shim if a conference bridge can do
policing on the Shim information.
Ingemar
> -----Original Message-----
> From: Even, Roni [mailto:roni.even at polycom.co.il]
> Sent: den 7 september 2006 08:48
> To: Desineni, Harikishan; Colin Perkins; Ingemar Johansson S (LU/EAB)
> Cc: avt at ietf.org
> Subject: RE: [AVT] VoIP Shim for RTP Payload Formats
>
> Hi,
> I want to put my 2 cents on in band signaling.
>
> I would agree that in-band signaling will work I point to point call.
> Care should be taken for the following cases
>
> 1. Unidirectional media.
> 2. Multicast
> 3. Multipoint cases
>
> That is why I think that capabilities should be in the
> signaling path In the media path you can have changes which
> are of a temporary nature like rate change commands for video
> or audio or indications.
>
> I think you suggest a capability describing a more permanent
> state which should be in SDP.
>
> Roni Even
>
> > -----Original Message-----
> > From: Desineni, Harikishan [mailto:hdesinen at qualcomm.com]
> > Sent: Wednesday, September 06, 2006 10:57 PM
> > To: Colin Perkins; Ingemar Johansson S ((LU/EAB))
> > Cc: avt at ietf.org
> > Subject: RE: [AVT] VoIP Shim for RTP Payload Formats
> >
> >
> > I am under the impression that in-band signaling inside
> payload header
> > is an accepted concept in this community. Other than AMR Payload
> format,
> > there is another payload format which is trying to use this concept.
> > Once such work is the use of MBS field in Sec 5.2
> > draft-ietf-avt-rtp-g729-scal-wb-ext-07.txt
> >
> > "MBS (4 bits): maximum bit rate supported. Indicates a
> maximum bit
> > rate to the encoder at the site of the receiver of this payload."
> >
> > I think that RTCP (AVPF) has a similar message which can be used to
> > convey maximum bit rate to the encoder at the remote end.
> >
> > I'd like to infer the following statements from the
> reference to the
> > above work in RTP and RTCP:
> >
> > 1) In-band signaling using RTP payload header is an
> allowed/accepted
> > concept.
> > 2) RTCP signaling may also exist to carry the same information.
> >
> > In certain scenarios (MOH, voice mail), RTCP signaling is
> unavoidable.
> > One will end up defining methods to carry the same
> information using
> > both in-band RTP and RTCP based feedback.
> >
> > -----Original Message-----
> > From: Colin Perkins [mailto:csp at csperkins.org]
> > Sent: Friday, August 25, 2006 7:30 AM
> > To: Ingemar Johansson S ((LU/EAB))
> > Cc: avt at ietf.org
> > Subject: Re: [AVT] VoIP Shim for RTP Payload Formats
> >
> > > Inband signaling of the type proposed already exist for eg.
> > > the AMR payload format (RFC3267), it is however limited to the
> > > request of lower/higher codec rate. The intention of this added
> > > inband signaling is to allow for requests regarding frame
> aggregation
> > > and redundancy during a session so in that aspect it is a
> > > continuation of the inband signaling concept that already exist.
> >
> > This is one of the less desirable features of the AMR
> payload format,
> > and was included solely for backwards compatibility.
> >
> >
> > Colin
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt at ietf.org
> > https://www1.ietf.org/mailman/listinfo/avt
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt at ietf.org
> > https://www1.ietf.org/mailman/listinfo/avt
>
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt