time-lined static media

Hi,

Has anyone been thinking about the draft
http://search.ietf.org/internet-drafts/draft-westerlund-avt-rtp-static-media-01.txt
?

There was quite a discussion last July, then all quiet. This payload
format seems to have a lot of potential.

Cheers,
  Chuck Harrison
  Far Field Associates, LLC

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

Re: RTP mixers & translators

Dear Roni,

Thank you very much for your answer.
The functionality I would like to use is (from RFC1889 section 2.3)

mixer:

...Instead of forcing
   everyone to use a lower-bandwidth, reduced-quality audio encoding, an
   RTP-level relay called a mixer may be placed near the low-bandwidth
   area....

translator:
                                                                   .....Two
translators
   are installed, one on either side of the firewall, with the outside
   one funneling all multicast packets received through a secure
   connection to the translator inside the firewall.

I have secure, heterogeneous networks (very high and very low bandwidth).
I thought mixer can help to reduce the data rate (seamlessly?) at the boundary.

And translator can be used to across the secure LANs. Is it true?
Or, the H.323 signaling handles this situation? So we don't need mixers and
translators at RTP-level in the real world. Does SIP have the same functions?

Any suggestion is greatly appreciated!!!

Regards,
Oliver

IP Network Simulator

UXP RTP payload format

All,

I have been reading draft-ietf-avt-uxp-02.txt and have the following comments:


0. About the document structure, I think that the document could benefit from moving the introduction (section 3)
before the very useful but also quite long "conventions used in this document" part

1. Since one of the key features of the payload format is that it distributes errors
using *interleaving* I think that this key word should be found in the abstract
and the introduction.

2. There is a substancial amont of confusion introduced by using several words
to say same/different things, for example in section 2.7 we find "block" to mean "frame"
then "bitstream of certain length" then "elements"  which apparently are pieces thereof (?)
Then in the next paragraph (2.8) "block" is a RS block etc..

I would recommend the usage of "encoded frame" and "encoded frame fragment"

3. section 2.15 defines an "info stream" (and then the term "info byte" is used a lot
in the whole document) which looks to me like a rather extreme short cut
especially if it is meant to lead the reader to assume that this level of abstraction
can serve as some proof that this specification can work with *any* media stream.

Specifically recent audio codecs dont have a "bitstreams" structure (or byte-stream either)
in the traditional sense that if encoded frame boundaries are not transported
explicitely the decoder cannot find them.

Then there is this extremely mysterious parenthesis:
"(e.g.  as specified in the respective RTP profile
for the media codec in use)" which confuses me rather badly.

Is that the "normal" RTP payload format for the media ?

if yes, say so, then explain why and how it would help.

if no, (which I suspect)  the way a receiver can reconstruct the media stream structure i.e.
at least encoded frames boundaries and time line after de-packetization must be specified.

As mentioned (a bit late) in section 9 UXP creates a completely "new packetization"
(by contrast with ULP) of the original media stream, therefore it would be useful to
at least add a few paragraphs about how one is supposed to "replace" the
functionality that RTP packets play when transporting the *same media* in
"normal" RTP i.e. transport of encoded frame boundaries and associated media time....

For example section 6.12 says in another mysterious parenthesis
"(the source decoder may be informed about the missing info stream,
if required)". Informed of what ? And how ?

If -as I suspect- this scheme works only for self-timed self-framed media
streams, this should be clearly indicated preferably much early than in
the discussion comparing it with ULP (section 9), i.e. in the abstract
and introduction (!)

3bis. The document would greatly benefit from a few numerical examples based
on realistic media streams. Examples covering the usage of existing "real life" codecs
would be very useful for both audio and video (create an Appendix ?)

4.The document does not mention anything about the complexity of RS
computations (especially by comparison with XOR ?) and that could be
badly misleading for naive potential implementers (Is not  it so that
the RS processing complexity is several orders of magnitude
higher than XOR ?)

4bis.The document does not clearly explain if RS code computation is
required when no losses occur (I hope not).

Could there be a security consequences that an attacker could, by creating
excess traffic, trigger losses, themselves triggering more RS computations,
which in turn would create significant additional ressource usage in decoders ...
a kind of Degradation Of Ressource Attack ??

****************
More details:

Replace all occurences of "byte" with "octet"

Some acronyms/names  are not fully explained/explicit or localized:
* there is a "forward" declaration of "TB" (point 9)
* CA_i is not expanded (IMHO variable names should either
have a meaning or be based on a well known convention right ?)
* AV is not expanded (while SI is )
 
Section 5 mention scalability in MPEG-4: Can MPEG-4 Video Packet and data Partition be used as example ?

In the references there is a MPEG working document (M4204) which status should be checked (maybe hard to *legally* get it no ?)

***************


Regards,

Philippe Gentric
Software Architect
Philips MP4Net
philippe.gentric <at> philips.com
http://www.mpeg-4.philips.com

RE: RTP mixers & translators

