comments on AVD 2253 from Raleigh

Even, Roni roni.even at polycom.co.il
Wed Sep 18 04:06:28 EDT 2002


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 at packetizer.com]
> Sent: Tuesday, September 17, 2002 7:52 PM
> To: Even, Roni; ITU-SG16 at 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
> 
> 



More information about the sg16-avd mailing list