Paul,
Single source is not a good definition, is it an a same IP address or is it
the same encoder
Roni
> -----Original Message-----
> From: Paul E. Jones [mailto:paulej@packetizer.com]
> Sent: Thursday, September 26, 2002 6:56 AM
> To: Even, Roni; ITU-SG16(a)echo.jf.INTEL.COM
> Cc: Martin Euchner
> Subject: Re: comments on AVD 2253 from Raleigh
>
>
> Roni,
>
> The current definition, which was drafted by Terry Anderson,
> is pretty clear
> that multiple payload streams must carry data from a single
> "source", I
> believe. Have a look at AVD 2257.
>
> Paul
>
> ----- Original Message -----
> From: "Even, Roni" <roni.even(a)polycom.co.il>
> To: "'Paul E. Jones'" <paulej(a)packetizer.com>; "Even, Roni"
> <roni.even(a)polycom.co.il>; <ITU-SG16(a)echo.jf.INTEL.COM>
> Cc: "Martin Euchner" <Martin.Euchner(a)icn.siemens.de>
> Sent: Wednesday, September 18, 2002 4:06 AM
> Subject: RE: comments on AVD 2253 from Raleigh
>
>
> > Paul,
> >
> > I think that the requirement were to prevent audio and
> video in the same
> > stream on one side and to allow for multiple video or audio
> in the same
> > stream to be compatible with SIP capabilities and not only
> for MOIP. So I
> > think that there should be a text saying that in multiple
> streams we do
> not
> > recommend audio and video in the same stream and to be able
> to specify the
> > packetization scheme for the multiple streams.
> > Roni
> >
> > > -----Original Message-----
> > > From: Paul E. Jones [mailto:paulej@packetizer.com]
> > > Sent: Tuesday, September 17, 2002 7:52 PM
> > > To: Even, Roni; ITU-SG16(a)echo.jf.INTEL.COM
> > > Cc: Martin Euchner
> > > Subject: Re: comments on AVD 2253 from Raleigh
> > >
> > >
> > > Roni,
> > >
> > > ,
> > > > I have some concerns about the changes proposed in this AVD.
> > > >
> > > > 1. The AVD adds a new data type called
> multiplepayloadstream that is
> > > > intended to allow more then one payload in a stream.
> > > According to the
> > > ASN.1
> > > > you can have different media types in the same logical
> > > channel which is
> > > not
> > > > a good practice and would break a lot of implementations.
> > >
> > > We already have precedence for this, such as RFC 2833. In
> > > addition, this
> > > feature would only be used if both sides advertise the
> > > capabilities, so I do
> > > not expect to see anything break.
> > >
> > > > 2. The data type in H.245 open logical channel describe the
> > > media type but
> > > > do not specify the RTP payload format used. There are cases
> > > were there is
> > > > more then one way to build the RTP stream for example in
> > > H.263. In the OLC
> > > > in H2250LogicalChannelParameters there is a RTPPayloadType
> > > parameter that
> > > > describe the RTP payload. If the AVD is used to describe
> > > multiple streams
> > > > there is no way to specify the packetization scheme used.
> > >
> > > This might be true. Would it be possible to add those
> parameters as
> > > necessary in the future? At the moment, the only use for
> > > this capability at
> > > the moment is for modem over IP, wherein every payload that
> > > will be used is
> > > understood based solely on the capability, I believe--
> > > perhaps I'm wrong.
> > > In any case, the important thing is to know whether the
> > > syntax precludes the
> > > specification of additional parameters.
> > >
> > > > 3. I think that the editor of H.235 will look to see if the
> > > proposed AVD
> > > > allows to specify and change a key for each payload that
> > > can be used in
> > > the
> > > > logical channel. I am not an expert on H.235
> > >
> > > Most definitely.. I would certainly welcome comments and
> > > input in the area
> > > of security.
> > >
> > > Paul
> > >
> > >
> >
>