Hi,
I re-read the definition in draft-ietf-avt-rtp-new-11.txt which is the
latest draft, since AVT is working on RTP layer which can serve different
applications like conversional and streaming then they define an entity that
works on the RTP layer regardless of the application. I am not sure that
there are real products that give this functionality as standalone product
since there is no definition how the mixer or translator interact in a
specific application. for conversional application based on SIP or H.323, I
am not aware of application aware firewalls that are handling the speed or
algorithm of the audio or video streams. Typically gateways will do it as
part of their functionality (for example a voice gateway from SIP to PSTN).
There are some gateways that can do it from IP to IP but again they do it in
the application context.

About your specific question. If you would like the mixer to change the rate
of audio between the external and internal network (seamlessly) I assume
that you want a box that will do it, how do you expect to tell the box what
rate and what audio algorithm to use on each side.

Roni Even

> -----Original Message-----
> From: Shu Wang [mailto:Shu.Wang <at> trw.com]
> Sent: Wednesday, April 03, 2002 4:30 AM
> To: Even, Roni
> Cc: avt <at> ietf.org
> Subject: Re: [AVT] RTP mixers & translators
> 
> 
> Dear Roni,
> 
> Thank you very much for your answer.
> The functionality I would like to use is (from RFC1889 section 2.3)
> 
> mixer:
> 
> ...Instead of forcing
>    everyone to use a lower-bandwidth, reduced-quality audio 
> encoding, an
>    RTP-level relay called a mixer may be placed near the low-bandwidth
>    area....
> 
> translator:
>                                                               
>      .....Two
> translators
>    are installed, one on either side of the firewall, with the outside
>    one funneling all multicast packets received through a secure
>    connection to the translator inside the firewall.
> 
> 
> I have secure, heterogeneous networks (very high and very low 
> bandwidth).
> I thought mixer can help to reduce the data rate 
> (seamlessly?) at the boundary.
> 
> And translator can be used to across the secure LANs. Is it true?
> Or, the H.323 signaling handles this situation? So we don't 
> need mixers and
> translators at RTP-level in the real world. Does SIP have the 
> same functions?
> 
> Any suggestion is greatly appreciated!!!
> 
> Regards,
> Oliver
> 
> "Even, Roni" wrote:
> 
> > Hi,
> >
> > Mixers and translator define functionality for mixing and 
> translating RTP
> > streams. For conversational services they are part of the 
> conference bridge
> > that handles also the call setup and call control 
> signalling. In H.323 it
> > states that an MCU (Multipoint control unit) is not a mixer 
> as defined in
> > RTP, it uses the H.323 signalling.
> >
> > Regards
> > Roni Even
> > Polycom
> > > -----Original Message-----
> > > From: Shu Wang [mailto:Shu.Wang <at> trw.com]
> > > Sent: Saturday, March 30, 2002 4:09 AM
> > > To: avt <at> ietf.org
> > > Subject: [AVT] RTP mixers & translators
> > >
> > >
> > > Hi,
> > >
> > > Based on RFC1889, I am really interested in RTP mixers and
> > > translators.
> > > The functionality is needed in my network design/implementation.
> > > However,
> > > I could not find if there is any vendor who really put them into
> > > products, or
> > > they are usually come with RTP.
> > >
> > > Could anyone please tell me if there is any vendor 
> implementing mixers
> > > and
> > > translators?
> > >
> > > Thank you.
> > >
> > > Regards,
> > > Oliver
> > >
> 

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

RE: RTP mixers & translators

Roni,

> Mixers and translator define functionality for mixing and translating RTP
> streams. For conversational services they are part of the conference bridge
> that handles also the call setup and call control signalling. In H.323 it
> states that an MCU (Multipoint control unit) is not a mixer as defined in
> RTP, it uses the H.323 signalling.

That statement in H.323 has always surprised me, because the MCU
really _is_ a particular case of a mixer.  The RTP specification tries
to convey the idea that the description of mixers and translators
covers a diverse space of devices.  The fact that an MCU also uses
H.323 signaling does not mean that the part handling RTP is not a
mixer.

> About your specific question. If you would like the mixer to change the rate
> of audio between the external and internal network (seamlessly) I assume
> that you want a box that will do it, how do you expect to tell the box what
> rate and what audio algorithm to use on each side.

The box has to be told in some way.  The initial RTP mixer devices
used experimentally on the MBone may have been manually configured.
Other devices may use signaling of some form.

							-- Steve

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

ROC update

Hi all,

As indicated by Mark, we are preparing the final version of SRTP. 
Before doing so, we the authors, would like to prepare you for one 
or two details that will not totally comply with comments received
during WG last call, provide rationale for why, and hope that you
will see our point. We are of course welcoming feedback.

The issue we would like to take up here is the update of the
roll-over counter, ROC, i.e. SRTP's own, not the corresponding
quantity maintained by RTP (the latter will here be denoted RTP-ROC).

We had a comment during WG last call that we should mandate a robust 
update strategy, and an example was given to us with a reference to 
Appendix A of the RTP spec.

