Roni,
I can't recall exactly what the definition of "source" was, but I would agree it should be stated clearly. In any case, the word "source" is akin (if not the same) as "source" in RFC 1889. Essentially, a "source" might be a microphone or a DSP that's converting audio into packetized media, etc.
Paul
----- Original Message ----- From: "Even, Roni" roni.even@polycom.co.il To: "'Paul E. Jones'" paulej@packetizer.com; "Even, Roni" roni.even@polycom.co.il; ITU-SG16@echo.jf.INTEL.COM Cc: "Martin Euchner" Martin.Euchner@icn.siemens.de Sent: Thursday, September 26, 2002 3:53 AM Subject: RE: comments on AVD 2253 from Raleigh
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@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@polycom.co.il To: "'Paul E. Jones'" paulej@packetizer.com; "Even, Roni" roni.even@polycom.co.il; ITU-SG16@echo.jf.INTEL.COM Cc: "Martin Euchner" Martin.Euchner@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@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.
- 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.
- 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.
- 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@lists.intel.com