Right now, we have a clear definition of what the ROC *is*, and give 
an example on how to maintain and update it on the receiving side. 
Sender behavior is specified exactly. Note that all potential 
robustness problems occurs when SRTP data integrity is not enabled, 
otherwise the suggestion given is robust, so we will in the sequel
assume that authentication is "off". Also, note that the (potential)
problems are on the receiver side only. 

We will not change the text concerning ROC and ROC update for the
following reasons:

* We do not think it is even possible to give a method that is robust
  when data integrity is not present. Besides random errors introduced
  by the channel, there could be adversarial behavior somewhere along
  the path.

* In particular, the RTP-ROC as in Appendix A of the RTP spec does not
seem 
  to withstand such adversarial attacks, it can loose synch. (Though it
  is probably quite good at handling randomly occurring re-orders etc.)

* Mandating a single update strategy in some sense makes it easier 
  for an attacker to perform DoS: he knows how the receiver maintains
  his ROC and can act "counter-accordingly".

* There are no interop problems with allowing receivers to do what they 
  see fit, since the sender behavior is still clearly specified.

* Leaving it open makes it flexible, even application feedback could
  be allowed to detect out-of-synch problems.

An alternative might be to give a small number of different strategies,
but it will complicate the spec and someone will be sure to complain
that
we missed one approach. 

Best,

/Mats

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

RE: RTP mixers & translators

Steve
The text in 2.3 looks to me more like it is related to multicast conferences
and not to H.323 MCU  The example is not about the mixing but about what I
may call transcoding

2.3 Mixers and Translators

   So far, we have assumed that all sites want to receive media data in
   the same format. However, this may not always be appropriate.
   Consider the case where participants in one area are connected
   through a low-speed link to the majority of the conference
   participants who enjoy high-speed network access. Instead of forcing
   everyone to use a lower-bandwidth, reduced-quality audio encoding, an
   RTP-level relay called a mixer may be placed near the low-bandwidth
   area. This mixer resynchronizes incoming audio packets to reconstruct
   the constant 20 ms spacing generated by the sender, mixes these
   reconstructed audio streams into a single stream, translates the
   audio encoding to a lower-bandwidth one and forwards the lower-
   bandwidth packet stream across the low-speed link. These packets
   might be unicast to a single recipient or multicast on a different
   address to multiple recipients. The RTP header includes a means for
   mixers to identify the sources that contributed to a mixed packet so
   that correct talker indication can be provided at the receivers.

As for H.323 in H.225 the text is (annex A and B are the RTP/RTCP and the
profile RFCs that are part of H.225 due to problem with referencing them at
the time)

RTP translators and mixers are not elements of the H.323 system, and any
information about them in Annexes A and B shall be regarded as informative.
Note that both gateways and MCUs have some aspects of both mixers and
translators, and the information in Annexes A and B may be helpful in the
implementation of gateways and MCUs. However, MCUs are not mixers, and
mixers are not MCUs. Note that gateways, for example, on a packet-based
network-to-packet-based network call via the gateway may act as translators.

As for the second issue I was trying to point out that you can not expect to
buy a mixer or translator and control it in a standard mode

Roni

> -----Original Message-----
> From: Stephen Casner [mailto:casner <at> packetdesign.com]
> Sent: Thursday, April 04, 2002 11:06 AM
> To: Even, Roni
> Cc: AVT WG
> Subject: RE: [AVT] RTP mixers & translators
> 
> 
> Roni,
> 
> > Mixers and translator define functionality for mixing and 
> translating RTP
> > streams. For conversational services they are part of the 
> conference bridge
> > that handles also the call setup and call control 
> signalling. In H.323 it
> > states that an MCU (Multipoint control unit) is not a mixer 
> as defined in
> > RTP, it uses the H.323 signalling.
> 
> That statement in H.323 has always surprised me, because the MCU
> really _is_ a particular case of a mixer.  The RTP specification tries
> to convey the idea that the description of mixers and translators
> covers a diverse space of devices.  The fact that an MCU also uses
> H.323 signaling does not mean that the part handling RTP is not a
> mixer.
> 
> > About your specific question. If you would like the mixer 
> to change the rate
> > of audio between the external and internal network 
> (seamlessly) I assume
> > that you want a box that will do it, how do you expect to 
> tell the box what
> > rate and what audio algorithm to use on each side.
> 
> The box has to be told in some way.  The initial RTP mixer devices
> used experimentally on the MBone may have been manually configured.
> Other devices may use signaling of some form.
> 
> 							-- Steve
> 

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

I-D ACTION:draft-ietf-avt-rtp-cn-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: RTP Payload for Comfort Noise
	Author(s)	: R. Zopf
	Filename	: draft-ietf-avt-rtp-cn-06.txt
	Pages		: 8
	Date		: 03-Apr-02
	
This document describes an RTP [2] payload format for transporting
comfort noise (CN).  The CN payload type is primarily for use with
audio codecs that do not support comfort noise as part of the codec
itself such as ITU-T Recommendations G.711 [3], G.726 [4], G.727
[5], G.728 [6], and G.722 [7].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-cn-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-avt-rtp-cn-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-rtp-cn-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

RE: Re: MPEG-4 BIFS in the packet loss environment