RE: [AVT] WG last call: text/red

I'm asking this since the procedure of deriving a session key from a= given master key does not include the use of SSRC - therefore I dont und= erstand how different streams will have different session keys.

as for the <from, to>, as far as I understand ,this value is u= sed to define a master key "life time" ,it doesnt help y= ou define a sequence number space per a session key ?

M= ark Baugher <mbaugher@cisco.com> wrote:

Yes, I think calling the interactions "in= secure" as I did is not
accurate. There is the following issue as I se= e it: An SRTP master
key can be associated with one or more session ke= ys each having its
own sequence-number space. So the master key per se= does not have
a sequence-number space but from-to is used to determin= e when to
change master keys. If the master key is always in one-onerelationship with a session key, then there is no ambiguity.
But if = the master key is used to derive two or more session keys,
then the fr= om-to is not well defined.

Is this "insecure?" Probably not.
Mark
space. So from-to works on
At 12:49 PM 5/11/2004, Mats N=E4s= lund wrote:

>Hi
>
>What I think Mark refers to is a= situation in which
>
>- several SRTP streams share a master = key, and,
>- re-keying is based on From-To values.
>
>If you use SRTP in this way (which RFC3711 recomm= ends against)
>the receiver may in some cases have problem determin= ing the correct
>key. However, there is really no "extra" security = problems involved.
>What *could* happen is a so-called two-time pad= , but this would be
>caused by a misstake by the sender, not by the= receiver. Furthermore,
>this key sharing is not allowed in RFC3711= , unless you can guarantee
>distinct SSRCs for the RTP sessions sha= ring the key. Whence, if you
>(somehow) could guarantee such SSRC-d= istincness, two-time pads would
>anyway not occur.
>
>C= heers
>
>/Mats
>
>Mark Baugher wrote:
>
= >>hi
>> Using both mechanisms is a lot of complexity and I= 'm hard pressed to
>> find examples of when we would need two m= echanisms, which do the same
>> thing. I don't like that final = sentence in 8.1.1 in RFC 3711 because
>> complexity undermines security and using both mechanisms is= complex.
>>
>> From/To has the advantage of not adding= a field to the packet, but it
>> has the disadvantage of insec= ure interactions with the AES counter mode
>> transform. MKI ad= ds a field but does not suffer from this problem. I
>> would ch= oose one or the other but not both.
>>
>> As it is desc= ribed below, use of both mechanisms is superfluous AFAICT.
>>>>Mark
>>
>>At 05:56 AM 5/11/2004, Sylvain Latul= ippe wrote:
>>
>>
>>
>>>Hi,
>= ;>>
>>>My understanding is the following:
>>&g= t;
>>>Both mechanisms can be used whitin the same session. Wh= en using MKI,
>>> mechanism can be used by the sen= der side for synchronizing
>>>key transitions (re-keying).>>>
>>>For example:
>>>
>>>A session is started and 2 keys = (KEY_1 and KEY_2) are given to the session.
>>>
>>&g= t;Session parameters:
>>>KEY FROM TO MKI
>>>KEY_1= 0 10 1
>>>KEY_2 11 x 2
>>>
>>>The se= nder uses KEY_1 to encrypt packets with index 0 to 10. MKI =3D 1 is
&= gt;>>also appended to packets 0 to 10. When building packet with in= dex 11,
>>>the sender switches to KEY_2 and appends MKI =3D = 2 to the packet.
>>>
>>>On the receiver side, is not required in this scenario. MKI
>>>is extracted= from the received packet and used to retrieve the right key.
>>= >
>>>Sylvain
>>>
>>>
>>&g= t;
>>>
>>>-----Original Message-----
>>&= gt;From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Ofer = Goren
>&>>Sent: 11 mai, 2004 07:35
>>>To: avt@ietf.org; srtp-users@lists.sourceforge.net<= BR>>>>Subject: [AVT] and MKI, FRC 3711
>>>=
>>>
>>>Hi.
>>>
>>>In RFC= 3711, section 8.1.1, it says that "using the MKI does not exclude
&g= t;>>using key
>>> lifetime simultaneously".>>>
>>>As I understand it, both mechanisms can be = used for the same session
>>>simultaneously. However, does t= he mechanism is MANDATORY to
>>>be used every time= (whether is used or not), or can I omit it
>>>if = I'm using MKI?
>>>
>>>Thanks,
>>>
= >>>Ofer.
>>>
>>>
>>>--------= -----------------------------------------------
>>>This SF.Ne= t email is sponsored by Sleepycat Software>>>Learn develope= r strategies Cisco, Motorola, Ericsson & Lucent use to
>>>deliver higher performing products faster, = at low TCO.
>>>http://www.sleepycat.com/telcomwpreg.php?Fromd= nemail3
>>>_______________________________________________>>>Srtp-users mailing list
>>>Srtp-users@lists.sour= ceforge.net
>>>https://lists.sourceforge.net/lists/listinfo/s= rtp-users
>>>
>>
>>
>
>
>=
>_______________________________________________
>Audio/Vide= o Transport Working Group
>avt@ietf.org
>https://www1.ietf.or= g/mailman/listinfo/avt

___________________________________= ____________
Audio/Video Transport Working Group
avt@ietf.org
ht= tps://www1.ietf.org/mailman/listinfo/avt

Do you Yahoo!?
Yahoo! Movi= es - Buy advance tickets for 'Shrek 2' --0-705932148-1084349851=:41696-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed May 12 05:21:10 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19454 for ; Wed, 12 May 2004 05:21:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNpsp-0002pn-93 for avt-archive@odin.ietf.org; Wed, 12 May 2004 05:18:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C9IZK1010896 for avt-archive@odin.ietf.org; Wed, 12 May 2004 05:18:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNpka-0001Sd-EB; Wed, 12 May 2004 05:10:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNpgQ-0000R8-Kr for avt@optimus.ietf.org; Wed, 12 May 2004 05:05:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18871 for ; Wed, 12 May 2004 05:05:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNpgN-000455-FY for avt@ietf.org; Wed, 12 May 2004 05:05:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNpfR-0003bX-00 for avt@ietf.org; Wed, 12 May 2004 05:04:46 -0400 Received: from web61310.mail.yahoo.com ([216.155.196.153]) by ietf-mx with smtp (Exim 4.12) id 1BNpf2-00037q-00 for avt@ietf.org; Wed, 12 May 2004 05:04:20 -0400 Message-ID: <20040512090351.25785.qmail@web61310.mail.yahoo.com> Received: from [80.74.106.2] by web61310.mail.yahoo.com via HTTP; Wed, 12 May 2004 02:03:51 PDT Date: Wed, 12 May 2004 02:03:51 -0700 (PDT) From: tal shahar Subject: Re: [Srtp-users] [AVT] RFC 3711 - questions about cryptographic context To: "David A. McGrew" Cc: AVT , SRTP In-Reply-To: <3F8F83C8-A3B2-11D8-8B31-0003935495EC@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1249633816-1084352631=:24515" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --0-1249633816-1084352631=:24515 Content-Type: text/plain; charset=us-ascii hi David and thanks again I didnt define my question properly, the question is whether a key exchange will give me a list of / MKI and their master key along. or will I get one at a time. if I understand correct, the key exchange protocol can decide on giving me all (or some) of the keys in advance - this will require me (the SRTP implementation) to do something like switching master keys for the appropriate index - is it right ? about the second question we were pondring this issue for quite a while as far as I can understand the RFC does lean torward having the SRTP triggering this process I'd like to quote a few things from the RFC, please tell me what you think 1. 8.1. SRTP senders SHALL count the amount of SRTP and SRTCP traffic being used for a master key and invoke key management to re-key if needed. 2. (9.2) That is, when 2^48 SRTP packets or 2^31 SRTCP packets have been secured with the same key (whichever occurs before), the key management MUST be called to provide new master key(s) 3. (11.2) If there are more than one SRTP/SRTCP stream (within the same RTP session) that share the master key, the upper limit of 2^48 SRTP packets / 2^31 SRTCP packets means that, before one of the streams reaches its maximum number of packets, re-keying MUST be triggered on ALL streams sharing the master key. thanks a lot Tal "David A. McGrew" wrote: Tal, On May 10, 2004, at 12:22 AM, tal shahar wrote: > sorry, I missed the attachment > > Note: forwarded message attached. > > Do you Yahoo!? > Win a $20,000 Career Makeover at Yahoo! HotJobs > From: tal shahar > Date: May 9, 2004 7:26:00 AM PDT > To: "David A. McGrew" > Subject: Re: [Srtp-users] [AVT] RFC 3711 - questions about > cryptographic context > > > David hi and thanks a lot > as far as I understand, the key exchange protocol provides you with > the value. > so ,does the key exchange give you a bunch of values and > their corresponding keys. > another question, does this apply also to the MKI implementation, i.e. > the key exchange provides you with a list of MKIs and their > corresponding keys. Yes, if you're using an MKI, then the key management protocol will need to supply that value along with the key. Similarly, if a packet index pair is associated with a key, then the pair would need to be communicated with the key. This is described in Section 8.2. of RFC 3711, "Key Management Parameters". > > it is also not totally clear to me whether the sender triggers the > re-keying or should it be triggered in the key exchange protocol, and > the sender should just enforce it Good question, and it is clearly and important system design point. SRTP doesn't dictate how this is done. Clearly a key management system can provide new keys to an SRTP implementation, e.g. "here's a new key and the MKI to go with it". Also, an SRTP layer could trigger key management into getting new keys for it, though that is out of the scope of the RFC. In libSRTP, there is an event/callback system by which SRTP can indicate to another system that some interesting event happened (see Section 4.3 of the "libSRTP 1.3 Overview and Reference Manual"). Two of these events are: event_key_soft_limit An SRTP stream reached the soft key usage limit and will expire soon. event_key_hard_limit An SRTP stream reached the hard key usage limit and has expired. So the callback can recognize a key-expiration event and could call a key management function. Of course, the key management system would need to get the new key to all of the participants in the SRTP session. David > > "David A. McGrew" wrote: > Tal, > > On May 9, 2004, at 2:03 AM, tal shahar wrote: > > > hi > > in 3.2.1. Transform-independent parameters > > 1. the RFC states that the cryptographic context should hold the the > > master key(s) > > assuming I wish to have SRTP and SRTCP sharing the same master key, > > what is the situation where I have more than one key > > if I understand right, you are wondering why the "(s)" appears in the > quote from the RFC. This is because there might be multiple master > keys, each of which is used for a particular range of the packet index > (that is, the 48-bit integer that is the concatenation of the ROC and > the sequence number). libSRTP does not support this facility, and I > expect that the vast majority of users won't miss it. > > > > 2. if I have only one master key, why do I need to hold the MKI > > You don't, though you might need to store the fact that you are not > using an MKI. libSRTP does not support MKIs as of yet. I don't think > that it would be hard to add this feature. > > David > > > > > thanks a lot > > tal > > > > Do you Yahoo!? > > Win a $20,000 Career Makeover at Yahoo! HotJobs > > Do you Yahoo!? > Win a $20,000 Career Makeover at Yahoo! HotJobs --------------------------------- Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' --0-1249633816-1084352631=:24515 Content-Type: text/html; charset=us-ascii

hi David and thanks again

I didnt define my question properly, the question is whether a key exchange will give me a list of <from, to> / MKI and their master key along. or will I get one at a time.

if I understand correct, the key exchange protocol can decide on giving me all (or some) of the keys in advance - this will require me (the SRTP implementation) to do something like switching master keys for the appropriate index - is it right ?

about the second question

we were pondring this issue for quite a while

as far as I can understand the RFC does lean torward having the SRTP triggering this process

I'd like to quote a few things from the RFC, please tell me what you think

1. 8.1. SRTP senders SHALL count the amount of SRTP and SRTCP traffic being used for a master key and invoke key management to re-key if needed.

2. (9.2) That is, when 2^48 SRTP packets or 2^31 SRTCP packets have been secured
with the same key (whichever occurs before), the key management MUST be called to provide new master key(s)
3. (11.2) If there are more than one SRTP/SRTCP stream (within the same RTP session) that share the master key, the upper limit of 2^48 SRTP packets / 2^31 SRTCP packets means that, before one of the streams reaches its maximum number of packets, re-keying MUST be triggered on ALL streams sharing the master key.

thanks a lot

Tal
"David A. McGrew" <mcgrew@cisco.com> wrote:

Tal,

On May 10, 2004, at 12:22 AM, tal shahar wrote:

> sorry, I missed the attachment
>
> Note: forwarded message attached.
>
> Do you Yahoo!?
> Win a $20,000 Career Makeover at Yahoo! HotJobs
> From: tal shahar
> Date: May 9, 2004 7:26:00 AM PDT
> To: "David A. McGrew"
> Subject: Re: [Srtp-users] [AVT] RFC 3711 - questions about
> cryptographic context
>
>
> David hi and thanks a lot
> as far as I understand, the key exchange protocol provides you with
> the value.
> so ,does the key exchange give you a bunch of values and
> their corresponding keys.
> another question, does this apply also to the MKI implementation, i.e.
> the key exchange provides you with a list of MKIs and their!
> corresponding keys.

Yes, if you're using an MKI, then the key management protocol will need
to supply that value along with the key. Similarly, if a
packet index pair is associated with a key, then the pair would need to
be communicated with the key.

This is described in Section 8.2. of RFC 3711, "Key Management
Parameters".

>
> it is also not totally clear to me whether the sender triggers the
> re-keying or should it be triggered in the key exchange protocol, and
> the sender should just enforce it

Good question, and it is clearly and important system design point.
SRTP doesn't dictate how this is done. Clearly a key management system
can provide new keys to an SRTP implementation, e.g. "here's a new key
and the MKI to go with it". Also, an SRTP layer could trigger key
management into getting new keys for it, though that is out of the
scope of the RFC.

In libSRTP! , there is an event/callback system by which SRTP can
indicate to another system that some interesting event happened (see
Section 4.3 of the "libSRTP 1.3 Overview and Reference Manual"). Two
of these events are:

event_key_soft_limit An SRTP stream reached the soft key usage limit
and will expire soon.
event_key_hard_limit An SRTP stream reached the hard key usage limit
and has expired.

So the callback can recognize a key-expiration event and could call a
key management function. Of course, the key management system would
need to get the new key to all of the participants in the SRTP session.

David

>
> "David A. McGrew" wrote:
> Tal,
>
> On May 9, 2004, at 2:03 AM, tal shahar wrote:
>
> > hi
> > in 3.2.1. Transform-independent parameters
> > 1. the RFC states that the cryptographic context should hold the the
> > master key(s)
&g! t; > assuming I wish to have SRTP and SRTCP sharing the same master key,
> > what is the situation where I have more than one key
>
> if I understand right, you are wondering why the "(s)" appears in the
> quote from the RFC. This is because there might be multiple master
> keys, each of which is used for a particular range of the packet index
> (that is, the 48-bit integer that is the concatenation of the ROC and
> the sequence number). libSRTP does not support this facility, and I
> expect that the vast majority of users won't miss it.
>
>
> > 2. if I have only one master key, why do I need to hold the MKI
>
> You don't, though you might need to store the fact that you are not
> using an MKI. libSRTP does not support MKIs as of yet. I don't think
> that it would be hard to add this feature.
>
> David
>
> >
> > thanks a lot
> > tal> >
> > Do you Yahoo!?
> > Win a $20,000 Career Makeover at Yahoo! HotJobs
>
> Do you Yahoo!?
> Win a $20,000 Career Makeover at Yahoo! HotJobs

Do you Yahoo!?
Yahoo! Movies - Buy advance tickets for 'Shrek 2' --0-1249633816-1084352631=:24515-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed May 12 06:26:11 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21992 for ; Wed, 12 May 2004 06:26:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNqpB-0007Ku-59 for avt-archive@odin.ietf.org; Wed, 12 May 2004 06:18:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CAIrd9028195 for avt-archive@odin.ietf.org; Wed, 12 May 2004 06:18:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNqiW-0005HN-QY; Wed, 12 May 2004 06:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNiQC-0005gB-2M for avt@optimus.ietf.org; Tue, 11 May 2004 21:20:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12074 for ; Tue, 11 May 2004 21:20:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNiQ9-0002C4-Ek for avt@ietf.org; Tue, 11 May 2004 21:20:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNiPI-0001l1-00 for avt@ietf.org; Tue, 11 May 2004 21:19:37 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BNiOX-0001Gv-00 for avt@ietf.org; Tue, 11 May 2004 21:18:49 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4C1IHSu028429; Tue, 11 May 2004 18:18:18 -0700 (PDT) Received: from [128.107.163.107] (dhcp-128-107-163-107.cisco.com [128.107.163.107]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ATC10370; Tue, 11 May 2004 18:17:30 -0700 (PDT) In-Reply-To: <20040510072255.15027.qmail@web61310.mail.yahoo.com> References: <20040510072255.15027.qmail@web61310.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/alternative; boundary=Apple-Mail-1-790798629 Message-Id: <3F8F83C8-A3B2-11D8-8B31-0003935495EC@cisco.com> Cc: AVT , SRTP From: "David A. McGrew" Subject: Re: [Srtp-users] [AVT] RFC 3711 - questions about cryptographic context Date: Tue, 11 May 2004 18:18:17 -0700 To: tal shahar X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --Apple-Mail-1-790798629 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Tal, On May 10, 2004, at 12:22 AM, tal shahar wrote: > sorry, I missed the attachment > > Note: forwarded message attached. > > Do you Yahoo!? > Win a $20,000 Career Makeover at Yahoo! HotJobs > From: tal shahar > Date: May 9, 2004 7:26:00 AM PDT > To: "David A. McGrew" > Subject: Re: [Srtp-users] [AVT] RFC 3711 - questions about=20 > cryptographic context > > > David hi and thanks a lot > as far as I understand, the key exchange protocol provides you with=20 > the value. > so ,does the key exchange give you a bunch of values and=20 > their corresponding keys. > another question, does this apply also to the MKI implementation, i.e.=20= > the key exchange provides you with a list of MKIs and their=20 > corresponding keys. Yes, if you're using an MKI, then the key management protocol will need=20= to supply that value along with the key. Similarly, if a =20 packet index pair is associated with a key, then the pair would need to=20= be communicated with the key. This is described in Section 8.2. of RFC 3711, "Key Management=20 Parameters". > =A0 > it is also not totally clear to me whether the sender triggers the=20 > re-keying or should it be triggered in the key exchange protocol, and=20= > the sender should just enforce it Good question, and it is clearly and important system design point. =20 SRTP doesn't dictate how this is done. Clearly a key management system=20= can provide new keys to an SRTP implementation, e.g. "here's a new key=20= and the MKI to go with it". Also, an SRTP layer could trigger key=20 management into getting new keys for it, though that is out of the=20 scope of the RFC. In libSRTP, there is an event/callback system by which SRTP can=20 indicate to another system that some interesting event happened (see=20 Section 4.3 of the "libSRTP 1.3 Overview and Reference Manual"). Two=20 of these events are: event_key_soft_limit An SRTP stream reached the soft key usage limit=20= and will expire soon. event_key_hard_limit An SRTP stream reached the hard key usage limit=20= and has expired. So the callback can recognize a key-expiration event and could call a=20 key management function. Of course, the key management system would=20 need to get the new key to all of the participants in the SRTP session. David > > "David A. McGrew" wrote: > Tal, > > On May 9, 2004, at 2:03 AM, tal shahar wrote: > > > hi > > in 3.2.1.=A0 Transform-independent parameters > > 1. the RFC states that the cryptographic context should hold the the > > master key(s) > > assuming I wish to have SRTP and SRTCP sharing the same master key, > > what is the situation where I have more than one key > > if I understand right, you are wondering why the "(s)" appears in the > quote from the RFC. This is because there might be multiple master > keys, each of which is used for a particular range of the packet = index > (that is, the 48-bit integer that is the concatenation of the ROC and > the sequence number). libSRTP does not support this facility, and I > expect that the vast majority of users won't miss it. > > > > 2. if I have only one master key, why do I need to hold the MKI > > You don't, though you might need to store the fact that you are not > using an MKI. libSRTP does not support MKIs as of yet. I don't think > that it would be hard to add this feature. > > David > > > =A0 > > thanks a lot > > tal > > > > Do you Yahoo!? > > Win a $20,000 Career Makeover at Yahoo! HotJobs > > Do you Yahoo!? > Win a $20,000 Career Makeover at Yahoo! HotJobs= --Apple-Mail-1-790798629 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Tal, On May 10, 2004, at 12:22 AM, tal shahar wrote: sorry, I missed the attachment Note: forwarded message attached. Arial

Do you = Yahoo!?

= Arial0000,0000,EEEE

Win a $20,000 Career Makeover at Yahoo! = HotJobs

<= bold>0000,0000,0000 From: tal shahar < 0000,0000,0000Date: May 9, 2004 7:26:00 AM PDT 0000,0000,0000To: "David A. McGrew" < 0000,0000,0000Subject: Re: [Srtp-users] [AVT] RFC 3711 - questions about cryptographic context David hi and thanks a lot as far as I understand, the key exchange protocol provides you with the < value. so ,does the key exchange give you a bunch of < values and their corresponding keys. another question, does this apply also to the MKI implementation, i.e. the key exchange provides you with a list of MKIs and their corresponding keys. Yes, if you're using an MKI, then the key management protocol will need to supply that value along with the key. Similarly, if a < packet index pair is associated with a key, then the pair would need to be communicated with the key. =20 This is described in Section 8.2. of RFC 3711, "Key Management Parameters". =A0 it is also not totally clear to me whether the sender triggers the re-keying or should it be triggered in the key exchange protocol, and the sender should just enforce it Good question, and it is clearly and important system design point.=20 SRTP doesn't dictate how this is done. Clearly a key management system can provide new keys to an SRTP implementation, e.g. "here's a new key and the MKI to go with it". Also, an SRTP layer could trigger key management into getting new keys for it, though that is out of the scope of the RFC. In libSRTP, there is an event/callback system by which SRTP can indicate to another system that some interesting event happened (see Section 4.3 of the "libSRTP 1.3 Overview and Reference Manual"). Two of these events are: event_key_soft_limit An SRTP stream reached the soft key usage limit and will expire soon.=20 event_key_hard_limit An SRTP stream reached the hard key usage limit and has expired.=20 So the callback can recognize a key-expiration event and could call a key management function. Of course, the key management system would need to get the new key to all of the participants in the SRTP session. =20 David "David A. McGrew" < wrote: Tal, On May 9, 2004, at 2:03 AM, tal shahar wrote: > hi > in 3.2.1.=A0 Transform-independent parameters > 1. the RFC states that the cryptographic context should hold the the > master key(s) > assuming I wish to have SRTP and SRTCP sharing the same master key, > what is the situation where I have more than one key if I understand right, you are wondering why the "(s)" appears in the quote from the RFC. This is because there might be multiple master keys, each of which is used for a particular range of the packet index (that is, the 48-bit integer that is the concatenation of the ROC and the sequence number). libSRTP does not support this facility, and I=20 expect that the vast majority of users won't miss it. > 2. if I have only one master key, why do I need to hold the MKI You don't, though you might need to store the fact that you are not using an MKI. libSRTP does not support MKIs as of yet. I don't think that it would be hard to add this feature. David > =A0 > thanks a lot > tal > > Do you Yahoo!? > Win a $20,000 Career Makeover at Yahoo! HotJobs Arial

Do you = Yahoo!?

= Arial0000,0000,EEEE

Win a $20,000 Career Makeover at Yahoo! = HotJobs

= --Apple-Mail-1-790798629-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed May 12 09:56:43 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04082 for ; Wed, 12 May 2004 09:56:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNu47-0005n8-W1 for avt-archive@odin.ietf.org; Wed, 12 May 2004 09:46:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CDkV1r022263 for avt-archive@odin.ietf.org; Wed, 12 May 2004 09:46:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNtlN-0001O1-0Q; Wed, 12 May 2004 09:27:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNtcf-0007Ln-8x for avt@optimus.ietf.org; Wed, 12 May 2004 09:18:09 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00784; Wed, 12 May 2004 09:18:06 -0400 (EDT) Message-Id: <200405121318.JAA00784@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: avt@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 12 May 2004 09:18:06 -0400 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-3gpp-timed-text-01.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart 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 Format for 3GPP Timed Text Author(s) : J. Rey, Y. Matsui Filename : draft-ietf-avt-rtp-3gpp-timed-text-01.txt Pages : 33 Date : 2004-5-11 This document specifies an RTP payload format for the transmission of 3GPP (3rd Generation Partnership Project) timed text. 3GPP timed text is a time-lined decorated text media format with defined storage in a 3GP file. Timed Text can be synchronised with audio/video contents. As of today, 3GP files containing timed text contents can only be downloaded via HTTP. There is no available mechanism for streaming 3GPP timed text contents neither out of 3GP files nor directly from live content. In the following sections the problems of streaming timed text are addressed and a payload format for streaming 3GPP timed text over RTP is specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-3gpp-timed-text-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-3gpp-timed-text-01.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@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-3gpp-timed-text-01.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-12093820.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-3gpp-timed-text-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-3gpp-timed-text-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-12093820.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed May 12 13:47:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29313 for ; Wed, 12 May 2004 13:47:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNxi4-0005M1-Jd for avt-archive@odin.ietf.org; Wed, 12 May 2004 13:40:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CHe0nr020579 for avt-archive@odin.ietf.org; Wed, 12 May 2004 13:40:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNxXZ-0001eS-Eu; Wed, 12 May 2004 13:29:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNvLJ-0000mo-NG for avt@optimus.ietf.org; Wed, 12 May 2004 11:08:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14669 for ; Wed, 12 May 2004 11:08:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNvLG-0005kt-Su for avt@ietf.org; Wed, 12 May 2004 11:08:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNvHq-0004j5-00 for avt@ietf.org; Wed, 12 May 2004 11:04:47 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1BNvDg-000388-00 for avt@ietf.org; Wed, 12 May 2004 11:00:28 -0400 Received: from mangole ([130.209.247.112]:55076) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:RC4-MD5:128) (Exim 4.04) id 1BNvD9-0005wD-00; Wed, 12 May 2004 15:59:55 +0100 From: Colin Perkins Organization: http://csperkins.org To: Date: Wed, 12 May 2004 15:59:55 +0100 User-Agent: KMail/1.6.2 Cc: , References: <0B08EA1BF5F6304992CDC985EE02209E02342986@sdebe002.americas.nokia.com> In-Reply-To: <0B08EA1BF5F6304992CDC985EE02209E02342986@sdebe002.americas.nokia.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200405121559.55346.csp@csperkins.org> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [AVT] Re: draft-ahmadi-avt-rtp-vmr-wb-01.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wednesday 05 May 2004 18:57, sassan.ahmadi@nokia.com wrote: ... > In the revised draft I have addressed all of your comments and concerns > about the original draft. Major changes include > > 1- All comments from AVT chairs are addressed. > 2- A header-free payload format has been added (just like RFC 3558) > 3- Bandwidth-efficient mode is eliminated. > 4- By some changes in Tables 2 and 3 in Section 6, the interworking > function is completely eliminated. > 5- The size of MIME parameter set has been reduced. The extra MIME > parameters have been removed. > 6- CDMA system issues have been removed from the document. > 7- Signaling conflicts with AMR-WB have all been resolved both in the > payload and the storage formats. > > Attached please find a PowerPoint presentation comprising highlights of > the revised Internet Draft. Also please find the draft as well as > detailed response to Magnus' comments. > > Considering the improvements and corrections that have been made in the > revised draft, I would like to kindly ask IETF/AVT group to accept this > Internet Draft as an AVT group work item now. > > I also kindly ask you to provide your feedback and comments to complete > and finalize a RFC for VMR-WB. This is certainly greatly improved, however it does not address my concern with respect to the signalling of AMR-WB compatible modes. I would suggest you study the Offer-Answer Model Considerations for the AMR-WB+ payload format (draft-sjoberg-avt-rtp-amrwbplus-01.txt) and follow a similar model for interoperability (i.e. require a VMR-WB capable endpoint to advertise support for the AMR-WB payload format, in addition to native VMR-WB, as an way of avoiding interoperability problems). With that change made, I believe this would be appropriate to accept as an AVT work item (provided there are no other objections from the list). -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed May 12 15:38:38 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06103 for ; Wed, 12 May 2004 15:38:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzSO-0001Z5-0b for avt-archive@odin.ietf.org; Wed, 12 May 2004 15:31:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CJVtwi006016 for avt-archive@odin.ietf.org; Wed, 12 May 2004 15:31:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzI1-0006Xr-5A; Wed, 12 May 2004 15:21:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzAr-0002Yc-Kw for avt@optimus.ietf.org; Wed, 12 May 2004 15:13:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04279 for ; Wed, 12 May 2004 15:13:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNzAq-0001wV-9c for avt@ietf.org; Wed, 12 May 2004 15:13:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNz9t-0001S1-00 for avt@ietf.org; Wed, 12 May 2004 15:12:51 -0400 Received: from news.ti.com ([192.94.94.33] helo=dragon.ti.com) by ietf-mx with esmtp (Exim 4.12) id 1BNz9I-0000x8-00 for avt@ietf.org; Wed, 12 May 2004 15:12:12 -0400 Received: from dlep91.itg.ti.com ([157.170.152.55]) by dragon.ti.com (8.12.11/8.12.11) with ESMTP id i4CJBekm019886; Wed, 12 May 2004 14:11:41 -0500 (CDT) Received: from tnint11.telogy.design.ti.com (localhost [127.0.0.1]) by dlep91.itg.ti.com (8.12.11/8.12.11) with ESMTP id i4CJBdBA007889; Wed, 12 May 2004 14:11:40 -0500 (CDT) Received: by tnint11.telogy.design.ti.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 May 2004 15:11:07 -0400 Message-ID: <09DD40ABD88ACF4CB0D3CD84BB95296001B46B@tnint11.telogy.design.ti.com> From: "Mundra, Satish" To: "'Gunnar Hellstrom'" , "Paul E. Jones" , avt IETF Subject: RE: [avt] Comments/questions on draft-ietf-avt-rfc2793bis-04 Date: Wed, 12 May 2004 15:11:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Gunnar, responses inline... > -----Original Message----- > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > Sent: Tuesday, May 11, 2004 6:32 PM > To: Mundra, Satish; Paul E. Jones; avt IETF > Subject: RE: [avt] Comments/questions on draft-ietf-avt-rfc2793bis-04 >=20 >=20 > Satish, > I get the impression that your main goal with the discussion > is to try to find a format for audio/red/t140 that could=20 > allow us to drop the t140block counter from the format. >=20 > Is the reason saving bits? >=20 Yes, saving six bytes per audio/red/t140 packet could buy one more = level of redundancy=20 if needed. If you feel that it's required for reliable operations, and change at = this stage is not desirable, that's fine with me.=20 > We have had it there since August, with no major concerns, so > it seems acceptable to most reviewers. >=20 > You also want to use the M-bit as in RFC3551. > > The M-bit behavior is from (RFC3551): "For applications which send > > either no packets or occasional comfort-noise packets=20 > during silence, > > the first packet > > of a talkspurt, that is, the first packet after a silence > period during > > which packets have not been transmitted contiguously, SHOULD be=20 > > distinguished by setting the marker bit in the RTP data > header to one." > That can be OK. But then you must not do anything drastic, > such as adding a missing text marker just because the packet=20 > with the M-bit seems to be missing. With 10% packet loss, 10%=20 > of the M-bits will be missing, but only 0.1% of text, if we=20 > are using primary and two redundant transmissions. >=20 One need not solely depend on the missing primary with marker to = conclude loss of=20 t140 data for audio/red/t140.=20 Assuming that 10% of M-bits are lost:=20 If the total number of consecutive packets lost is less than the = redundancy level in use, one can easily determine if the missing sequence numbers = were carrying text or voice.=20 At other times I agree that it may not be obvious. It seems like one = could use both the timestamp gap and sequence number gap to determine if any text was = lost. Note that=20 when text is transmitted the sequence numbers increments by 1 every 300/500ms where =20 as for voice it would be every 20/30ms or so.=20 > Would it be OK to you to take in the text about the M-bit=20 > from RFC3551? >=20 Yes. Thanks, --Satish > Gunnar >=20 >=20 > ------------------------------------------- > Gunnar Hellstr=F6m > Omnitor AB > Renathv=E4gen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- >=20 >=20 > > -----Original Message----- > > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of=20 > > Mundra, Satish > > Sent: Tuesday, May 11, 2004 7:19 PM > > To: 'Gunnar Hellstrom'; Paul E. Jones; avt IETF > > Subject: RE: [avt] Comments/questions on=20 > draft-ietf-avt-rfc2793bis-04 > > > > > > Gunnar/Paul, > > > > Thanks for summarizing the questions. The previous comments got=20 > > cross-posted, I have used your latest posting for further debate on = > > the questions/comments. See comments inline... > > > > Regards, > > > > Satish Mundra > > > > > -----Original Message----- > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > > Sent: Monday, May 10, 2004 6:29 PM > > > To: Paul E. Jones; Mundra, Satish; avt IETF > > > Subject: RE: [avt] Comments/questions on=20 > > > draft-ietf-avt-rfc2793bis-04 > > > > > > > > > Satish, > > > I am eager to come to conclusions on your questions regarding=20 > > > draft-ietf-avt-rfc2793bis-04. > > > > > > Our (Paul=B4s and mine ) understanding regarding the questions = are=20 > > > now: > > > > > > 1. Security risk to have the 16-bit T140block counter to always=20 > > > start at 0 in a session. I mentioned that loss in the beginning=20 > > > could be detected by the text stream not starting with=20 > the Unicode=20 > > > synchronization character, because the requirement to start with=20 > > > that code is clearly stated in T.140. So, that could be=20 > used and the=20 > > > counter could then start at a random value. However, also this=20 > > > session start code can be seen as a security risk with the same=20 > > > reason as the 0 counter would be one. Are not all media full of > > > predictable bit patterns, like picture start headers, audio > > > session parameters etc? > > > > > > We would like to hear more voices if it is important to start the = > > > counter at a random value, and instead rely on detection=20 > of initial=20 > > > loss by a missing Unicode Synchronization character. > > > > > > > See comments on the "t140block counter" below. > > > > > 2. M-bit for indication of start of text. > > > You hint that we should specify that the M-bit SHALL be used as=20 > > > indicated in the AVT profile for indicating start of text=20 > initially=20 > > > in the stream and also after a gap. This could be used both to=20 > > > detect loss and in order to detect when suspected loss is=20 > only loss=20 > > > of empty text blocks. > > > > > > > Yes. > > > > > Each M-bit is only sent once, so it does not get improved=20 > > > reliability by redundancy. We have a mechanism with=20 > marking missing=20 > > > text with a Unicode replacement character, specified in=20 > T.140. If in=20 > > > doubt, it is better to mark too much than too little,=20 > because there=20 > > > will be non-printable characters that will be marked by this=20 > > > character when lost. Therefore the users might know that=20 > there can=20 > > > be markers for missing text without any visible text missing. > > > > > > > Let me understand this again, the requirement for the=20 > payload format=20 > > is to NOT fail in detecting LOSS when occurs, misleading loss=20 > > indicators are unavoidable and seem to be acceptable. [see further=20 > > comments on the block counter below] > > > > > So, for audio/t140, we can select between three methods for=20 > > > indicating the start of stream: a. counter =3D0 b. M-bit =20 > c. Unicode=20 > > > start of stream character > > > > > > > See comments on counter below. > > > > > For text/t140, we can only select between two methods: > > > a. M-bit > > > b. Unicode start of stream character > > > > > > A missing M-bit does not give full information if a real text=20 > > > element is missing. The text might be received in=20 > redundant code. =20 > > > But it can be used as a likely indication. > > > > > > The other methods are at least as reliable as the redundant=20 > > > transmission method used. > > > > > > > > > For text during a session, we have the following problem:=20 > What is a=20 > > > gap? When shall the M-bit be set to 1? What is a text-spurt? > > > > > > > Borrowing from section 5.4 of draft(04), gap would be "no new T.140 = > > data to transmit after the transmit buffering interval described in > > section 5.1 has > > passed". This defines the text-spurt which is analogous to=20 > talkspurt. > > > > The M-bit behavior is from (RFC3551): "For applications which send=20 > > either no packets or occasional comfort-noise packets=20 > during silence,=20 > > the first packet > > of a talkspurt, that is, the first packet after a silence=20 > period during > > which packets have not been transmitted contiguously, SHOULD be > > distinguished by setting the marker bit in the RTP data=20 > header to one." > > > > > For text/t140, it is hard to find a good delimitation for when a=20 > > > text-spurt starts. There is no declaration of the time=20 > between the=20 > > > packets, just the buffering time that normally may be 300 ms, but = > > > may vary. For the text/red/t140 case, there could be a=20 > reason to use=20 > > > the M-bit, when only the primary data contains valid=20 > text. The other=20 > > > blocks should be empty or non-existing. That is the case after a=20 > > > pause. Detection of an M-bit can make sure that the risk=20 > is kept low > > > for falsely marking loss of data during the pause. Without > > > the use of the M-bit, falsely marking lost text will occur > > > slightly more often. > > > > > > > The text-spurt starts with the packet that you transmit after a=20 > > zero-length block is transmitted, that happens whenever the T.140=20 > > buffering interval expires and no new data > > is available for transmission. > > > > > > > For the plain text/t140 format, I do not see any need for marking = > > > the first packet after a longer pause. > > > > > > > It helps in situations when one can not include a=20 > zero-length block as=20 > > redundant data because it's too old. > > > > > For red/audio/t140 I see no need for the M-bit. The=20 > counter give a=20 > > > better reliability. > > > > > > > During a interval where text is transmitted contiguously, the=20 > > block-counter and the RTP sequence numbers are in sync. So=20 > I guess the=20 > > counter is only useful at the boundaries when > > switchover between voice/text payload is occurring. Under=20 > certain loss > > scenarios or when both marker and zero-length blocks are lost > > one could have > > misleading text loss-indicator which in any case are > > unavoidable. In either > > case you would detect loss as required. > > > > As I mentioned earlier, I am unconvinced about the=20 > usefulness of the=20 > > block counter. During contiguous text transmission the=20 > counter and RTP=20 > > sequence numbers are in sync. Even if marker is lost, one=20 > could sync=20 > > to the first sequence number that can be deriver or is=20 > present in the=20 > > header. IMO, different redundancy rules for text/t140 and=20 > audio/t140=20 > > can be unified and > > implementation simplified. > > > > > The current RFC2793 does not specify the use of the M-bit.=20 > > > RFC2793bis should be compatible with RFC2793 for text/t140 and=20 > > > text/red/t140. Using the M-bit for RFC2793 bis would be a=20 > step off=20 > > > from that direction. > > > > > > Anyway, it does little harm, so if there are voices for=20 > it, we could=20 > > > say that the transmitter MUST use the M-bit to indicate start of=20 > > > stream, and start after a pause. The receiver MAY use it for=20 > > > detection of loss. > > > > > > > > > Please advice > > > > > > Regards > > > > > > Gunnar > > > -------------------------------------------------------------- > > > ------------- > > > ------- > > > > > > > > > Satish, > > > Further answers inline, > > > > > > Gunnar > > > > > > ------------------------------------------- > > > Gunnar Hellstr=F6m > > > Omnitor AB > > > Renathv=E4gen 2 > > > SE 121 37 Johanneshov > > > SWEDEN > > > +46 8 556 002 03 > > > Mob: +46 708 204 288 > > > www.omnitor.se > > > Gunnar.Hellstrom@Omnitor.se > > > -------------------------------------------- > > > > > > > > > > -----Original Message----- > > > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > > > Sent: Thursday, May 06, 2004 11:10 PM > > > > To: Mundra, Satish; 'Gunnar Hellstrom'; avt IETF > > > > Subject: Re: [avt] Comments/questions on=20 > > > > draft-ietf-avt-rfc2793bis-03/04 > > > > > > > > > > > > X--------snip > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www1.ietf.org/mailman/listinfo/avt > > > > >=20 >=20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed May 12 16:53:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10614 for ; Wed, 12 May 2004 16:53:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO0ZN-0004Zj-WC for avt-archive@odin.ietf.org; Wed, 12 May 2004 16:43:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CKhDLS017587 for avt-archive@odin.ietf.org; Wed, 12 May 2004 16:43:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO0Na-0000n4-C3; Wed, 12 May 2004 16:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO0JR-0007mu-Ce for avt@optimus.ietf.org; Wed, 12 May 2004 16:26:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08892 for ; Wed, 12 May 2004 16:26:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO0JP-00013G-Hm for avt@ietf.org; Wed, 12 May 2004 16:26:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO0IO-0000We-00 for avt@ietf.org; Wed, 12 May 2004 16:25:41 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BO0HQ-0007Kj-00 for avt@ietf.org; Wed, 12 May 2004 16:24:40 -0400 Received: from mbaugher-w2k07.cisco.com (sjc-vpn4-390.cisco.com [10.21.81.134]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i4CKO5jP015064; Wed, 12 May 2004 13:24:05 -0700 (PDT) Message-Id: <6.0.0.22.2.20040512131446.03fbbcf0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 12 May 2004 13:24:02 -0700 To: tal shahar From: Mark Baugher Subject: Re: [Srtp-users] RE: [AVT] and MKI, FRC 3711 Cc: AVT , SRTP In-Reply-To: <20040512081731.42959.qmail@web61303.mail.yahoo.com> References: <6.0.0.22.2.20040511162350.04282df8@mira-sjc5-6.cisco.com> <20040512081731.42959.qmail@web61303.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable hi At 01:17 AM 5/12/2004, tal shahar wrote: >hi Mark >I'm not sure I understand your point >do you suggest that one master key can have a few sets of SRTP session=20 >keys simultaniously in use ? Yes. At minimum, we'll likely have SRTP and SRTCP session keys derived=20 from the master keys (pg 9 of RFC 3711). >i.e. can it happen that for the same master key, different streams will=20 >have different SRTP session keys Yes, beyond SRTP and SRTCP (see pg 10). >I'm asking this since the procedure of deriving a session key from a given= =20 >master key does not include the use of SSRC - therefore I dont understand= =20 >how different streams will have different session keys. The keystreams are differentiated with the SSRCs, not the keys themselves=20 (see pg 21). >as for the , as far as I understand ,this value is used to=20 >define a master key "life time" ,it doesnt help you define a sequence=20 >number space per a session key ? My point is that are sequence numbers, or extended sequence=20 numbers computed from the SEQ and the ROC. SRTP streams have sequence=20 numbers and there is the _potential_ for a problem or at least some=20 additional complexity when you derive multiple session keys (for individual= =20 streams) from a given master key since you at least have to signal which=20 sequence number space is being used for the from-to. Mark >Mark Baugher wrote: >>Yes, I think calling the interactions "insecure" as I did is not >>accurate. There is the following issue as I see it: An SRTP master >>key can be associated with one or more session keys each having its >>own sequence-number space. So the master key per se does not have >>a sequence-number space but from-to is used to determine when to >>change master keys. If the master key is always in one-one >>relationship with a session key, then there is no ambiguity. >>But if the master key is used to derive two or more session keys, >>then the from-to is not well defined. >> >>Is this "insecure?" Probably not. >> >>Mark >>space. So from-to works on >>At 12:49 PM 5/11/2004, Mats N=E4slund wrote: >> >> >Hi >> > >> >What I think Mark refers to is a situation in which >> > >> >- several SRTP streams share a master key, and, >> >- re-keying is based on From-To values. >> > >> >If you use SRTP in this way (which RFC3711 recommends against) >> >the receiver may in some cases have problem determining the correct >> >key. However, there is really no "extra" security problems involved. >> >What *could* happen is a so-called two-time pad, but this would be >> >caused by a misstake by the sender, not by the receiver. Furthermore, >> >this key sharing is not allowed in RFC3711, unless you can guarantee >> >distinct SSRCs for the RTP sessions sharing the key. Whence, if you >> >(somehow) could guarantee such SSRC-distincness, two-time pads would >> >anyway not occur. >> > >> >Cheers >> > >> >/Mats >> > >> >Mark Baugher wrote: >> > >> >>hi >> >> Using both mechanisms is a lot of complexity and I'm hard pressed to >> >> find examples of when we would need two mechanisms, which do the same >> >> thing. I don't like that final sentence in 8.1.1 in RFC 3711 because >> >> complexity undermines security and using both mechanisms is complex. >> >> >> >> From/To has the advantage of not adding a field to the packet, but it >> >> has the disadvantage of insecure interactions with the AES counter= mode >> >> transform. MKI adds a field but does not suffer from this problem. I >> >> would choose one or the other but not both. >> >> >> >> As it is described below, use of both mechanisms is superfluous= AFAICT. >> >> >> >>Mark >> >> >> >>At 05:56 AM 5/11/2004, Sylvain Latulippe wrote: >> >> >> >> >> >> >> >>>Hi, >> >>> >> >>>My understanding is the following: >> >>> >> >>>Both mechanisms can be used whitin the same session. When using MKI, >> >>> mechanism can be used by the sender side for synchronizing >> >>>key transitions (re-keying). >> >>> >> >>>For example: >> >>> >> >>>A session is started and 2 keys (KEY_1 and KEY_2) are given to the=20 >> session. >> >>> >> >>>Session parameters: >> >>>KEY FROM TO MKI >> >>>KEY_1 0 10 1 >> >>>KEY_2 11 x 2 >> >>> >> >>>The sender uses KEY_1 to encrypt packets with index 0 to 10. MKI =3D 1= is >> >>>also appended to packets 0 to 10. When building packet with index 11, >> >>>the sender switches to KEY_2 and appends MKI =3D 2 to the packet. >> >>> >> >>>On the receiver side, is not required in this scenario. MKI >> >>>is extracted from the received packet and used to retrieve the right= key. >> >>> >> >>>Sylvain >> >>> >> >>> >> >>> >> >>> >> >>>-----Original Message----- >> >>>From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Ofer= =20 >> Goren >> > >Sent: 11 mai, 2004 07:35 >> >>>To: avt@ietf.org; srtp-users@lists.sourceforge.net >> >>>Subject: [AVT] and MKI, FRC 3711 >> >>> >> >>> >> >>>Hi. >> >>> >> >>>In RFC 3711, section 8.1.1, it says that "using the MKI does not= exclude >> >>>using key >> >>> lifetime simultaneously". >> >>> >> >>>As I understand it, both mechanisms can be used for the same session >> >>>simultaneously. However, does the mechanism is MANDATORY to >> >>>be used every time (whether is used or not), or can I omit it >> >>>if I'm using MKI? >> >>> >> >>>Thanks, >> >>> >> >>>Ofer. >> >>> >> >>> >> >>>------------------------------------------------------- >> >>>This SF.Net email is sponsored by Sleepycat Software>>>Learn=20 >> developer strategies Cisco, Motorola, Ericsson & Lucent use to >> >>>deliver higher performing products faster, at low TCO. >> >>>http://www.sleepycat.com/telcomwpreg.php?Fromdnemail3 >> >>>_______________________________________________ >> >>>Srtp-users mailing list >> >>>Srtp-users@lists.sourceforge.net >> >>>https://lists.sourceforge.net/lists/listinfo/srtp-users >> >>> >> >> >> >> >> > >> > >> > >> >_______________________________________________ >> >Audio/Video Transport Working Group >> >avt@ietf.org >> >https://www1.ietf.org/mailman/listinfo/avt >> >> >> >>_______________________________________________ >>Audio/Video Transport Working Group >>avt@ietf.org >>https://www1.ietf.org/mailman/listinfo/avt > > >Do you Yahoo!? >Yahoo! Movies -=20 >Buy advance=20 >tickets for 'Shrek 2' _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed May 12 20:47:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22560 for ; Wed, 12 May 2004 20:47:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO4B0-0003R3-OH for avt-archive@odin.ietf.org; Wed, 12 May 2004 20:34:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4D0YIfn013206 for avt-archive@odin.ietf.org; Wed, 12 May 2004 20:34:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO444-0001pI-Ly; Wed, 12 May 2004 20:27:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO2ap-0000Eo-5B for avt@optimus.ietf.org; Wed, 12 May 2004 18:52:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17110 for ; Wed, 12 May 2004 18:52:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO2am-00053m-0z for avt@ietf.org; Wed, 12 May 2004 18:52:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO2Zk-0004YP-00 for avt@ietf.org; Wed, 12 May 2004 18:51:46 -0400 Received: from av7-1-sn4.m-sp.skanova.net ([81.228.10.110]) by ietf-mx with esmtp (Exim 4.12) id 1BO2Yb-0003aR-00 for avt@ietf.org; Wed, 12 May 2004 18:50:34 -0400 Received: by av7-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id C0E7237F5A; Thu, 13 May 2004 00:50:02 +0200 (CEST) Received: from smtp2-1-sn4.m-sp.skanova.net (smtp2-1-sn4.m-sp.skanova.net [81.228.10.183]) by av7-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id AFEAC37E45; Thu, 13 May 2004 00:50:02 +0200 (CEST) Received: from vit (h53n2fls31o265.telia.com [217.208.189.53]) by smtp2-1-sn4.m-sp.skanova.net (Postfix) with SMTP id 5433037E42; Thu, 13 May 2004 00:50:02 +0200 (CEST) From: "Gunnar Hellstrom" To: "Mundra, Satish" , "Paul E. Jones" , "avt IETF" Subject: RE: [avt] Comments/questions on draft-ietf-avt-rfc2793bis-04 Date: Thu, 13 May 2004 00:50:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: <09DD40ABD88ACF4CB0D3CD84BB95296001B46B@tnint11.telogy.design.ti.com> Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Satish, I have tried to find a possible procedure that could make the T140block counters superflous for audio/red/t140, and still being able to detect if text was lost. I have not found any method, so I think that the t140block counter is a suitable solution that we need to stick to for now. Here are some traces of what I tried: The format can be that we always include the redundant blocks, even if th= ey contain no text. If an empty block is older than 16383 ticks, it is included, but the time offset is set to 0. We also always use the redundancy format once it is used in a session. ( thus not go back and forth between plain and redundant format ) We can also say that we include the M-bit after a pause, in the packet where new text is included as primary data. A pause is identified by that there was a need to send at least one packe= t with at least one empty t140block. If, at reception, a sequence number gap larger than the number of text generations we use for transmission is revealed, we check if the last received text packet before the gap contained any empty t140blocks. If no= t, we are at risk of having lost text. But, we have no way to tell if we really lost anything or not, because we do not know how many of the lost packets were text and how many were audio packets. So, I prefer to maintain the format with the counters for audio/t140, assuming that we maintain the ambition to mark where text is missing. The M-bit is irrelevant for that decision, but it can give you the positi= ve information that you received the first packet of a medium, so that you i= n that case can deduct if you lost anything of the medium in the packets before the M-bit. Gunnar ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Mundra= , > Satish > Sent: Wednesday, May 12, 2004 9:11 PM > To: 'Gunnar Hellstrom'; Paul E. Jones; avt IETF > Subject: RE: [avt] Comments/questions on draft-ietf-avt-rfc2793bis-04 > > > Gunnar, > > responses inline... > > > -----Original Message----- > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > Sent: Tuesday, May 11, 2004 6:32 PM > > To: Mundra, Satish; Paul E. Jones; avt IETF > > Subject: RE: [avt] Comments/questions on draft-ietf-avt-rfc2793bis-04 > > > > > > Satish, > > I get the impression that your main goal with the discussion > > is to try to find a format for audio/red/t140 that could > > allow us to drop the t140block counter from the format. > > > > Is the reason saving bits? > > > > Yes, saving six bytes per audio/red/t140 packet could buy one > more level of > redundancy > if needed. > If you feel that it's required for reliable operations, and > change at this > stage is not > desirable, that's fine with me. > > > We have had it there since August, with no major concerns, so > > it seems acceptable to most reviewers. > > > > You also want to use the M-bit as in RFC3551. > > > The M-bit behavior is from (RFC3551): "For applications which send > > > either no packets or occasional comfort-noise packets > > during silence, > > > the first packet > > > of a talkspurt, that is, the first packet after a silence > > period during > > > which packets have not been transmitted contiguously, SHOULD be > > > distinguished by setting the marker bit in the RTP data > > header to one." > > That can be OK. But then you must not do anything drastic, > > such as adding a missing text marker just because the packet > > with the M-bit seems to be missing. With 10% packet loss, 10% > > of the M-bits will be missing, but only 0.1% of text, if we > > are using primary and two redundant transmissions. > > > > One need not solely depend on the missing primary with marker to conclu= de > loss of > t140 data for audio/red/t140. > > Assuming that 10% of M-bits are lost: > If the total number of consecutive packets lost is less than the > redundancy > level in use, one can easily determine if the missing sequence > numbers were > carrying text or voice. > At other times I agree that it may not be obvious. It seems > like one could > use both > the timestamp gap and sequence number gap to determine if any > text was lost. > Note that > when text is transmitted the sequence numbers increments by 1 every > 300/500ms where > as for voice it would be every 20/30ms or so. > > > > > > > Would it be OK to you to take in the text about the M-bit > > from RFC3551? > > > > Yes. > > > Thanks, > > --Satish > > > > > > Gunnar > > > > > > ------------------------------------------- > > Gunnar Hellstr=F6m > > Omnitor AB > > Renathv=E4gen 2 > > SE 121 37 Johanneshov > > SWEDEN > > +46 8 556 002 03 > > Mob: +46 708 204 288 > > www.omnitor.se > > Gunnar.Hellstrom@Omnitor.se > > -------------------------------------------- > > > > > > > -----Original Message----- > > > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of > > > Mundra, Satish > > > Sent: Tuesday, May 11, 2004 7:19 PM > > > To: 'Gunnar Hellstrom'; Paul E. Jones; avt IETF > > > Subject: RE: [avt] Comments/questions on > > draft-ietf-avt-rfc2793bis-04 > > > > > > > > > Gunnar/Paul, > > > > > > Thanks for summarizing the questions. The previous comments got > > > cross-posted, I have used your latest posting for further debate on > > > the questions/comments. See comments inline... > > > > > > Regards, > > > > > > Satish Mundra > > > > > > > -----Original Message----- > > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > > > Sent: Monday, May 10, 2004 6:29 PM > > > > To: Paul E. Jones; Mundra, Satish; avt IETF > > > > Subject: RE: [avt] Comments/questions on > > > > draft-ietf-avt-rfc2793bis-04 > > > > > > > > > > > > Satish, > > > > I am eager to come to conclusions on your questions regarding > > > > draft-ietf-avt-rfc2793bis-04. > > > > > > > > Our (Paul=B4s and mine ) understanding regarding the questions ar= e > > > > now: > > > > > > > > 1. Security risk to have the 16-bit T140block counter to always > > > > start at 0 in a session. I mentioned that loss in the beginning > > > > could be detected by the text stream not starting with > > the Unicode > > > > synchronization character, because the requirement to start with > > > > that code is clearly stated in T.140. So, that could be > > used and the > > > > counter could then start at a random value. However, also this > > > > session start code can be seen as a security risk with the same > > > > reason as the 0 counter would be one. Are not all media full of > > > > predictable bit patterns, like picture start headers, audio > > > > session parameters etc? > > > > > > > > We would like to hear more voices if it is important to start the > > > > counter at a random value, and instead rely on detection > > of initial > > > > loss by a missing Unicode Synchronization character. > > > > > > > > > > See comments on the "t140block counter" below. > > > > > > > 2. M-bit for indication of start of text. > > > > You hint that we should specify that the M-bit SHALL be used as > > > > indicated in the AVT profile for indicating start of text > > initially > > > > in the stream and also after a gap. This could be used both to > > > > detect loss and in order to detect when suspected loss is > > only loss > > > > of empty text blocks. > > > > > > > > > > Yes. > > > > > > > Each M-bit is only sent once, so it does not get improved > > > > reliability by redundancy. We have a mechanism with > > marking missing > > > > text with a Unicode replacement character, specified in > > T.140. If in > > > > doubt, it is better to mark too much than too little, > > because there > > > > will be non-printable characters that will be marked by this > > > > character when lost. Therefore the users might know that > > there can > > > > be markers for missing text without any visible text missing. > > > > > > > > > > Let me understand this again, the requirement for the > > payload format > > > is to NOT fail in detecting LOSS when occurs, misleading loss > > > indicators are unavoidable and seem to be acceptable. [see further > > > comments on the block counter below] > > > > > > > So, for audio/t140, we can select between three methods for > > > > indicating the start of stream: a. counter =3D0 b. M-bit > > c. Unicode > > > > start of stream character > > > > > > > > > > See comments on counter below. > > > > > > > For text/t140, we can only select between two methods: > > > > a. M-bit > > > > b. Unicode start of stream character > > > > > > > > A missing M-bit does not give full information if a real text > > > > element is missing. The text might be received in > > redundant code. > > > > But it can be used as a likely indication. > > > > > > > > The other methods are at least as reliable as the redundant > > > > transmission method used. > > > > > > > > > > > > For text during a session, we have the following problem: > > What is a > > > > gap? When shall the M-bit be set to 1? What is a text-spurt? > > > > > > > > > > Borrowing from section 5.4 of draft(04), gap would be "no new T.140 > > > data to transmit after the transmit buffering interval described in > > > section 5.1 has > > > passed". This defines the text-spurt which is analogous to > > talkspurt. > > > > > > The M-bit behavior is from (RFC3551): "For applications which send > > > either no packets or occasional comfort-noise packets > > during silence, > > > the first packet > > > of a talkspurt, that is, the first packet after a silence > > period during > > > which packets have not been transmitted contiguously, SHOULD be > > > distinguished by setting the marker bit in the RTP data > > header to one." > > > > > > > For text/t140, it is hard to find a good delimitation for when a > > > > text-spurt starts. There is no declaration of the time > > between the > > > > packets, just the buffering time that normally may be 300 ms, but > > > > may vary. For the text/red/t140 case, there could be a > > reason to use > > > > the M-bit, when only the primary data contains valid > > text. The other > > > > blocks should be empty or non-existing. That is the case after a > > > > pause. Detection of an M-bit can make sure that the risk > > is kept low > > > > for falsely marking loss of data during the pause. Without > > > > the use of the M-bit, falsely marking lost text will occur > > > > slightly more often. > > > > > > > > > > The text-spurt starts with the packet that you transmit after a > > > zero-length block is transmitted, that happens whenever the T.140 > > > buffering interval expires and no new data > > > is available for transmission. > > > > > > > > > > For the plain text/t140 format, I do not see any need for marking > > > > the first packet after a longer pause. > > > > > > > > > > It helps in situations when one can not include a > > zero-length block as > > > redundant data because it's too old. > > > > > > > For red/audio/t140 I see no need for the M-bit. The > > counter give a > > > > better reliability. > > > > > > > > > > During a interval where text is transmitted contiguously, the > > > block-counter and the RTP sequence numbers are in sync. So > > I guess the > > > counter is only useful at the boundaries when > > > switchover between voice/text payload is occurring. Under > > certain loss > > > scenarios or when both marker and zero-length blocks are lost > > > one could have > > > misleading text loss-indicator which in any case are > > > unavoidable. In either > > > case you would detect loss as required. > > > > > > As I mentioned earlier, I am unconvinced about the > > usefulness of the > > > block counter. During contiguous text transmission the > > counter and RTP > > > sequence numbers are in sync. Even if marker is lost, one > > could sync > > > to the first sequence number that can be deriver or is > > present in the > > > header. IMO, different redundancy rules for text/t140 and > > audio/t140 > > > can be unified and > > > implementation simplified. > > > > > > > The current RFC2793 does not specify the use of the M-bit. > > > > RFC2793bis should be compatible with RFC2793 for text/t140 and > > > > text/red/t140. Using the M-bit for RFC2793 bis would be a > > step off > > > > from that direction. > > > > > > > > Anyway, it does little harm, so if there are voices for > > it, we could > > > > say that the transmitter MUST use the M-bit to indicate start of > > > > stream, and start after a pause. The receiver MAY use it for > > > > detection of loss. > > > > > > > > > > > > Please advice > > > > > > > > Regards > > > > > > > > Gunnar > > > > -------------------------------------------------------------- > > > > ------------- > > > > ------- > > > > > > > > > > > > Satish, > > > > Further answers inline, > > > > > > > > Gunnar > > > > > > > > ------------------------------------------- > > > > Gunnar Hellstr=F6m > > > > Omnitor AB > > > > Renathv=E4gen 2 > > > > SE 121 37 Johanneshov > > > > SWEDEN > > > > +46 8 556 002 03 > > > > Mob: +46 708 204 288 > > > > www.omnitor.se > > > > Gunnar.Hellstrom@Omnitor.se > > > > -------------------------------------------- > > > > > > > > > > > > > -----Original Message----- > > > > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > > > > Sent: Thursday, May 06, 2004 11:10 PM > > > > > To: Mundra, Satish; 'Gunnar Hellstrom'; avt IETF > > > > > Subject: Re: [avt] Comments/questions on > > > > > draft-ietf-avt-rfc2793bis-03/04 > > > > > > > > > > > > > > > > X--------snip > > > > > > _______________________________________________ > > > Audio/Video Transport Working Group > > > avt@ietf.org > > > https://www1.ietf.org/mailman/listinfo/avt > > > > > > > > > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu May 13 04:42:31 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28313 for ; Thu, 13 May 2004 04:42:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOBi1-0005He-RJ for avt-archive@odin.ietf.org; Thu, 13 May 2004 04:36:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4D8arO0020311 for avt-archive@odin.ietf.org; Thu, 13 May 2004 04:36:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOBXV-0003Mp-MF; Thu, 13 May 2004 04:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO15Q-0004oZ-6S for avt@optimus.ietf.org; Wed, 12 May 2004 17:16:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12390 for ; Wed, 12 May 2004 17:16:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO15N-0002sX-UO for avt@ietf.org; Wed, 12 May 2004 17:16:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO14R-0002Ih-00 for avt@ietf.org; Wed, 12 May 2004 17:15:20 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BO13S-0001g4-00 for avt@ietf.org; Wed, 12 May 2004 17:14:18 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 12 May 2004 13:19:56 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4CLDkSu005934; Wed, 12 May 2004 14:13:47 -0700 (PDT) Received: from [128.107.165.143] (dhcp-128-107-165-143.cisco.com [128.107.165.143]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ATC92293; Wed, 12 May 2004 14:12:59 -0700 (PDT) In-Reply-To: <20040512090351.25785.qmail@web61310.mail.yahoo.com> References: <20040512090351.25785.qmail@web61310.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/alternative; boundary=Apple-Mail-2-862527985 Message-Id: <4194DBCE-A459-11D8-AA34-0003935495EC@cisco.com> Cc: AVT , SRTP From: "David A. McGrew" Subject: Re: [Srtp-users] [AVT] RFC 3711 - questions about cryptographic context Date: Wed, 12 May 2004 14:13:46 -0700 To: tal shahar X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --Apple-Mail-2-862527985 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Tal, On May 12, 2004, at 2:03 AM, tal shahar wrote: > hi David and thanks again > I didnt define my question properly, the question is whether a key=20 > exchange will give me a list of / MKI and their master key=20= > along. or will I get one at a time. > if I understand correct, the key exchange protocol can decide on=20 > giving me all (or some) of the keys in advance - this will require me=20= > (the SRTP implementation) to do something like switching master=20 > keys=A0for the appropriate index - is it right ? Yes, that's right. > =A0 > about the second question > we were pondring this issue for quite a while > as far as I can understand the RFC does lean torward having the SRTP=20= > triggering this process > I'd like to quote a few things from the RFC, please tell me what you=20= > think > 1. 8.1. SRTP senders SHALL count the amount of SRTP and SRTCP traffic=20= > being=A0used for a master key and invoke key management to re-key if=20= > needed. > 2. (9.2) That=A0is, when 2^48 SRTP packets or 2^31 SRTCP packets have=20= > been secured > =A0=A0 with the same key (whichever occurs before), the key management=20= > MUST=A0be called to provide new master key(s) > 3. (11.2) If there are more than one SRTP/SRTCP stream (within the=20 > same RTP=A0session) that share the master key, the upper limit of 2^48=20= > SRTP=A0packets / 2^31 SRTCP packets means that, before one of the=20 > streams=A0reaches its maximum number of packets, re-keying MUST be=20 > triggered on=A0ALL streams sharing the master key.=A0 > Agreed. SRTP, like RTP, relies on external signaling to set up its=20 sessions, and for SRTP, this means that keys and other parameters are=20 provided by some external mechanism. But in SRTP there is also the=20 strong requirement to not overuse a key, and the authors tried to=20 highlight that need. Daivd > =A0 > thanks a lot > Tal > "David A. McGrew" wrote: > Tal, > > On May 10, 2004, at 12:22 AM, tal shahar wrote: > > > sorry, I missed the attachment > > > > Note: forwarded message attached. > > > > Do you Yahoo!? > > Win a $20,000 Career Makeover at Yahoo! HotJobs > > From: tal shahar > > Date: May 9, 2004 7:26:00 AM PDT > > To: "David A. McGrew" > > Subject: Re: [Srtp-users] [AVT] RFC 3711 - questions about > > cryptographic context > > > > > > David hi and thanks a lot > > as far as I understand, the key exchange protocol provides you with > > the value. > > so ,does the key exchange give you a bunch of values and > > their corresponding keys. > > another question, does this apply also to the MKI implementation,=20 > i.e. > > the key exchange provides you with a list of MKIs and their > > corresponding keys. > > Yes, if you're using an MKI, then the key management protocol will = need > to supply that value along with the key. Similarly, if a > packet index pair is associated with a key, then the pair would need = to > be communicated with the key. > > This is described in Section 8.2. of RFC 3711, "Key Management > Parameters". > > > =A0 > > it is also not totally clear to me whether the sender triggers the > > re-keying or should it be triggered in the key exchange protocol,=20= > and > > the sender should just enforce it > > Good question, and it is clearly and important system design point. > SRTP doesn't dictate how this is done. Clearly a key management = system > can provide new keys to an SRTP implementation, e.g. "here's a new = key > and the MKI to go with it". Also, an SRTP layer could trigger key > management into getting new keys for it, though that is out of the > scope of the RFC. > > In libSRTP, there is an event/callback system by which SRTP can > indicate to another system that some interesting event happened (see > Section 4.3 of the "libSRTP 1.3 Overview and Reference Manual"). Two > of these events are: > > event_key_soft_limit An SRTP stream reached the soft key usage limit > and will expire soon. > event_key_hard_limit An SRTP stream reached the hard key usage limit > and has expired. > > So the callback can recognize a key-expiration event and could call a > key management function. Of course, the key management system would > need to get the new key to all of the participants in the SRTP=20 > session. > > David > > > > > "David A. McGrew" wrote: > > Tal, > > > > On May 9, 2004, at 2:03 AM, tal shahar wrote: > > > > > hi > > > in 3.2.1.=A0 Transform-independent parameters > > > 1. the RFC states that the cryptographic context should hold the=20= > the > > > master key(s) > > > assuming I wish to have SRTP and SRTCP sharing the same master = key, > > > what is the situation where I have more than one key > > > > if I understand right, you are wondering why the "(s)" appears in = the > > quote from the RFC. This is because there might be multiple master > > keys, each of which is used for a particular range of the packet=20 > index > > (that is, the 48-bit integer that is the concatenation of the ROC = and > > the sequence number). libSRTP does not support this facility, and I > > expect that the vast majority of users won't miss it. > > > > > > > 2. if I have only one master key, why do I need to hold the MKI > > > > You don't, though you might need to store the fact that you are not > > using an MKI. libSRTP does not support MKIs as of yet. I don't think > > that it would be hard to add this feature. > > > > David > > > > > =A0 > > > thanks a lot > > > tal > > > > > > Do you Yahoo!? > > > Win a $20,000 Career Makeover at Yahoo! HotJobs > > > > Do you Yahoo!? > > Win a $20,000 Career Makeover at Yahoo! HotJobs > > Do you Yahoo!? > > Yahoo! Movies - Buy advance tickets for 'Shrek 2'=20= --Apple-Mail-2-862527985 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Tal, On May 12, 2004, at 2:03 AM, tal shahar wrote: hi David and thanks again I didnt define my question properly, the question is whether a key exchange will give me a list of < / MKI and their master key along. or will I get one at a time. if I understand correct, the key exchange protocol can decide on giving me all (or some) of the keys in advance - this will require me (the SRTP implementation) to do something like switching master keys=A0for the appropriate index - is it right ? Yes, that's right. =A0 about the second question we were pondring this issue for quite a while as far as I can understand the RFC does lean torward having the SRTP triggering this process I'd like to quote a few things from the RFC, please tell me what you think 1. 8.1. SRTP senders SHALL count the amount of SRTP and SRTCP traffic being=A0used for a master key and invoke key management to re-key if needed. 2. (9.2) That=A0is, when 2^48 SRTP packets or 2^31 SRTCP packets have been secured =A0=A0 with the same key (whichever occurs before), the key management MUST=A0be called to provide new master key(s) 3. (11.2) If there are more than one SRTP/SRTCP stream (within the same RTP=A0session) that share the master key, the upper limit of 2^48 SRTP=A0packets / 2^31 SRTCP packets means that, before one of the streams=A0reaches its maximum number of packets, re-keying MUST be triggered on=A0ALL streams sharing the master key.=A0 Agreed. SRTP, like RTP, relies on external signaling to set up its sessions, and for SRTP, this means that keys and other parameters are provided by some external mechanism. But in SRTP there is also the strong requirement to not overuse a key, and the authors tried to highlight that need. Daivd =A0 thanks a lot Tal "David A. McGrew" < wrote: Tal, On May 10, 2004, at 12:22 AM, tal shahar wrote: > sorry, I missed the attachment > > Note: forwarded message attached. > > Do you Yahoo!? > Win a $20,000 Career Makeover at Yahoo! HotJobs > From: tal shahar > Date: May 9, 2004 7:26:00 AM PDT > To: "David A. McGrew" > Subject: Re: [Srtp-users] [AVT] RFC 3711 - questions about > cryptographic context > > > David hi and thanks a lot > as far as I understand, the key exchange protocol provides you with > the value. > so ,does the key exchange give you a bunch of values and > their corresponding keys. > another question, does this apply also to the MKI implementation, i.e. > the key exchange provides you with a list of MKIs and their > corresponding keys. Yes, if you're using an MKI, then the key management protocol will need to supply that value along with the key. Similarly, if a=20 packet index pair is associated with a key, then the pair would need to=20 be communicated with the key. This is described in Section 8.2. of RFC 3711, "Key Management Parameters". > =A0 > it is also not totally clear to me whether the sender triggers the > re-keying or should it be triggered in the key exchange protocol, and > the sender should just enforce it Good question, and it is clearly and important system design point. SRTP doesn't dictate how this is done. Clearly a key management system can provide new keys to an SRTP implementation, e.g. "here's a new key and the MKI to go with it". Also, an SRTP layer could trigger key management into getting new keys for it, though that is out of the scope of the RFC. In libSRTP, there is an event/callback system by which SRTP can indicate to another system that some interesting event happened (see Section 4.3 of the "libSRTP 1.3 Overview and Reference Manual"). Two of these events are: event_key_soft_limit An SRTP stream reached the soft key usage limit and will expire soon. event_key_hard_limit An SRTP stream reached the hard key usage limit and has expired. So the callback can recognize a key-expiration event and could call a=20 key management function. Of course, the key management system would need to get the new key to all of the participants in the SRTP session. David > > "David A. McGrew" wrote: > Tal, > > On May 9, 2004, at 2:03 AM, tal shahar wrote: > > > hi > > in 3.2.1.=A0 Transform-independent parameters > > 1. the RFC states that the cryptographic context should hold the the > > master key(s) > > assuming I wish to have SRTP and SRTCP sharing the same master key, > > what is the situation where I have more than one key > > if I understand right, you are wondering why the "(s)" appears in the > quote from the RFC. This is because there might be multiple master > keys, each of which is used for a particular range of the packet index > (that is, the 48-bit integer that is the concatenation of the ROC and > the sequence number). libSRTP does not support this facility, and I > expect that the vast majority of users won't miss it. > > > > 2. if I have only one master key, why do I need to hold the MKI > > You don't, though you might need to store the fact that you are not > using an MKI. libSRTP does not support MKIs as of yet. I don't think > that it would be hard to add this feature. > > David > > > =A0 > > thanks a lot > > tal > > > > Do you Yahoo!? > > Win a $20,000 Career Makeover at Yahoo! HotJobs > > Do you Yahoo!? > Win a $20,000 Career Makeover at Yahoo! HotJobs Arial

Do you = Yahoo!?

Arial

Yahoo! Movies -

0000,0000,EEEDBuy advance tickets for 'Shrek 2' = = --Apple-Mail-2-862527985-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu May 13 10:38:03 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16324 for ; Thu, 13 May 2004 10:38:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOHHc-0004do-Sa for avt-archive@odin.ietf.org; Thu, 13 May 2004 10:34:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DEY0Fr017835 for avt-archive@odin.ietf.org; Thu, 13 May 2004 10:34:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOHAs-0002nl-P9; Thu, 13 May 2004 10:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOH6P-0001fr-JV for avt@optimus.ietf.org; Thu, 13 May 2004 10:22:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15266 for ; Thu, 13 May 2004 10:22:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOH6N-0007W2-9I for avt@ietf.org; Thu, 13 May 2004 10:22:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOH5N-0006vc-00 for avt@ietf.org; Thu, 13 May 2004 10:21:22 -0400 Received: from [80.74.106.125] (helo=rvil-mail.RADVISION.com) by ietf-mx with esmtp (Exim 4.12) id 1BOH4Y-0006Ke-00 for avt@ietf.org; Thu, 13 May 2004 10:20:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C438F5.B001B88D" Date: Thu, 13 May 2004 17:22:14 +0300 Message-ID: Thread-Topic: RFC3711, MKI length question Thread-Index: AcQ49a/hxl8JXVAjRpiimWT7DNNlYQ== From: "Ofer Goren" To: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 Subject: [AVT] RFC3711, MKI length question Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C438F5.B001B88D Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi all. =20 According to the RFC, Section 3.3, bullet 3, one should use the MKI (if = exist in the packet) to retrieve the master key in the crypto context. My question is this, and it is implementation related: if I need to use = the MKI, I need to know its length before. Can I assume the user (user = application) sets and stores the value on a per-session base? This means = that all MKIs associated with that session has the same length. The same goes to n_tag parameter. =20 Thanks,=20 =20 Ofer Goren =20 ------_=_NextPart_001_01C438F5.B001B88D Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Hi=20 all.

According to the=20 RFC, Section 3.3, bullet 3, one should use the MKI (if exist in the = packet) to=20 retrieve the master key in the crypto context.

My = question is this,=20 and it is implementation related: if I need to use the MKI, I need to = know its=20 length before. Can I assume the user (user application) sets and = stores the=20 value on a per-session base? This means that all MKIs = associated with=20 that session has the same length.

The same goes=20 to n_tag parameter.

Thanks,

Ofer Goren

------_=_NextPart_001_01C438F5.B001B88D-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu May 13 11:11:08 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17975 for ; Thu, 13 May 2004 11:11:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOHlG-0003Ty-8U for avt-archive@odin.ietf.org; Thu, 13 May 2004 11:04:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DF4cLg013338 for avt-archive@odin.ietf.org; Thu, 13 May 2004 11:04:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOHfq-0002XX-QA; Thu, 13 May 2004 10:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOHXQ-0000X7-59 for avt@optimus.ietf.org; Thu, 13 May 2004 10:50:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17092 for ; Thu, 13 May 2004 10:50:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOHXN-0007fK-LT for avt@ietf.org; Thu, 13 May 2004 10:50:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOHWL-00072f-00 for avt@ietf.org; Thu, 13 May 2004 10:49:14 -0400 Received: from m5tmail.m5t.com ([66.129.134.18]) by ietf-mx with esmtp (Exim 4.12) id 1BOHVF-0005wH-00 for avt@ietf.org; Thu, 13 May 2004 10:48:05 -0400 Content-Class: urn:content-classes:message Subject: RE: [AVT] RFC3711, MKI length question MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Thu, 13 May 2004 10:47:48 -0400 Message-ID: Thread-Topic: RFC3711, MKI length question Thread-Index: AcQ49a/hxl8JXVAjRpiimWT7DNNlYQAAmqkw From: "Sylvain Latulippe" To: "Ofer Goren" , , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, I also assume that MKI length and n_tag are initialized at session = configuration and won't change. I don't see any cases where it would be = necessary to modify these values during a session. Sylvain -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Ofer = Goren Sent: 13 mai, 2004 10:22 To: avt@ietf.org; srtp-users@lists.sourceforge.net Subject: [AVT] RFC3711, MKI length question Hi all. According to the RFC, Section 3.3, bullet 3, one should use the MKI (if = exist in the packet) to retrieve the master key in the crypto context. My question is this, and it is implementation related: if I need to use = the MKI, I need to know its length before. Can I assume the user (user = application) sets and stores the value on a per-session base? This means = that all MKIs associated with that session has the same length. The same goes to n_tag parameter. Thanks,=20 Ofer Goren _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu May 13 11:15:06 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18072 for ; Thu, 13 May 2004 11:15:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOHoo-0004Oc-2m for avt-archive@odin.ietf.org; Thu, 13 May 2004 11:08:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DF8Igb016890 for avt-archive@odin.ietf.org; Thu, 13 May 2004 11:08:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOHgn-0002jy-JB; Thu, 13 May 2004 11:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOHew-0002Cx-Ju for avt@optimus.ietf.org; Thu, 13 May 2004 10:58:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17406 for ; Thu, 13 May 2004 10:58:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOHet-0004Cd-UF for avt@ietf.org; Thu, 13 May 2004 10:58:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOHdu-0003fJ-00 for avt@ietf.org; Thu, 13 May 2004 10:57:03 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BOHcf-0002cc-00 for avt@ietf.org; Thu, 13 May 2004 10:55:45 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i4DEtiAh014381 for ; Thu, 13 May 2004 16:55:44 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 13 May 2004 16:55:44 +0200 Received: from ericsson.com (permit153.er.ki.sw.ericsson.se [147.214.97.153]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id KWS174A0; Thu, 13 May 2004 16:55:53 +0200 Message-ID: <40A38C6F.1030003@ericsson.com> Date: Thu, 13 May 2004 16:55:43 +0200 X-Sybari-Trust: 4e739d05 3becbf40 0537a248 00000139 From: =?windows-1255?Q?Mats_Na=22slund?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ofer Goren CC: avt@ietf.org, srtp-users@lists.sourceforge.net Subject: Re: [AVT] RFC3711, MKI length question References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 May 2004 14:55:44.0573 (UTC) FILETIME=[5E25C6D0:01C438FA] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi The cryptographic context stores the MKI_length value, and the value is typically provided via key managament/session set-up, defined by user/application preference. (I would assume that 32 bits usually suffices.) You are correct in that the length MUST be fixed for the session (this is explicitly stated in the RFC). cheers /Mats Ofer Goren wrote: >Hi all. > >According to the RFC, Section 3.3, bullet 3, one should use the MKI (if exist in the packet) to retrieve the master key in the crypto context. >My question is this, and it is implementation related: if I need to use the MKI, I need to know its length before. Can I assume the user (user application) sets and stores the value on a per-session base? This means that all MKIs associated with that session has the same length. >The same goes to n_tag parameter. > >Thanks, > >Ofer Goren > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu May 13 13:58:03 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29177 for ; Thu, 13 May 2004 13:58:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOJy9-0005Sv-9U for avt-archive@odin.ietf.org; Thu, 13 May 2004 13:26:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DHQ586020985 for avt-archive@odin.ietf.org; Thu, 13 May 2004 13:26:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOJau-0004wg-0W; Thu, 13 May 2004 13:02:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOJVA-0003zl-UT for avt@optimus.ietf.org; Thu, 13 May 2004 12:56:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23213 for ; Thu, 13 May 2004 12:56:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOJV9-0004Re-6U for avt@ietf.org; Thu, 13 May 2004 12:56:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOJU7-0003tM-00 for avt@ietf.org; Thu, 13 May 2004 12:55:04 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BOJSw-0002li-00 for avt@ietf.org; Thu, 13 May 2004 12:53:50 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 13 May 2004 09:52:24 -0700 Received: from mbaugher-w2k07.cisco.com (sjc-vpn1-501.cisco.com [10.21.97.245]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i4DGr9jP019803; Thu, 13 May 2004 09:53:09 -0700 (PDT) Message-Id: <6.0.0.22.2.20040513095248.0453bdc0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 13 May 2004 09:53:34 -0700 To: "Sylvain Latulippe" From: Mark Baugher Subject: RE: [AVT] RFC3711, MKI length question Cc: , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , At 07:47 AM 5/13/2004, Sylvain Latulippe wrote: >Hi, > >I also assume that MKI length and n_tag are initialized at session >configuration and won't change. Yes. >I don't see any cases where it would be necessary to modify these values >during a session. I don't either. Mark >Sylvain > >-----Original Message----- >From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Ofer Goren >Sent: 13 mai, 2004 10:22 >To: avt@ietf.org; srtp-users@lists.sourceforge.net >Subject: [AVT] RFC3711, MKI length question > > >Hi all. > >According to the RFC, Section 3.3, bullet 3, one should use the MKI (if >exist in the packet) to retrieve the master key in the crypto context. >My question is this, and it is implementation related: if I need to use >the MKI, I need to know its length before. Can I assume the user (user >application) sets and stores the value on a per-session base? This means >that all MKIs associated with that session has the same length. >The same goes to n_tag parameter. > >Thanks, > >Ofer Goren > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu May 13 15:17:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07269 for ; Thu, 13 May 2004 15:17:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOLZT-0002Tz-PU for avt-archive@odin.ietf.org; Thu, 13 May 2004 15:08:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DJ8hp6009504 for avt-archive@odin.ietf.org; Thu, 13 May 2004 15:08:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOLTy-00060Z-Mg; Thu, 13 May 2004 15:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOLFo-0006rq-Gc for avt@optimus.ietf.org; Thu, 13 May 2004 14:48:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05039 for ; Thu, 13 May 2004 14:48:21 -0400 (EDT) From: silvia.pfeiffer@csiro.au Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOLFl-0001bP-O6 for avt@ietf.org; Thu, 13 May 2004 14:48:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOLEk-00013l-00 for avt@ietf.org; Thu, 13 May 2004 14:47:18 -0400 Received: from mix-avignon-206-1-5.w193-249.abo.wanadoo.fr ([193.249.252.5] helo=ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1BOLDs-0000X0-00 for avt@ietf.org; Thu, 13 May 2004 14:46:25 -0400 To: avt@ietf.org Date: Thu, 13 May 2004 20:46:29 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.8 required=5.0 tests=MICROSOFT_EXECUTABLE, MIME_BOUND_NEXTPART,MISSING_MIMEOLE,MSGID_FROM_MTA_SHORT,NO_REAL_NAME, PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.1 MICROSOFT_EXECUTABLE RAW: Message includes Microsoft executable program * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 0.2 MIME_BOUND_NEXTPART Spam tool pattern in MIME boundary * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer Subject: [AVT] Re: Extended Mail Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Follow the instructions to read the message. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: details.doc .pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. ------=_NextPart_000_0016----=_NextPart_000_0016-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri May 14 05:25:06 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09162 for ; Fri, 14 May 2004 05:25:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOYuA-0001ke-Go for avt-archive@odin.ietf.org; Fri, 14 May 2004 05:22:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E9MwI9006682 for avt-archive@odin.ietf.org; Fri, 14 May 2004 05:22:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOYnY-0000RL-Ic; Fri, 14 May 2004 05:16:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOYQU-0003gS-UV for avt@optimus.ietf.org; Fri, 14 May 2004 04:52:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07900 for ; Fri, 14 May 2004 04:52:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOYQR-0005bW-RP for avt@ietf.org; Fri, 14 May 2004 04:52:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOYPB-00055h-00 for avt@ietf.org; Fri, 14 May 2004 04:50:58 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1BOYOW-0004ZL-00 for avt@ietf.org; Fri, 14 May 2004 04:50:16 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61308 helo=[192.168.0.3]) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:RC4-MD5:128) (Exim 4.04) id 1BOYO3-0005Xb-00 for avt@ietf.org; Fri, 14 May 2004 09:49:47 +0100 From: Colin Perkins Organization: http://csperkins.org To: avt@ietf.org Subject: Re: [AVT] WG last call: text/red and RFC2793bis Date: Fri, 14 May 2004 09:49:48 +0100 User-Agent: KMail/1.6.2 References: <6933F046-9AD7-11D8-8F53-000A957FC5F2@csperkins.org> In-Reply-To: <6933F046-9AD7-11D8-8F53-000A957FC5F2@csperkins.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200405140949.48748.csp@csperkins.org> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Friday 30 April 2004 19:51, Colin Perkins wrote: > This is to announce a working group last call on the "text/red" MIME > type registration , and the RTP Payload > Format for Text Conversation . Both > drafts are under consideration for proposed standard status. > > Please send any final comments on these drafts to the mailing list > before Friday 14th May 2004. Note that we will not advance either draft > until we receive a valid review of the work by someone other than the > authors. The working group last call for these drafts ends today. There has been considerable discussion of the 2793bis draft on the mailing list, thanks to the review by Satish Mundra, and it appears that there are open issues to resolve. Accordingly, we will not advance the 2793bis draft until a revision is available that addresses these concerns. The text/red draft has not yet received a public last call review, even through there are 1077 people on the list who received the request for input. Accordingly, it will continue in working group last call until such a review is received. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri May 14 09:01:40 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19460 for ; Fri, 14 May 2004 09:01:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOcFL-0005IV-K2 for avt-archive@odin.ietf.org; Fri, 14 May 2004 08:57:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ECv3uJ020363 for avt-archive@odin.ietf.org; Fri, 14 May 2004 08:57:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOc8b-0003vp-FQ; Fri, 14 May 2004 08:50:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOc6b-0003TC-1g for avt@optimus.ietf.org; Fri, 14 May 2004 08:48:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18697 for ; Fri, 14 May 2004 08:47:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOc6Z-0000ZB-Gx for avt@ietf.org; Fri, 14 May 2004 08:47:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOc5X-00003R-00 for avt@ietf.org; Fri, 14 May 2004 08:46:56 -0400 Received: from smtp.eweka.nl ([81.171.101.3]) by ietf-mx with esmtp (Exim 4.12) id 1BOc4S-00077Q-00 for avt@ietf.org; Fri, 14 May 2004 08:45:48 -0400 Received: from solstice (ew-dsl-81-171-8-127.eweka.nl [81.171.8.127]) by smtp.eweka.nl (8.12.9/8.12.9) with ESMTP id i4EDG2WB032453; Fri, 14 May 2004 13:16:16 GMT (envelope-from a.vwijk@viataal.nl) Message-Id: <200405141316.i4EDG2WB032453@smtp.eweka.nl> From: "Arnoud van Wijk" To: "'Mundra, Satish'" , "'Gunnar Hellstrom'" , "'Paul E. Jones'" , "'avt IETF'" Subject: RE: [avt] Comments/questions on draft-ietf-avt-rfc2793bis-04 Date: Fri, 14 May 2004 14:45:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <09DD40ABD88ACF4CB0D3CD84BB95296001B46B@tnint11.telogy.design.ti.com> Thread-Index: AcQ4WB0eKRK7ZUpjQwC29lEgrdaHwABVtQ8Q X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I am trying to follow what the big deal is about the M-bit. In my opinion the draft rfc2793bis-04 is finished and ready to work. What am I then missing? Greetz Arnoud Drs. Arnoud A. T. van Wijk Viataal Research & Development Afdeling RDS Theerestraat 42 5271 GD Sint-Michielsgestel The Netherlands.=20 Mobile: +31651921948 International text telephone: +31735588408 -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On Behalf Of = Mundra, Satish Sent: woensdag 12 mei 2004 21:11 To: 'Gunnar Hellstrom'; Paul E. Jones; avt IETF Subject: RE: [avt] Comments/questions on draft-ietf-avt-rfc2793bis-04 Gunnar, responses inline... > -----Original Message----- > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > Sent: Tuesday, May 11, 2004 6:32 PM > To: Mundra, Satish; Paul E. Jones; avt IETF > Subject: RE: [avt] Comments/questions on draft-ietf-avt-rfc2793bis-04 >=20 >=20 > Satish, > I get the impression that your main goal with the discussion > is to try to find a format for audio/red/t140 that could=20 > allow us to drop the t140block counter from the format. >=20 > Is the reason saving bits? >=20 Yes, saving six bytes per audio/red/t140 packet could buy one more level = of redundancy=20 if needed. If you feel that it's required for reliable operations, and change at = this stage is not desirable, that's fine with me.=20 > We have had it there since August, with no major concerns, so > it seems acceptable to most reviewers. >=20 > You also want to use the M-bit as in RFC3551. > > The M-bit behavior is from (RFC3551): "For applications which send > > either no packets or occasional comfort-noise packets=20 > during silence, > > the first packet > > of a talkspurt, that is, the first packet after a silence > period during > > which packets have not been transmitted contiguously, SHOULD be=20 > > distinguished by setting the marker bit in the RTP data > header to one." > That can be OK. But then you must not do anything drastic, > such as adding a missing text marker just because the packet=20 > with the M-bit seems to be missing. With 10% packet loss, 10%=20 > of the M-bits will be missing, but only 0.1% of text, if we=20 > are using primary and two redundant transmissions. >=20 One need not solely depend on the missing primary with marker to = conclude loss of=20 t140 data for audio/red/t140.=20 Assuming that 10% of M-bits are lost:=20 If the total number of consecutive packets lost is less than the = redundancy level in use, one can easily determine if the missing sequence numbers = were carrying text or voice.=20 At other times I agree that it may not be obvious. It seems like one = could use both the timestamp gap and sequence number gap to determine if any text was = lost. Note that=20 when text is transmitted the sequence numbers increments by 1 every 300/500ms where =20 as for voice it would be every 20/30ms or so.=20 > Would it be OK to you to take in the text about the M-bit=20 > from RFC3551? >=20 Yes. Thanks, --Satish > Gunnar >=20 >=20 > ------------------------------------------- > Gunnar Hellstr=F6m > Omnitor AB > Renathv=E4gen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- >=20 >=20 > > -----Original Message----- > > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of=20 > > Mundra, Satish > > Sent: Tuesday, May 11, 2004 7:19 PM > > To: 'Gunnar Hellstrom'; Paul E. Jones; avt IETF > > Subject: RE: [avt] Comments/questions on=20 > draft-ietf-avt-rfc2793bis-04 > > > > > > Gunnar/Paul, > > > > Thanks for summarizing the questions. The previous comments got=20 > > cross-posted, I have used your latest posting for further debate on=20 > > the questions/comments. See comments inline... > > > > Regards, > > > > Satish Mundra > > > > > -----Original Message----- > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > > Sent: Monday, May 10, 2004 6:29 PM > > > To: Paul E. Jones; Mundra, Satish; avt IETF > > > Subject: RE: [avt] Comments/questions on=20 > > > draft-ietf-avt-rfc2793bis-04 > > > > > > > > > Satish, > > > I am eager to come to conclusions on your questions regarding=20 > > > draft-ietf-avt-rfc2793bis-04. > > > > > > Our (Paul=B4s and mine ) understanding regarding the questions are = > > > now: > > > > > > 1. Security risk to have the 16-bit T140block counter to always=20 > > > start at 0 in a session. I mentioned that loss in the beginning=20 > > > could be detected by the text stream not starting with=20 > the Unicode=20 > > > synchronization character, because the requirement to start with=20 > > > that code is clearly stated in T.140. So, that could be=20 > used and the=20 > > > counter could then start at a random value. However, also this=20 > > > session start code can be seen as a security risk with the same=20 > > > reason as the 0 counter would be one. Are not all media full of > > > predictable bit patterns, like picture start headers, audio > > > session parameters etc? > > > > > > We would like to hear more voices if it is important to start the=20 > > > counter at a random value, and instead rely on detection=20 > of initial=20 > > > loss by a missing Unicode Synchronization character. > > > > > > > See comments on the "t140block counter" below. > > > > > 2. M-bit for indication of start of text. > > > You hint that we should specify that the M-bit SHALL be used as=20 > > > indicated in the AVT profile for indicating start of text=20 > initially=20 > > > in the stream and also after a gap. This could be used both to=20 > > > detect loss and in order to detect when suspected loss is=20 > only loss=20 > > > of empty text blocks. > > > > > > > Yes. > > > > > Each M-bit is only sent once, so it does not get improved=20 > > > reliability by redundancy. We have a mechanism with=20 > marking missing=20 > > > text with a Unicode replacement character, specified in=20 > T.140. If in=20 > > > doubt, it is better to mark too much than too little,=20 > because there=20 > > > will be non-printable characters that will be marked by this=20 > > > character when lost. Therefore the users might know that=20 > there can=20 > > > be markers for missing text without any visible text missing. > > > > > > > Let me understand this again, the requirement for the=20 > payload format=20 > > is to NOT fail in detecting LOSS when occurs, misleading loss=20 > > indicators are unavoidable and seem to be acceptable. [see further=20 > > comments on the block counter below] > > > > > So, for audio/t140, we can select between three methods for=20 > > > indicating the start of stream: a. counter =3D0 b. M-bit =20 > c. Unicode=20 > > > start of stream character > > > > > > > See comments on counter below. > > > > > For text/t140, we can only select between two methods: > > > a. M-bit > > > b. Unicode start of stream character > > > > > > A missing M-bit does not give full information if a real text=20 > > > element is missing. The text might be received in=20 > redundant code. =20 > > > But it can be used as a likely indication. > > > > > > The other methods are at least as reliable as the redundant=20 > > > transmission method used. > > > > > > > > > For text during a session, we have the following problem:=20 > What is a=20 > > > gap? When shall the M-bit be set to 1? What is a text-spurt? > > > > > > > Borrowing from section 5.4 of draft(04), gap would be "no new T.140=20 > > data to transmit after the transmit buffering interval described in > > section 5.1 has > > passed". This defines the text-spurt which is analogous to=20 > talkspurt. > > > > The M-bit behavior is from (RFC3551): "For applications which send=20 > > either no packets or occasional comfort-noise packets=20 > during silence,=20 > > the first packet > > of a talkspurt, that is, the first packet after a silence=20 > period during > > which packets have not been transmitted contiguously, SHOULD be > > distinguished by setting the marker bit in the RTP data=20 > header to one." > > > > > For text/t140, it is hard to find a good delimitation for when a=20 > > > text-spurt starts. There is no declaration of the time=20 > between the=20 > > > packets, just the buffering time that normally may be 300 ms, but=20 > > > may vary. For the text/red/t140 case, there could be a=20 > reason to use=20 > > > the M-bit, when only the primary data contains valid=20 > text. The other=20 > > > blocks should be empty or non-existing. That is the case after a=20 > > > pause. Detection of an M-bit can make sure that the risk=20 > is kept low > > > for falsely marking loss of data during the pause. Without > > > the use of the M-bit, falsely marking lost text will occur > > > slightly more often. > > > > > > > The text-spurt starts with the packet that you transmit after a=20 > > zero-length block is transmitted, that happens whenever the T.140=20 > > buffering interval expires and no new data > > is available for transmission. > > > > > > > For the plain text/t140 format, I do not see any need for marking=20 > > > the first packet after a longer pause. > > > > > > > It helps in situations when one can not include a=20 > zero-length block as=20 > > redundant data because it's too old. > > > > > For red/audio/t140 I see no need for the M-bit. The=20 > counter give a=20 > > > better reliability. > > > > > > > During a interval where text is transmitted contiguously, the=20 > > block-counter and the RTP sequence numbers are in sync. So=20 > I guess the=20 > > counter is only useful at the boundaries when > > switchover between voice/text payload is occurring. Under=20 > certain loss > > scenarios or when both marker and zero-length blocks are lost > > one could have > > misleading text loss-indicator which in any case are > > unavoidable. In either > > case you would detect loss as required. > > > > As I mentioned earlier, I am unconvinced about the=20 > usefulness of the=20 > > block counter. During contiguous text transmission the=20 > counter and RTP=20 > > sequence numbers are in sync. Even if marker is lost, one=20 > could sync=20 > > to the first sequence number that can be deriver or is=20 > present in the=20 > > header. IMO, different redundancy rules for text/t140 and=20 > audio/t140=20 > > can be unified and > > implementation simplified. > > > > > The current RFC2793 does not specify the use of the M-bit.=20 > > > RFC2793bis should be compatible with RFC2793 for text/t140 and=20 > > > text/red/t140. Using the M-bit for RFC2793 bis would be a=20 > step off=20 > > > from that direction. > > > > > > Anyway, it does little harm, so if there are voices for=20 > it, we could=20 > > > say that the transmitter MUST use the M-bit to indicate start of=20 > > > stream, and start after a pause. The receiver MAY use it for=20 > > > detection of loss. > > > > > > > > > Please advice > > > > > > Regards > > > > > > Gunnar > > > -------------------------------------------------------------- > > > ------------- > > > ------- > > > > > > > > > Satish, > > > Further answers inline, > > > > > > Gunnar > > > > > > ------------------------------------------- > > > Gunnar Hellstr=F6m > > > Omnitor AB > > > Renathv=E4gen 2 > > > SE 121 37 Johanneshov > > > SWEDEN > > > +46 8 556 002 03 > > > Mob: +46 708 204 288 > > > www.omnitor.se > > > Gunnar.Hellstrom@Omnitor.se > > > -------------------------------------------- > > > > > > > > > > -----Original Message----- > > > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > > > Sent: Thursday, May 06, 2004 11:10 PM > > > > To: Mundra, Satish; 'Gunnar Hellstrom'; avt IETF > > > > Subject: Re: [avt] Comments/questions on=20 > > > > draft-ietf-avt-rfc2793bis-03/04 > > > > > > > > > > > > X--------snip > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www1.ietf.org/mailman/listinfo/avt > > > > >=20 >=20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri May 14 14:23:13 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10560 for ; Fri, 14 May 2004 14:23:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOhHP-0001w1-Uc for avt-archive@odin.ietf.org; Fri, 14 May 2004 14:19:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EIJV7A007425 for avt-archive@odin.ietf.org; Fri, 14 May 2004 14:19:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOhD3-00014k-TW; Fri, 14 May 2004 14:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOh9a-0000bO-V0 for avt@optimus.ietf.org; Fri, 14 May 2004 14:11:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09505 for ; Fri, 14 May 2004 14:11:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOh9Y-000483-Gt for avt@ietf.org; Fri, 14 May 2004 14:11:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOh7Q-0003CB-00 for avt@ietf.org; Fri, 14 May 2004 14:09:12 -0400 Received: from relay2.eecs.berkeley.edu ([169.229.60.28]) by ietf-mx with esmtp (Exim 4.12) id 1BOh6R-0002gi-00 for avt@ietf.org; Fri, 14 May 2004 14:08:11 -0400 Received: from relay3.EECS.Berkeley.EDU (localhost [127.0.0.1]) by relay2.EECS.Berkeley.EDU (8.12.10/8.9.3) with ESMTP id i4EI8A68010329 for ; Fri, 14 May 2004 11:08:10 -0700 (PDT) Received: from gateway.EECS.Berkeley.EDU (nsmail@gateway.EECS.Berkeley.EDU [169.229.60.73]) by relay3.EECS.Berkeley.EDU (8.12.10/8.9.3) with ESMTP id i4EI89tj019342 for ; Fri, 14 May 2004 11:08:09 -0700 (PDT) Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) by gateway.EECS.Berkeley.EDU (Netscape Messaging Server 4.15) with ESMTP id HXPUDJ00.3HF for ; Fri, 14 May 2004 11:08:07 -0700 Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: avt@ietf.org From: "John Lazzaro" Subject: Re: [AVT] WG last call: text/red and RFC2793bis Date: Fri, 14 May 2004 11:08:06 -0700 X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Colin Perkins writes: > > The text/red draft has not yet received a public last call review, even > through there are 1077 people on the list who received the request for > input. Accordingly, it will continue in working group last call until > such a review is received. A suggestion. After the first time a document goes to Last Call, and gets OKed by someone (on text/red that was me), all future requests should include URLs to the I-D diffs on this website: http://ietf.levkowetz.com/drafts/avt/text-red/ and an "OK on the diffs" should be considered an OK on the document. I just checked over the -02/-03 and -03/-04 diffs for tex/red and give my OK on the diffs. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri May 14 18:46:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04331 for ; Fri, 14 May 2004 18:46:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOlM9-0001Bo-1n for avt-archive@odin.ietf.org; Fri, 14 May 2004 18:40:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EMefZg004567 for avt-archive@odin.ietf.org; Fri, 14 May 2004 18:40:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOlEQ-0007gU-23; Fri, 14 May 2004 18:32:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOkz9-0003iJ-98 for avt@optimus.ietf.org; Fri, 14 May 2004 18:16:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02928 for ; Fri, 14 May 2004 18:16:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOkz6-0004Xb-8s for avt@ietf.org; Fri, 14 May 2004 18:16:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOkyB-00041S-00 for avt@ietf.org; Fri, 14 May 2004 18:15:56 -0400 Received: from go4.ext.ti.com ([192.91.75.132]) by ietf-mx with esmtp (Exim 4.12) id 1BOkxE-0003TT-00 for avt@ietf.org; Fri, 14 May 2004 18:14:56 -0400 Received: from dlep91.itg.ti.com ([157.170.152.55]) by go4.ext.ti.com (8.12.11/8.12.11) with ESMTP id i4EMEPtj005060; Fri, 14 May 2004 17:14:25 -0500 (CDT) Received: from tnint11.telogy.design.ti.com (localhost [127.0.0.1]) by dlep91.itg.ti.com (8.12.11/8.12.11) with ESMTP id i4EMEOOE018567; Fri, 14 May 2004 17:14:24 -0500 (CDT) Received: by tnint11.telogy.design.ti.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 May 2004 18:21:08 -0400 Message-ID: <09DD40ABD88ACF4CB0D3CD84BB95296001B475@tnint11.telogy.design.ti.com> From: "Mundra, Satish" To: "'Colin Perkins'" , IETF AVT WG , "'Paul E. Jones'" Subject: RE: [AVT] WG last call: text/red Date: Fri, 14 May 2004 18:21:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/html Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.8 required=5.0 tests=AWL,FORGED_IMS_HTML,HTML_50_60, HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable RE: [AVT] WG last call: text/red

Colin/Paul,

I have reviewed the draft = <draft-ietf-avt-text-red-04.txt>.
It looks good to move further.

Regards,

Satish Mundra

> -----Original Message-----
> From: Colin Perkins [mailto:csp@csperkins.org]
> Sent: Friday, April 30, 2004 2:52 PM
> To: IETF AVT WG
> Subject: [AVT] WG last call: text/red and = RFC2793bis
>
>
> This is to announce a working group last call = on the "text/red" MIME
> type registration = <draft-ietf-avt-text-red-04.txt>, and the
> RTP Payload
> Format for Text Conversation = <draft-ietf-avt-rfc2793bis-04.txt>. Both
> drafts are under consideration for proposed = standard status.
>
> Please send any final comments on these drafts = to the mailing list
> before Friday 14th May 2004. Note that we will = not advance
> either draft
> until we receive a valid review of the work by = someone other than the
> authors.
>
> Colin
>
>
> = _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
>

Arnoud,

Here is brief summary in response to your question on = the Mbit, and you can refer to
comments on draft-03 for other issues.

For audio encodings, M-bit can be used for making = playout delay adjustments at the beginning of talkspurt. Most video = encoding set it on the last packet of a video frame to signal the end = of frame. For text encoding no behavior is specified.

Encoding audio/t140 is one more voice encoding and = hence should follow the
behavior specified in RFC3551. One certainly = can not depend on the M-bit being present
and hence must be robust if the packet is lost, = however, there are implementation that
would improve playout performance/behave differently = when the packet with M-bit is not lost.

2793bis-04 defines zero-length packets for use during = "silence periods" but different rules govern their = re-transmission when redundancy is used depending on whether audio/t140 = or text/t140 is used. At times those MUST requirements can not be = satisfied for e.g., when the "Silence Period" is longer than = 16383/clock-rate.

The last one is not an issue but an observation. = There is two byte sequence number in audio/t140 payload that is in sync = with RTP sequence number during a text-spurt and the reason for = different rules above. The primary use for the counter in the payload = is, as I

understand it, to distinguish between loss of = audio/t140 data and voice data so that text loss can be indicated to = user when 2198 is used. We were discussing if the M-bit = could

allow one to do the same instead of counter. The = authors feel that it is needed to mark the
missing text accurately and this is fine.

Regards,

Satish Mundra

> -----Original Message-----
> From: Arnoud van Wijk [mailto:a.vwijk@viataal.nl]=
> Sent: Friday, May 14, 2004 8:46 AM
> To: 'Mundra, Satish'; 'Gunnar Hellstrom'; 'Paul = E. Jones'; 'avt IETF'
> Subject: RE: [avt] Comments/questions on = draft-ietf-avt-rfc2793bis-04
>
>
> I am trying to follow what the big deal is = about the M-bit. In my
> opinion the draft rfc2793bis-04 is finished and = ready to work.
>
> What am I then missing?
>
> Greetz
>
> Arnoud
>
>
> Drs. Arnoud A. T. van Wijk
> Viataal
> Research & Development
> Afdeling RDS
> Theerestraat 42
> 5271 GD Sint-Michielsgestel
> The Netherlands.
> Mobile: +31651921948
> International text telephone: = +31735588408
>
> -----Original Message-----
> From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] = On
> Behalf Of Mundra, Satish
> Sent: woensdag 12 mei 2004 21:11
> To: 'Gunnar Hellstrom'; Paul E. Jones; avt = IETF
> Subject: RE: [avt] Comments/questions on = draft-ietf-avt-rfc2793bis-04
>
> Gunnar,
>
> responses inline...
>
> > -----Original Message-----
> > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omni= tor.se]
> > Sent: Tuesday, May 11, 2004 6:32 PM
> > To: Mundra, Satish; Paul E. Jones; avt = IETF
> > Subject: RE: [avt] Comments/questions = on
> draft-ietf-avt-rfc2793bis-04
> >
> >
> > Satish,
> > I get the impression that your main goal = with the
> discussion is to try
> > to find a format for audio/red/t140 that = could allow us to drop the
> > t140block counter from the format.
> >
> > Is the reason saving bits?
> >
>
> Yes, saving six bytes per audio/red/t140 packet = could buy one
> more level of redundancy
> if needed.
> If you feel that it's required for reliable = operations, and
> change at this stage is not desirable, that's = fine with me.
>
> > We have had it there since August, with no = major concerns,
> so it seems
> > acceptable to most reviewers.
> >
> > You also want to use the M-bit as in = RFC3551.
> > > The M-bit behavior is from (RFC3551): = "For applications
> which send
> > > either no packets or occasional = comfort-noise packets
> > during silence,
> > > the first packet
> > > of a talkspurt, that is, the first = packet after a silence
> > period during
> > > which packets have not been = transmitted contiguously, SHOULD be
> > > distinguished by setting the marker = bit in the RTP data
> > header to one."
> > That can be OK. But then you must not do = anything drastic, such as
> > adding a missing text marker just because = the packet with the M-bit
> > seems to be missing. With 10% packet loss, = 10% of the
> M-bits will be
> > missing, but only 0.1% of text, if we are = using primary and two
> > redundant transmissions.
> >
>
> One need not solely depend on the missing = primary with marker
> to conclude loss of
> t140 data for audio/red/t140.
>
> Assuming that 10% of M-bits are lost:
> If the total number of consecutive packets lost = is less than
> the redundancy level in use, one can easily = determine if the
> missing sequence numbers were carrying text or = voice.
> At other times I agree that it may not be = obvious. It seems
> like one could use both the timestamp gap and = sequence number
> gap to determine if any text was lost. Note = that
> when text is transmitted the sequence numbers = increments by 1
> every 300/500ms where
> as for voice it would be every 20/30ms or so. =
>
>
>
>
>
> > Would it be OK to you to take in the text = about the M-bit from
> > RFC3551?
> >
>
> Yes.
>
>
> Thanks,
>
> --Satish
>
>
>
>
> > Gunnar
> >
> >
> > = -------------------------------------------
> > Gunnar Hellstr=F6m
> > Omnitor AB
> > Renathv=E4gen 2
> > SE 121 37 Johanneshov
> > SWEDEN
> > +46 8 556 002 03
> > Mob: +46 708 204 288
> > www.omnitor.se
> > Gunnar.Hellstrom@Omnitor.se
> > = --------------------------------------------
> >
> >
> > > -----Original Message-----
> > > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On = Behalf Of
> > > Mundra, Satish
> > > Sent: Tuesday, May 11, 2004 7:19 = PM
> > > To: 'Gunnar Hellstrom'; Paul E. = Jones; avt IETF
> > > Subject: RE: [avt] Comments/questions = on
> > draft-ietf-avt-rfc2793bis-04
> > >
> > >
> > > Gunnar/Paul,
> > >
> > > Thanks for summarizing the questions. = The previous comments got
> > > cross-posted, I have used your latest = posting for further
> debate on
> > > the questions/comments. See comments = inline...
> > >
> > > Regards,
> > >
> > > Satish Mundra
> > >
> > > > -----Original = Message-----
> > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omni= tor.se]
> > > > Sent: Monday, May 10, 2004 6:29 = PM
> > > > To: Paul E. Jones; Mundra, = Satish; avt IETF
> > > > Subject: RE: [avt] = Comments/questions on
> > > > = draft-ietf-avt-rfc2793bis-04
> > > >
> > > >
> > > > Satish,
> > > > I am eager to come to = conclusions on your questions regarding
> > > > = draft-ietf-avt-rfc2793bis-04.
> > > >
> > > > Our (Paul=B4s and mine ) = understanding regarding the
> questions are
> > > > now:
> > > >
> > > > 1. Security risk to have the = 16-bit T140block counter to always
> > > > start at 0 in a session. I = mentioned that loss in the beginning
> > > > could be detected by the text = stream not starting with
> > the Unicode
> > > > synchronization character, = because the requirement to
> start with
> > > > that code is clearly stated in = T.140. So, that could be
> > used and the
> > > > counter could then start at a = random value. However, also this
> > > > session start code can be seen = as a security risk with the same
> > > > reason as the 0 counter would be = one. Are not all media full of
> > > > predictable bit patterns, like = picture start headers, audio
> > > > session parameters etc?
> > > >
> > > > We would like to hear more = voices if it is important to
> start the
> > > > counter at a random value, and = instead rely on detection
> > of initial
> > > > loss by a missing Unicode = Synchronization character.
> > > >
> > >
> > > See comments on the "t140block = counter" below.
> > >
> > > > 2. M-bit for indication of start = of text.
> > > > You hint that we should specify = that the M-bit SHALL be used as
> > > > indicated in the AVT profile for = indicating start of text
> > initially
> > > > in the stream and also after a = gap. This could be used both to
> > > > detect loss and in order to = detect when suspected loss is
> > only loss
> > > > of empty text blocks.
> > > >
> > >
> > > Yes.
> > >
> > > > Each M-bit is only sent once, so = it does not get improved
> > > > reliability by redundancy. We = have a mechanism with
> > marking missing
> > > > text with a Unicode replacement = character, specified in
> > T.140. If in
> > > > doubt, it is better to mark too = much than too little,
> > because there
> > > > will be non-printable characters = that will be marked by this
> > > > character when lost. Therefore = the users might know that
> > there can
> > > > be markers for missing text = without any visible text missing.
> > > >
> > >
> > > Let me understand this again, the = requirement for the
> > payload format
> > > is to NOT fail in detecting LOSS when = occurs, misleading loss
> > > indicators are unavoidable and seem = to be acceptable.
> [see further
> > > comments on the block counter = below]
> > >
> > > > So, for audio/t140, we can = select between three methods for
> > > > indicating the start of = stream: a. counter =3D0 b. M-bit
> > c. Unicode
> > > > start of stream character
> > > >
> > >
> > > See comments on counter below.
> > >
> > > > For text/t140, we can only = select between two methods: a. M-bit
> > > > b. Unicode start of stream = character
> > > >
> > > > A missing M-bit does not give = full information if a real text
> > > > element is missing. The text = might be received in
> > redundant code.
> > > > But it can be used as a likely = indication.
> > > >
> > > > The other methods are at least = as reliable as the redundant
> > > > transmission method used.
> > > >
> > > >
> > > > For text during a session, we = have the following problem:
> > What is a
> > > > gap? When shall the M-bit be set = to 1? What is a text-spurt?
> > > >
> > >
> > > Borrowing from section 5.4 of = draft(04), gap would be "no
> new T.140
> > > data to transmit after the transmit = buffering interval
> described in
> > > section 5.1 has
> > > passed". This defines the = text-spurt which is analogous to
> > talkspurt.
> > >
> > > The M-bit behavior is from (RFC3551): = "For applications
> which send
> > > either no packets or occasional = comfort-noise packets
> > during silence,
> > > the first packet
> > > of a talkspurt, that is, the first = packet after a silence
> > period during
> > > which packets have not been = transmitted contiguously, SHOULD be
> > > distinguished by setting the marker = bit in the RTP data
> > header to one."
> > >
> > > > For text/t140, it is hard to = find a good delimitation
> for when a
> > > > text-spurt starts. There is no = declaration of the time
> > between the
> > > > packets, just the buffering time = that normally may be
> 300 ms, but
> > > > may vary. For the text/red/t140 = case, there could be a
> > reason to use
> > > > the M-bit, when only the primary = data contains valid
> > text. The other
> > > > blocks should be empty or = non-existing. That is the
> case after a
> > > > pause. Detection of an M-bit can = make sure that the risk
> > is kept low
> > > > for falsely marking loss of data = during the pause. Without the
> > > > use of the M-bit, falsely = marking lost text will occur slightly
> > > > more often.
> > > >
> > >
> > > The text-spurt starts with the packet = that you transmit after a
> > > zero-length block is transmitted, = that happens whenever the T.140
> > > buffering interval expires and no new = data
> > > is available for transmission.
> > >
> > >
> > > > For the plain text/t140 format, = I do not see any need
> for marking
> > > > the first packet after a longer = pause.
> > > >
> > >
> > > It helps in situations when one can = not include a
> > zero-length block as
> > > redundant data because it's too = old.
> > >
> > > > For red/audio/t140 I see no need = for the M-bit. The
> > counter give a
> > > > better reliability.
> > > >
> > >
> > > During a interval where text is = transmitted contiguously, the
> > > block-counter and the RTP sequence = numbers are in sync. So
> > I guess the
> > > counter is only useful at the = boundaries when
> > > switchover between voice/text payload = is occurring. Under
> > certain loss
> > > scenarios or when both marker and = zero-length blocks are lost one
> > > could have misleading text = loss-indicator which in any case are
> > > unavoidable. In either
> > > case you would detect loss as = required.
> > >
> > > As I mentioned earlier, I am = unconvinced about the
> > usefulness of the
> > > block counter. During contiguous text = transmission the
> > counter and RTP
> > > sequence numbers are in sync. Even if = marker is lost, one
> > could sync
> > > to the first sequence number that can = be deriver or is
> > present in the
> > > header. IMO, different redundancy = rules for text/t140 and
> > audio/t140
> > > can be unified and
> > > implementation simplified.
> > >
> > > > The current RFC2793 does not = specify the use of the M-bit.
> > > > RFC2793bis should be compatible = with RFC2793 for text/t140 and
> > > > text/red/t140. Using the M-bit = for RFC2793 bis would be a
> > step off
> > > > from that direction.
> > > >
> > > > Anyway, it does little harm, so = if there are voices for
> > it, we could
> > > > say that the transmitter MUST = use the M-bit to indicate
> start of
> > > > stream, and start after a pause. = The receiver MAY use it for
> > > > detection of loss.
> > > >
> > > >
> > > > Please advice
> > > >
> > > > Regards
> > > >
> > > > Gunnar
> > > > = --------------------------------------------------------------
> > > > -------------
> > > > -------
> > > >
> > > >
> > > > Satish,
> > > > Further answers inline,
> > > >
> > > > Gunnar
> > > >
> > > > = -------------------------------------------
> > > > Gunnar Hellstr=F6m
> > > > Omnitor AB
> > > > Renathv=E4gen 2
> > > > SE 121 37 Johanneshov
> > > > SWEDEN
> > > > +46 8 556 002 03
> > > > Mob: +46 708 204 288
> > > > www.omnitor.se
> > > > = Gunnar.Hellstrom@Omnitor.se
> > > > = --------------------------------------------
> > > >
> > > >
> > > > > -----Original = Message-----
> > > > > From: Paul E. Jones [mailto:paulej@packetizer.com]<= /FONT>
> > > > > Sent: Thursday, May 06, = 2004 11:10 PM
> > > > > To: Mundra, Satish; 'Gunnar = Hellstrom'; avt IETF
> > > > > Subject: Re: [avt] = Comments/questions on
> > > > > = draft-ietf-avt-rfc2793bis-03/04
> > > > >
> > > > >
> > >
> > > X--------snip
> > >
> > > = _______________________________________________
> > > Audio/Video Transport Working = Group
> > > avt@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/avt
> > >
> > >
> >
> >
>
> = _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
>
>

_______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun May 16 05:57:12 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24312 for ; Sun, 16 May 2004 05:57:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPIJM-0003YC-Op for avt-archive@odin.ietf.org; Sun, 16 May 2004 05:52:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4G9q0Ah013616 for avt-archive@odin.ietf.org; Sun, 16 May 2004 05:52:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPIDa-0002FZ-CE; Sun, 16 May 2004 05:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPHZl-0005VO-2Y for avt@optimus.ietf.org; Sun, 16 May 2004 05:04:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22735 for ; Sun, 16 May 2004 05:04:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPHZh-000441-Rr for avt@ietf.org; Sun, 16 May 2004 05:04:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPHYk-0003i4-00 for avt@ietf.org; Sun, 16 May 2004 05:03:51 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1BPHY9-0003IY-00 for avt@ietf.org; Sun, 16 May 2004 05:03:13 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:60145 helo=[192.168.0.3]) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:RC4-MD5:128) (Exim 4.04) id 1BPHXf-0002gC-00; Sun, 16 May 2004 10:02:44 +0100 From: Colin Perkins Organization: http://csperkins.org To: avt@ietf.org Subject: Re: [AVT] WG last call: text/red and RFC2793bis Date: Sun, 16 May 2004 10:02:44 +0100 User-Agent: KMail/1.6.2 Cc: "John Lazzaro" References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200405161002.45257.csp@csperkins.org> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Friday 14 May 2004 19:08, John Lazzaro wrote: > A suggestion. After the first time a document goes to Last Call, > and gets OKed by someone (on text/red that was me), all future > requests should include URLs to the I-D diffs on this website: > > http://ietf.levkowetz.com/drafts/avt/text-red/ > > and an "OK on the diffs" should be considered an OK on the document. I wasn't aware of that website, but it certainly looks useful. Being "okay on the diffs" is certainly acceptable, provided one has checked an earlier version of the draft - I frequently do this using tkdiff. > I just checked over the -02/-03 and -03/-04 diffs for tex/red and give > my OK on the diffs. Many thanks... Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun May 16 05:57:32 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24329 for ; Sun, 16 May 2004 05:57:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPILg-0003re-VZ for avt-archive@odin.ietf.org; Sun, 16 May 2004 05:54:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4G9sOed014849 for avt-archive@odin.ietf.org; Sun, 16 May 2004 05:54:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPIDa-0002Fh-Va; Sun, 16 May 2004 05:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPHdu-0006XO-5P for avt@optimus.ietf.org; Sun, 16 May 2004 05:09:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22958 for ; Sun, 16 May 2004 05:09:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPHdq-0005dH-Vt for avt@ietf.org; Sun, 16 May 2004 05:09:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPHcn-0005EO-00 for avt@ietf.org; Sun, 16 May 2004 05:08:01 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1BPHbp-0004SM-00 for avt@ietf.org; Sun, 16 May 2004 05:07:02 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:60171 helo=[192.168.0.3]) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:RC4-MD5:128) (Exim 4.04) id 1BPHbM-0002gR-00; Sun, 16 May 2004 10:06:32 +0100 From: Colin Perkins Organization: http://csperkins.org To: avt@ietf.org Subject: Re: [AVT] WG last call: text/red Date: Sun, 16 May 2004 10:06:34 +0100 User-Agent: KMail/1.6.2 Cc: "Mundra, Satish" , "'Paul E. Jones'" References: <09DD40ABD88ACF4CB0D3CD84BB95296001B475@tnint11.telogy.design.ti.com> In-Reply-To: <09DD40ABD88ACF4CB0D3CD84BB95296001B475@tnint11.telogy.design.ti.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200405161006.34378.csp@csperkins.org> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thanks! I believe there were a couple of typos found which should be corrected in a new version of the draft, but no-one has raised a technical problem. Paul - can you submit an update to fix the editorial things, then we'll advance the draft to the IESG. Colin On Friday 14 May 2004 23:21, Mundra, Satish wrote: > Colin/Paul, > > > I have reviewed the draft . > It looks good to move further. > > > Regards, > > > Satish Mundra > > > -----Original Message----- > > From: Colin Perkins [mailto:csp@csperkins.org] > > Sent: Friday, April 30, 2004 2:52 PM > > To: IETF AVT WG > > Subject: [AVT] WG last call: text/red and RFC2793bis > > > > > > This is to announce a working group last call on the "text/red" MIME > > type registration , and the > > RTP Payload > > Format for Text Conversation . Both > > drafts are under consideration for proposed standard status. > > > > Please send any final comments on these drafts to the mailing list > > before Friday 14th May 2004. Note that we will not advance > > either draft > > until we receive a valid review of the work by someone other than the > > authors. > > > > Colin > > > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www1.ietf.org/mailman/listinfo/avt > > _______________________________________________ Audio/Video Transport > Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun May 16 17:34:24 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22598 for ; Sun, 16 May 2004 17:34:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPTFx-0003XP-Rr for avt-archive@odin.ietf.org; Sun, 16 May 2004 17:33:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4GLXDJD013599 for avt-archive@odin.ietf.org; Sun, 16 May 2004 17:33:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPT90-0002nP-Cs; Sun, 16 May 2004 17:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPT3U-00029c-Pz for avt@optimus.ietf.org; Sun, 16 May 2004 17:20:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22255 for ; Sun, 16 May 2004 17:20:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPT3S-0000AY-D5 for avt@ietf.org; Sun, 16 May 2004 17:20:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPT2X-0007f7-00 for avt@ietf.org; Sun, 16 May 2004 17:19:22 -0400 Received: from av4-2-sn3.vrr.skanova.net ([81.228.9.112]) by ietf-mx with esmtp (Exim 4.12) id 1BPT1b-000741-00 for avt@ietf.org; Sun, 16 May 2004 17:18:23 -0400 Received: by av4-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 47DC737ECE; Sun, 16 May 2004 23:17:52 +0200 (CEST) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av4-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 36C4037E53; Sun, 16 May 2004 23:17:52 +0200 (CEST) Received: from vit (h53n2fls31o265.telia.com [217.208.189.53]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with SMTP id BC9E038012; Sun, 16 May 2004 23:17:51 +0200 (CEST) From: "Gunnar Hellstrom" To: , "Colin Perkins" Cc: "Paul Jones(Packetizer)" , "Satish Mundra" Subject: RE: [AVT] WG last call: text/red and RFC2793bis Date: Sun, 16 May 2004 23:17:52 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200405140949.48748.csp@csperkins.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Colin and all, Thanks for fruitful review and discussion. We will make a new revision available. This is where the current revision is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2793bis-04.txt I have the following notes about things to change, or things discussed: 1. Section 3.6. Use of M-bit. Use of M-bit shall be recommended to mark beginning of new text after a p= eriod of silence, just as in the AVP profile. I see that some applications may find this useful and we do not want to h= inder that. The SHOULD for transmission will be included without any recommendation about= what the receiver shall do. But see discussion under 13 for possible sharpening of this statement. 2. Section 4, insert word "protection" before "methods" in next-to-last l= ine makes it more clear what it is about. 3. Section 4.2. transmission of old redundant data. Change rule about redundant data older than 16383 ticks. Include them, bu= t set the timestamp offset to hex 3FFF. We never used the timestamp of text for any= thing. The receiver may decide if it is still appropriate to present the text. This = new strategy simplifies logic for detection of loss, and avoiding false detection of l= oss. 4. The first two paragraphs of 4.2 should be valid for audio/t140 as well= and should therefore be moved to sec. 4.1. The corresponding part in section 4.3 can= be deleted. 5. In sec 4.3. Insert a clarification that the length indicator of the re= dundant block includes the t140 counter. 6. Section 5.4. Make it clear that when using red payload, it should be u= sed all through the session. ( with change 3 above, we always have redundant blocks, exce= pt in the first packet. 7 Last example in sec 7.1. The R2 and R1 mark should change places. Newer= data is placed after older. 8 Last example in sec 7.2. The F-bit of the last redundancy header s.b. 0 9 Last example in sec 7.2. The text says that there are two levels of red= undant info in the example, but the figure only shows one redundant header. Insert one m= ore. 10 Section 3.2. T140block counter initialized to zero is a security weakn= ess. We got a comment that it opens to security attacks to specify that the t1= 40block counter shall begin with the value zero. This value was selected in order to be a= ble to detect loss of the first block. In T.140, there is a requirement that the sessio= n shall start with a Unicode synchronization character. Even if there is no instruction= today in T.140 to indicate that the synch character is missing, applications can do so. However, the counter is a field in the payload, and it is common to have = fixed patterns, like start-of-picture, start-of-block etc. in the payloads. We can change the text to require that the t140block counter shall start = with a random value, and hint that upper layers should indicate loss of the synch chara= cter. I would like a second opinion on the importance of avoiding initial zero = value on t140block counter before we do this change. 11. Find another solution for loss detection in audio/t140 than introduci= ng the t140block counter. We had discussions on ways to avoid using the t140block counter for audio= /t140 in order to save bits and make the two formats more equal. Methods were proposed base= d on the M-bit and detection of empty blocks of data, and evaluating the differences in = sequence numbers to detect if text or audio was lost in the audio/t140 case. All these pro= posed methods appeared to have logic weaknesses, so we prefer to stay with the more bit= consuming but more reliable and simple method based on the t140block counter. 12. False detection of loss in the text/red/t140 format. A small risk for false detection of loss has been pointed out in the text= /red/t140 format. If all transmissions of an empty block are lost, the receiver may deduct = that text is lost and indicate that to the upper layers. But no text was lost, just an empt= y block. We want to maintain interoperability with RFC2793, and that reduces the o= pportunity to do anything about this risk. The rule in item 3 above helps to some degree. There are other "invisible" characters in T.140, e.g. the "bell" for audi= ble, visible or tactile alerting during call. Loss of it will be also marked by a missing= text marker even if nothing is missing in the visual presentation. Therefore the users wil= l understand the missing text indicator that there MAY have been a loss of visible charact= ers. Therefore it is better to give some false indications than to drop text without markin= g it. Thus the currently defined procedures are suitable and no change is neede= d. 13. Late and false detection of loss in the audio/t140 and text/t140 form= at In the formats without redundancy, the current procedures will not reveal= loss until next real character is transmitted. That may take minutes. A proposal is to in= troduce and send the same empty block once after the buffering timeout. Next time there is= something real to send, it should be sent with the M-bit. Loss of the last real character may be detected soon, if the empty block = is received. If the last, empty block is lost, but next block, sent with M-bit is rece= ived, a rule can be that a gap of two in sequence number when M-bit is received shall not = be reported as loss. A gap of three or more shall be reported as loss. If the block with= the M-bit is lost, real data is lost, and next reception will show no M-bit and a numb= er gap of 2 or more that leads to indication of loss. This procedure need to be defined with MUST for both transmission of empt= y block and for transmission of M-bit and use of the logic for detection of loss, otherwi= se there will be false detections and missed detections if different applications implemen= t different parts. One side effect will be packets with just empty blocks taking up bandwidt= h. I want to check the feelings for introducing this method. 14. The "text spurt" concept. In the discussions, the word "text spurt" has been used often. I hope tha= t it has not influenced anyone to believe that text and voice must come in "spurts" an= d take turns. It was an unfortune functional limitation in most old text telephone systems= in PSTN, but it is definitely not the way users want to use text and voice in a call. An = opportunity to use both media in parallell is what the users want, and it can easily be = achieved in IP transmission. Conclusion: Avoid influencing the transmission methods by organising tran= smission in spurts. Let it be a matter at the terminals or gateways. Regards Gunnar ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Colin Perkins Sent: Friday, May 14, 2004 10:50 AM To: avt@ietf.org Subject: Re: [AVT] WG last call: text/red and RFC2793bis On Friday 30 April 2004 19:51, Colin Perkins wrote: > This is to announce a working group last call on the "text/red" MIME > type registration , and the RTP Payload > Format for Text Conversation . Both > drafts are under consideration for proposed standard status. > > Please send any final comments on these drafts to the mailing list > before Friday 14th May 2004. Note that we will not advance either draft > until we receive a valid review of the work by someone other than the > authors. The working group last call for these drafts ends today. There has been considerable discussion of the 2793bis draft on the mailin= g list, thanks to the review by Satish Mundra, and it appears that there ar= e open issues to resolve. Accordingly, we will not advance the 2793bis draf= t until a revision is available that addresses these concerns. The text/red draft has not yet received a public last call review, even through there are 1077 people on the list who received the request for input. Accordingly, it will continue in working group last call until such a review is received. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon May 17 04:36:42 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07303 for ; Mon, 17 May 2004 04:36:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPdW9-0006Lr-Ny for avt-archive@odin.ietf.org; Mon, 17 May 2004 04:30:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4H8Ub3C024412 for avt-archive@odin.ietf.org; Mon, 17 May 2004 04:30:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPdJ0-0004j5-Gw; Mon, 17 May 2004 04:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPdDK-0003xg-6i for avt@optimus.ietf.org; Mon, 17 May 2004 04:11:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06350 for ; Mon, 17 May 2004 04:11:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPdDH-00010K-IV for avt@ietf.org; Mon, 17 May 2004 04:11:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPdCM-0000fn-00 for avt@ietf.org; Mon, 17 May 2004 04:10:11 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BPdBP-0000L1-00 for avt@ietf.org; Mon, 17 May 2004 04:09:11 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i4H89BPA013235 for ; Mon, 17 May 2004 10:09:11 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 17 May 2004 10:09:11 +0200 Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.60]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id KM010ZRX; Mon, 17 May 2004 10:09:11 +0200 Message-ID: <40A87327.1060905@ericsson.com> Date: Mon, 17 May 2004 10:09:11 +0200 X-Sybari-Trust: 6375a1a8 08d63d2e 2ac7f470 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: Gunnar Hellstrom CC: avt@ietf.org Subject: Re: [AVT] WG last call: text/red and RFC2793bis References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 May 2004 08:09:11.0741 (UTC) FILETIME=[3C89FED0:01C43BE6] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Gunnar, I have some comments: Gunnar Hellstrom wrote: [snip] > > 3. Section 4.2. transmission of old redundant data. > Change rule about redundant data older than 16383 ticks. Include them, > but set the > timestamp offset to hex 3FFF. We never used the timestamp of text for > anything. The > receiver may decide if it is still appropriate to present the text. This > new strategy > simplifies logic for detection of loss, and avoiding false detection of > loss. > It might look fine, doing what you proposed. However I see a few problems, that you will need to verify that you have thought of: A. If multiple text blocks fall outside of the 16383 ticks, then you will recover multiple text blocks with equal timestamp. That violates one of your must. B. How will old implementations react to this change? According to the old draft, a implementation may very well use the timestamp to check if the text block is the same as a previous one. Thus I think this change has interoperability issues. [snip] > > 9 Last example in sec 7.2. The text says that there are two levels of > redundant info in > the example, but the figure only shows one redundant header. Insert one > more. This is in fact not an error, according to your own rules, if one reads the text completely: "As a follow-on to the previous example, the example below shows the next RTP packet in the sequence which does contain a new real T140block when using the audio/t140 payload format. This example has 2 levels of redundancy and one primary data block. Since the previous primary block was empty, no redundant data is included for that block. This is because when using the audio/t140 payload format, any previously transmitted "empty" T140blocks are NOT included as redundant data in subsequent packets." You get the explanation in the last sentence. If it is desired to think of non sent block as impacting redundancy or not is another question. You will have to consider if it is more logical to repeat the same packet more than once, letting the receiver use the T140block counter to detect this, or in fact move on and include the empty blocks in the shift. > > 10 Section 3.2. T140block counter initialized to zero is a security > weakness. > We got a comment that it opens to security attacks to specify that the > t140block counter > shall begin with the value zero. This value was selected in order to be > able to detect > loss of the first block. In T.140, there is a requirement that the > session shall start > with a Unicode synchronization character. Even if there is no > instruction today in T.140 > to indicate that the synch character is missing, applications can do so. > > However, the counter is a field in the payload, and it is common to have > fixed patterns, > like start-of-picture, start-of-block etc. in the payloads. > > We can change the text to require that the t140block counter shall start > with a random > value, and hint that upper layers should indicate loss of the synch > character. > > I would like a second opinion on the importance of avoiding initial zero > value on > t140block counter before we do this change. This depends on the cipher used when performing the encryption. For example in SRTP the ciphers defined for usage, all have the property of being resistant to known plain text attacks. I totally agree with the sentence in SRTP RFC 3711, section 9.3: As some RTP packet could contain highly predictable data, e.g., SID, it is important to use a cipher designed to resist known plain text attacks (which is the current practice). An older cipher may not have this property. Which is likely based on the random tag for RTCP, and other things in RTP. However I think this property is necessary for any cipher being used with RTP. Because it is predictable to a large extent. Therefore any cipher not having this property should be replaced. And I don't see that RFC 2793bis makes this worse. I hope that any security expert will correct me if what I write is wrong. Therefore I think you will be safe to define it as starting a 0. However in certain applications, for example multiparty sessions, the start at 0 will give very little information, e.g. for late joiners. Basically it could only be used to count how many text blocks a certain user has sent. Thus I don't see any real gain of starting at 0. > > 11. Find another solution for loss detection in audio/t140 than > introducing the t140block > counter. > We had discussions on ways to avoid using the t140block counter for > audio/t140 in order to > save bits and make the two formats more equal. Methods were proposed > based on the M-bit > and detection of empty blocks of data, and evaluating the differences in > sequence numbers > to detect if text or audio was lost in the audio/t140 case. All these > proposed methods > appeared to have logic weaknesses, so we prefer to stay with the more > bit consuming but > more reliable and simple method based on the t140block counter. > I don't think bit-rate consumption in the payload for real users is a major consideration. I can agree that alignment would have been nice, however I think that robustness is more important. [snip] > > 13. Late and false detection of loss in the audio/t140 and text/t140 > format > In the formats without redundancy, the current procedures will not > reveal loss until next > real character is transmitted. That may take minutes. A proposal is to > introduce and send > the same empty block once after the buffering timeout. Next time there > is something real > to send, it should be sent with the M-bit. > Loss of the last real character may be detected soon, if the empty block > is received. > If the last, empty block is lost, but next block, sent with M-bit is > received, a rule can > be that a gap of two in sequence number when M-bit is received shall not > be reported as > loss. A gap of three or more shall be reported as loss. If the block > with the M-bit is > lost, real data is lost, and next reception will show no M-bit and a > number gap of 2 or > more that leads to indication of loss. > > This procedure need to be defined with MUST for both transmission of > empty block and for > transmission of M-bit and use of the logic for detection of loss, > otherwise there will be > false detections and missed detections if different applications > implement different > parts. > > One side effect will be packets with just empty blocks taking up > bandwidth. > I want to check the feelings for introducing this method. > As I understand it, this is the case when no RFC 2198 redundancy is used, and some other mechanism for reliability is used. When the last transmitted packet is lost, you are claiming that it might be minutes until this loss i detected. However, I think you have forgotten RTCP SR packets. If one uses RTCP, there should be two RTCP SR packets sent, which will both indicate that this RTP packet has been sent. Of course they can be both be lost. But there is need for 3 lost packets instead of only one, as you thought. Thus I don't know how sensitive problem this is. A sender could also monitor the receiver reports from the client, if they never reports the last packet received, one could send out an empty block, to ensure that it is received. If one does this, one can in most cases ensure that a receiver either gets the text block, or at least detect it as lost. And doing the smart thing at either end will reduce the risk of false indication to a level where it is not worth reporting. I would avoid any receiver heuristics for when a packet should be marked lost or not. Because they are likely to produce more errors then expected. Having a rule allowing a receiver to remove a loss marker after a while, does not seem to make much improvement. Isn't it also that if these mistakes are rare enough, we can let the human repair mechanism take care of it. Cheers Magnus -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon May 17 10:30:59 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25523 for ; Mon, 17 May 2004 10:30:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPj4z-0004XZ-6I for avt-archive@odin.ietf.org; Mon, 17 May 2004 10:26:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HEQvbi017454 for avt-archive@odin.ietf.org; Mon, 17 May 2004 10:26:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPixO-0002q3-IA; Mon, 17 May 2004 10:19:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPiuY-0001uo-5G for avt@optimus.ietf.org; Mon, 17 May 2004 10:16:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24598 for ; Mon, 17 May 2004 10:16:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPiuV-0007lj-Sg for avt@ietf.org; Mon, 17 May 2004 10:16:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPitV-0007Rj-00 for avt@ietf.org; Mon, 17 May 2004 10:15:06 -0400 Received: from [80.74.106.125] (helo=rvil-mail.RADVISION.com) by ietf-mx with esmtp (Exim 4.12) id 1BPisj-0006nm-00 for avt@ietf.org; Mon, 17 May 2004 10:14:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43C19.7CA69308" Date: Mon, 17 May 2004 17:16:03 +0300 Message-ID: Thread-Topic: RFC3711, MKI and Thread-Index: AcQ8GXybWC7aP24XSlqhF0QjNtxmcw== From: "Ofer Goren" To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 Subject: [AVT] RFC3711, MKI and Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C43C19.7CA69308 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi. =20 Since I'm new to security issues I have the following question: =20 If the SRTP and SRTCP for the same session DO NOT share the same master = key (well, even if they DO share it), can each of those protocols use = different method for master-key retrieval? e.g. the SRTP uses the MKI = method, and the SRTCP uses the method. And if so, is there = any reason to do so, or can I safely assume this will not happen? =20 Thanks, =20 Ofer ___________________________________________________ "What kind of a name is Azam Azam?" - Butrus Butrus Ghali. =20 ------_=_NextPart_001_01C43C19.7CA69308 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Hi.

Since = I'm new to=20 security issues I have the following question:

If the = SRTP and=20 SRTCP for the same session DO NOT share the same master key = (well, even=20 if they DO share it), can each of those protocols use different method = for=20 master-key retrieval? e.g. the SRTP uses the MKI method, and the SRTCP = uses the=20 <From, To> method. And if so, is there any reason to do so, or can = I=20 safely assume this will not happen?

Thanks,

Ofer

___________________________________________________

"What kind of a = name is Azam=20 Azam?" - Butrus Butrus Ghali.

------_=_NextPart_001_01C43C19.7CA69308-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon May 17 12:26:44 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02926 for ; Mon, 17 May 2004 12:26:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPkhD-0001VC-6q for avt-archive@odin.ietf.org; Mon, 17 May 2004 12:10:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HGAVjH005717 for avt-archive@odin.ietf.org; Mon, 17 May 2004 12:10:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPkUA-0007wU-NI; Mon, 17 May 2004 11:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPkQP-0006yX-Qz for avt@optimus.ietf.org; Mon, 17 May 2004 11:53:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00243 for ; Mon, 17 May 2004 11:53:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPkQO-0001KZ-ID for avt@ietf.org; Mon, 17 May 2004 11:53:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPkPQ-00010e-00 for avt@ietf.org; Mon, 17 May 2004 11:52:08 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BPkOa-0000Mm-00 for avt@ietf.org; Mon, 17 May 2004 11:51:16 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 17 May 2004 07:57:45 +0000 Received: from mbaugher-w2k07.cisco.com (sjc-vpn4-865.cisco.com [10.21.83.96]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4HFocSv015705; Mon, 17 May 2004 08:50:39 -0700 (PDT) Message-Id: <6.0.0.22.2.20040517084224.0434dd68@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 17 May 2004 08:51:06 -0700 To: "Ofer Goren" From: Mark Baugher Subject: Re: [AVT] RFC3711, MKI and Cc: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL autolearn=no version=2.60 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , hi Ofer, RFC 3711 places few restrictions on key management. It is up to the key establishment method (e.g. MIKEY or SDP Security Descriptions) to constrain how keys are defined, installed, maintained and updated. I think it is possible to do complex and probably therefor insecure things like you mention in your note. This is a key management problem, and interoperable SRTP implementations will need to have interoperable key management systems. Mark At 07:16 AM 5/17/2004, Ofer Goren wrote: >Hi. > >Since I'm new to security issues I have the following question: > >If the SRTP and SRTCP for the same session DO NOT share the same master >key (well, even if they DO share it), can each of those protocols use >different method for master-key retrieval? e.g. the SRTP uses the MKI >method, and the SRTCP uses the method. And if so, is there any >reason to do so, or can I safely assume this will not happen? > >Thanks, > >Ofer >___________________________________________________ >"What kind of a name is Azam Azam?" - Butrus Butrus Ghali. > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon May 17 15:32:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18347 for ; Mon, 17 May 2004 15:32:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPna9-0005KK-K0 for avt-archive@odin.ietf.org; Mon, 17 May 2004 15:15:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HJFPnZ020472 for avt-archive@odin.ietf.org; Mon, 17 May 2004 15:15:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPnFS-0005f2-A2; Mon, 17 May 2004 14:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPnAu-0004a7-LY for avt@optimus.ietf.org; Mon, 17 May 2004 14:49:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14112 for ; Mon, 17 May 2004 14:49:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPnAr-0001zY-Oj for avt@ietf.org; Mon, 17 May 2004 14:49:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPnA6-0001bx-00 for avt@ietf.org; Mon, 17 May 2004 14:48:30 -0400 Received: from glatton.cnchost.com ([207.155.248.47]) by ietf-mx with esmtp (Exim 4.12) id 1BPn9A-0001E0-00 for avt@ietf.org; Mon, 17 May 2004 14:47:32 -0400 Received: from MedhaviLT (61.79.219.209.transedge.com [209.219.79.61]) by glatton.cnchost.com id OAA18323; Mon, 17 May 2004 14:47:31 -0400 (EDT) [ConcentricHost SMTP Relay 1.17] Message-ID: <200405171847.OAA18323@glatton.cnchost.com> Reply-To: From: "Medhavi Bhatia" To: Date: Mon, 17 May 2004 14:47:44 -0400 Organization: NexTone Communications MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0130_01C43C1D.EA52A760" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcQ8Nj0pLcAPxiPwQraeM8o1XDAvWAACSbFQ X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_MESSAGE, MISSING_OUTLOOK_NAME autolearn=no version=2.60 Subject: [AVT] RE: statis of draft-even-avt-h263-h261-options-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0130_01C43C1D.EA52A760 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Do we know what is the status of the following draft: draft-even-avt-h263-h261-options-00.txt -Medhavi ------=_NextPart_000_0130_01C43C1D.EA52A760 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Do we know what is the status of the following = draft:

draft-even-avt-h263-h261-options-00.txt<= /p>

-Medhavi

------=_NextPart_000_0130_01C43C1D.EA52A760-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon May 17 17:15:44 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29050 for ; Mon, 17 May 2004 17:15:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPoU0-0008M9-Kk for avt-archive@odin.ietf.org; Mon, 17 May 2004 16:13:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HKD8YB032122 for avt-archive@odin.ietf.org; Mon, 17 May 2004 16:13:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPo7o-0008GQ-6S; Mon, 17 May 2004 15:50:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPnsh-00036q-QD for avt@optimus.ietf.org; Mon, 17 May 2004 15:34:35 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18546; Mon, 17 May 2004 15:34:33 -0400 (EDT) Message-Id: <200405171934.PAA18546@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: avt@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 17 May 2004 15:34:33 -0400 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-h264-06.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart 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 Format for H.264 Video Author(s) : S. Wenger Filename : draft-ietf-avt-rtp-h264-06.txt Pages : 72 Date : 2004-5-17 This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability supporting from simple low-bit rate conversational usage to Internet video streaming with interleaved transmission, all the way to high bit-rate video-on- demand applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-h264-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-h264-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@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-h264-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-17155643.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-h264-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-h264-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-17155643.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon May 17 17:15:52 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29092 for ; Mon, 17 May 2004 17:15:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPoUR-0008Uu-5O for avt-archive@odin.ietf.org; Mon, 17 May 2004 16:13:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HKDZXq032660 for avt-archive@odin.ietf.org; Mon, 17 May 2004 16:13:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPo7o-0008Gr-W6; Mon, 17 May 2004 15:50:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPntQ-0003Gf-0E for avt@optimus.ietf.org; Mon, 17 May 2004 15:35:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18581 for ; Mon, 17 May 2004 15:35:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPntO-00038p-KR for avt@ietf.org; Mon, 17 May 2004 15:35:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPnsY-0002lw-00 for avt@ietf.org; Mon, 17 May 2004 15:34:27 -0400 Received: from bzq-179-16-107.cust.bezeqint.net ([212.179.16.107] helo=accord-mail.israel.polycom.com) by ietf-mx with esmtp (Exim 4.12) id 1BPnrq-00027r-00 for avt@ietf.org; Mon, 17 May 2004 15:33:43 -0400 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 May 2004 22:32:59 +0300 Message-ID: From: "Even, Roni" To: "'mbhatia@nextone.com'" , avt@ietf.org Subject: RE: [AVT] RE: statis of draft-even-avt-h263-h261-options-00.txt Date: Mon, 17 May 2004 22:32:57 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43C45.C1F8BB10" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C43C45.C1F8BB10 Content-Type: text/plain; charset="iso-8859-1" Hi The work went into revising the H.263 and H.261 payload specs look in http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2429-bis-01.txt and http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2032-bis-00.txt - this draft will be revised soon, the major change is that the separator should be semi-colon and not space according to the MIME type RFC Roni Even =-----Original Message----- From: Medhavi Bhatia [mailto:mbhatia@nextone.com] Sent: Monday, May 17, 2004 9:48 PM To: avt@ietf.org Subject: [AVT] RE: statis of draft-even-avt-h263-h261-options-00.txt Do we know what is the status of the following draft: draft-even-avt-h263-h261-options-00.txt -Medhavi ------_=_NextPart_001_01C43C45.C1F8BB10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The work went into revising the H.263 and = H.261 payload=20 specs

look in

http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2429-bis-= 01.txt

and

http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2032-bis-= 00.txt -=20 this draft will be revised soon, the major change is that the separator = should=20 be semi-colon and not space according to the MIME type=20 RFC

Roni=20 Even

=3D-----Original=20 Message-----
From: Medhavi Bhatia=20 [mailto:mbhatia@nextone.com]
Sent: Monday, May 17, 2004 9:48=20 PM
To: avt@ietf.org
Subject: [AVT] RE: statis of=20 draft-even-avt-h263-h261-options-00.txt

Do we know what is the status of the = following=20 draft:

draft-even-avt-h263-h261-options-00.txt

-Medhavi

------_=_NextPart_001_01C43C45.C1F8BB10-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon May 17 17:16:21 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29211 for ; Mon, 17 May 2004 17:16:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPoYW-0001Lt-N7 for avt-archive@odin.ietf.org; Mon, 17 May 2004 16:17:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HKHm3e005192 for avt-archive@odin.ietf.org; Mon, 17 May 2004 16:17:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPo7t-0008I8-NV; Mon, 17 May 2004 15:50:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPnuE-0003Nt-7y for avt@optimus.ietf.org; Mon, 17 May 2004 15:36:10 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18707; Mon, 17 May 2004 15:36:08 -0400 (EDT) Message-Id: <200405171936.PAA18707@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: avt@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 17 May 2004 15:36:08 -0400 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-h264-06.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart 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 Format for H.264 Video Author(s) : S. Wenger, et al. Filename : draft-ietf-avt-rtp-h264-06.txt Pages : 72 Date : 2004-5-17 This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability supporting from simple low-bit rate conversational usage to Internet video streaming with interleaved transmission, all the way to high bit-rate video-on- demand applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-h264-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-h264-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@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-h264-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-17155643.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-h264-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-h264-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-17155643.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon May 17 18:12:27 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07553 for ; Mon, 17 May 2004 18:12:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPq8r-0000Jl-25 for avt-archive@odin.ietf.org; Mon, 17 May 2004 17:59:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HLxPvG001174 for avt-archive@odin.ietf.org; Mon, 17 May 2004 17:59:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPpu8-0002BP-F3; Mon, 17 May 2004 17:44:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPpia-0001k2-8p for avt@optimus.ietf.org; Mon, 17 May 2004 17:32:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01636 for ; Mon, 17 May 2004 17:32:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPpiX-00038I-Os for avt@ietf.org; Mon, 17 May 2004 17:32:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPpft-0002At-00 for avt@ietf.org; Mon, 17 May 2004 17:29:29 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BPpdK-0001ES-00 for avt@ietf.org; Mon, 17 May 2004 17:26:50 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 17 May 2004 14:24:41 -0700 Received: from cisco.com (sjc-vpn4-56.cisco.com [10.21.80.56]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i4HLQI0Q013411 for ; Mon, 17 May 2004 14:26:18 -0700 (PDT) Message-ID: <40A92E18.5A8AE6F4@cisco.com> Date: Mon, 17 May 2004 17:26:48 -0400 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "avt@ietf.org" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,TO_ADDRESS_EQ_REAL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [AVT] Question on RTCP statistics processing Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Greetings Let's say I have a unicast RTP session in "sendonly" or "inactive" mode (per SDP), but nevertheless, somebody is sending me RTP packets. Do I include those packets in my RTCP statistics (packets lost, jitter, etc.) or do I throw them away before we even get to that point ? In other words, is RTCP statistics processing affected by higher layer signaling about the directionality of the RTP session ? Thanks Flemming _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue May 18 10:04:16 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15619 for ; Tue, 18 May 2004 10:04:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ53q-00020i-5a for avt-archive@odin.ietf.org; Tue, 18 May 2004 09:55:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IDtETt007728 for avt-archive@odin.ietf.org; Tue, 18 May 2004 09:55:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ4xy-0008WP-DI; Tue, 18 May 2004 09:49:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ4qC-00061F-34 for avt@optimus.ietf.org; Tue, 18 May 2004 09:41:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14707 for ; Tue, 18 May 2004 09:41:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ4q9-0000sU-T7 for avt@ietf.org; Tue, 18 May 2004 09:41:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ4p8-0000Sg-00 for avt@ietf.org; Tue, 18 May 2004 09:40:04 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BQ4o4-0007gv-00 for avt@ietf.org; Tue, 18 May 2004 09:38:56 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i4IDctWR019206 for ; Tue, 18 May 2004 15:38:55 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 May 2004 15:38:55 +0200 Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.60]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id L1CYGSLK; Tue, 18 May 2004 15:38:55 +0200 Message-ID: <40AA11EF.4020407@ericsson.com> Date: Tue, 18 May 2004 15:38:55 +0200 X-Sybari-Trust: ef7f4035 08d63d2e 06b283dd 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: Jose Rey , IETF AVT WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 18 May 2004 13:38:55.0832 (UTC) FILETIME=[77307580:01C43CDD] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by albatross.ericsson.se id i4IDctWR019206 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [AVT] Comments on draft-ietf-avt-rtp-3gpp-timed-text-01.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, Here is my comments on the draft. 1. Why is there a empty line in the header between author company and=20 publication date? Also expires should be on the line after the filename=20 to keep things together. 2. The status of this memo section is not correct. Section 10 of RFC=20 2026 has been replaced. With the publication RFC 3667 and 3668 it should=20 as I understand it now read: Status of this Memo By submitting this Internet-Draft, I (we) certify that any applicable patent or other IPR claims of which I am (we are) aware have been disclosed, and any of which I (we) become aware will be disclosed, in accordance with RFC 3668 (BCP 79). By submitting this Internet-Draft, I (we) accept the provisions of Section 3 of RFC 3667 (BCP 78). Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html ------ end of quote ------- Please notice that certain things in the declaration depends on document=20 type and what the author is willing to give away. For a WG document=20 going for standards track this will be most common appearance. These=20 details will become more clear when IETF has published new Internet=20 draft guidelines on the homepage. One can also add the following paragraph to clarify things further as it=20 is a wg document: This document is a submission of the IETF AVT WG. Comments should be directed to the AVT WG mailing list, avt@ietf.org. 3. The copyright notice on the first page. I am not certain it is=20 compatible with the one on the last page. Please remove. 4. Change log: Can you please restrain the change log to only be=20 difference since the previous version? It becomes quite long otherwise,=20 and I don't find it that useful. 5. Section 1. "Unit or Access Unit" Shouldn't the last sentence include=20 a "so building what is called a (access) unit."? 6. Section 3. Marker bit: I think it should be a normative word in=20 there, like "the marker bit SHALL be set to 1 if the RTP packet=20 includes one or more whole text samples or the last fragment of a text=20 sample; otherwise set to 0." 7. Section 3. " Timestamp: the timestamp MUST indicate the sampling instant of the earliest (or unique) text sample contained in the RTP packet." What is a "unique" text sample? Or are you simply meaning the "only"=20 text sample. 8. Section 3. Timestamp: I think there a some improvement one can make=20 to the timestamp derivation text when multiple samples or fragments are=20 present. - First I think the normative definition of the order of the samples or=20 fragments should be done in another chapter. - Then the normative definition of how to calculate the TS for a=20 subsequent sample does not seem to properly take into account that other=20 text samples may not carry duration. 9. Section 3: "If the timed text is streamed from a 3GP file, the timestamp clockrate MUST be copied directly from the value of "timescale" in the Media Header Box for that text track." Why is this a MUST? I understand that one must maintain the correct=20 synchronization, however if a sender determines to rewrite everything=20 upon transmission, is it something that will not work. 10. Section 3.1.2: "In order to transport these larger text samples using RTP, it could be argued that a careful encoding be used to transform the original large sample into smaller self-contained text samples that fit into the given transport MTU. This would comply with the ALF principle, as described in the guidelines for RTP payload formats, RFC 2736 [14]. It would also need additional pre-processing previous to RTP encapsulation and that senders understand the modifiers format. However, given the low probability of fragmentation, it is believed that the overhead of this pre-processing is not worth and it is more appropriate to encode text samples without taking the path MTU into account. In this manner, this payload format meets a trade-off by intentionally leaving out this pre-processing and making the fragmented samples less robust to packet losses." I would recommend that one does in fact tries to ensure that one has=20 samples that fits the network, but that to ensure functionality also in=20 these cases when this is difficult, or not possible due to other=20 constraints the fragmentation mechanism is present. However one SHOULD=20 take the MTU into account. 11. Section 3.1.2: "The most important consequence of this design choice=20 is that while text string fragments can be displayed in the absence of a=20 previous text fragment, modifiers for that text string are useless if=20 they are not completely received." I think it is a bit unclear what "they" are intended to be, the=20 modifiers or the text string. 12. Section 3.1.2: Second bullet: I think one can extend the conclusion=20 why this is good to become the following: "This reduces complexity by minimizing the number of fragments and thus=20 also improve the error robustness." 13. Section 3.1.2, third bullet: "in order to fill up the remaining bits of a packet, piggybacking of sample descriptions MAY be performed. Also fragments of past samples MAY be piggybacked. For this purpose the server MAY reserve a certain amount of buffer to store already sent units for piggybacking." What is meant by "In order to fill up the remaining bits ...". I guess=20 you mean "If space in the packet up to the MTU, and there is available=20 bit-rate, then sample description MAY be piggybacked. Also is really=20 piggybacked the right word? Does not a sample description need to have a=20 specific place in the packet, and thus can't be added at the end? 14. Section 3.1.4: " o Although units containing modifier boxes or fragments thereof do not include a duration field, they make use of the RTP timestamp to group together. Therefore, they SHOULD be transmitted in the same order as they appear in the sample and be placed as near as possible to the text to which they apply. Logically, this does not apply for retransmitted or redundant packets or for units that are piggybacked into other packets." Is this really correct that the modifier boxes does not need duration?=20 As I understand it any modifier box is connected to the text sample by=20 having the same timestamp. Thus it would require a modifier box to have=20 a duration field if they should be possible to aggregate separately in=20 regards to the text strings. 15. Section 3.1.4: The concept of unknown duration is a bit loosely=20 defined. I haven't checked 26.245, but is it really defined there? I=20 understand the desire have functionality to define a sample as being=20 active until replaced. However if this is not defined in the 3GPP spec,=20 I think we must be cautious of defining such a mechanisms. If it is=20 defined, does it use a special explicit indicator that this is the case?=20 Otherwise I think it should use such a SDUR field indicator. 16. Section 3.1.5: I think the buffer concept is somewhat garbled in=20 this paragraph. To me it seems to talk about about both sender side=20 buffers and receiver buffers, without making any real differentiation. 17. Section 3.2: I think this section before going into clear definition=20 of all types, should give a clear definition of how different blocks can=20 be aggregated, and how one derive the necessary information. How the=20 packets must be built to be able to recover which type 1 that a type 3=20 belongs to. I think there are some oversight here of not providing SDUR=20 also for type 3 and 4. I think the timestamp derivation for all packets=20 types must be made much more clear. 18. Section 3.2.1: Definition of "R" bits. Please also include that they=20 SHALL be ignored by the receiver. Otherwise they will not be possible to=20 use without external signalling. 19. Section 3.2.1: Type list: I think the types are in all case a single=20 fragment, not multiple ones that the plural form indicates. 20. Section 3.2.1: "Two TYPEs (1 & 2) are defined for units containing text strings another two (3 & 4) for units not containing text strings (thus no timing attributes) and a final TYPE 5 for sample descriptions (also lacking timing attributes)." This sentences missing a "," after "text strings". 21. Section 3.2.2: I thing the following sentences has some language=20 problems: "In this case, TYPE 1 units MUST not have contents. This means that the LEN field MUST have a value of 6 (0x0006). Otherwise, the LEN field MUST be always greater than 6 (0x0006)." I think it should read more like: "In this case, the TYPE 1 unit MUST not have contents, and the LEN field=20 SHALL have a value of 6. Otherwise the LEN field SHALL always be greater=20 than 6." 22. Section 3.2.4: "Note that the SLEN, SIDX and SDUR fields are not present. This is because: a) these fragments do not contain text strings and b) these types of fragments are applied over text string fragments, which already contain this information. " I think here would, unless better clarified elsewhere a place to=20 actually define how this type 3 is bound to its TYPE 1 or TYPE 2s. 23. Section 3.2.4: " o The TOTAL/THIS field indicates whether the unit contains a part of or the whole of the modifiers: if TOTAL=3DTHIS, then all modifiers are included here. In this case, TOTAL=3DTHIS MUST be greater than one, because there cannot be a sample of modifiers without text strings. Otherwise, this unit just contains the first fragment." Why must the value of total and this be larger than 1 although all=20 modifiers are contained in one sample? 24. Section 3.2.6: I think it is appropriate that the TYPE 5 header is=20 mandatory to implement, otherwise we will have problems with=20 interoperability. And the text claims that the implementation of this=20 format is rather minor, if true, then there is no reason for having it=20 optional. 25. Section 4. "... the simplest option for packet loss resilient transport is to send the same RTP packet or the same text samples (or fragments) again." This sentence contains a error: "the same RTP packet" SHALL NOT be=20 repeated. Repeating a packet implies to send two packets with the same=20 RTP sequence number. Thus preventing RTP's reporting mechanism to=20 discern the two different packets. So please remove this part, it is=20 fully sufficient to repeat the payloads. 26. Section 4. " o in repeated packets, all RTP header fields MUST keep their original values except the sequence number that MUST be increased to comply with RTP. " I think this should talk about repeating RTP payload, and thus requiring=20 all payload specified fields (TS, M, PT) to be the same. I don't see a=20 reason to demand that any other field are actually the same. If one over=20 specifies things, any future usage of an RTP profile will be extremely=20 problematic. 27. Section 4. "If single units are repeated in packets different from their originals, care SHALL be taken to preserve their original timing." What is here meant with original timing? 28. Section 4: " A possible solution MAY be that the encoder provides a static default=20 sample description to be used for these cases." I think one should clarify that this would need to be a application=20 specific definition. 29. Section 5. I would recommend that either use stricter need for=20 congestion control. Otherwise it might be wise to simply use the=20 following sentence: Congestion control for RTP SHALL be used in accordance with RFC 3550 [?], and any applicable RTP profile, e.g. RFC 3551 [?]. 30. section 6.2: I think that one shall have a SMIL reference at the=20 first use of the name. 31. Section 7.1: Please fix the indentation so it is easier to read: parameter: asl=F6dsa=F6s=F6dlkskaa=F6lsldsa=F6=F6l ads=F6sa=F6dsdsadsla=F6sa=F6ldsa 32. Section 7.1: The definition of how the value should be written is=20 unclear. First one thinks that z should be multiplied with the sum of=20 x*256+y, while it appears that the number should be concatenated. Please=20 clarify. 33. Section 7.1: Spldesc: It is two possibilities. Also I think possible=20 values "both" and "out" should be used mutually exclusive. 34. Section 7.1, tx3g: Please add a reference to the BASE64 RFC. It is=20 number 3548. 35. Section 7.1 tx3g: I think this is a optional parameter, as it is=20 allowed to be empty. Define the lack of it as equal to empty string. 36. Section 7.1, layer, tx, ty, heigth, width: What is the allowed value=20 range here. If it is a 32-bit integer please be explicit about it. 37. Section 7.1: I think that you need to be a bit more clear about how=20 the values are defined. Instead of some half formal definition of the=20 value, either write it clearly in word, or use formal syntax notation. I=20 think writing it in words are often sufficient. 38. Section 8.1: I think we have two bullets that are equivalent to two=20 others. The third and fourth, seem to be possible to replace with only=20 the fifth. 39. Section 8.2: I think there are a few problems with the offer answer=20 section. The first major one is the sample descriptions. How is they=20 handled in a bi-directional session? Are they defined per direction, and=20 how does then unicast differentiate multicast. Or are they shared=20 between all participants. But are then the answerer allowed to add his=20 to the list the offerer provide. These are hard problems but they need=20 to be spelled out. 40. Section 8.2: How is the version handled in an interoperable way? Is=20 a answerer allowed to downgrade the version he accepts to receive? Thus=20 enabling the offerer to tell that he is ready to receive and send=20 version X, while the answerer declares what it accepts to receive, and=20 thus most probably also send. 41. Section 8.2: The section uses server, while an offer/answer session=20 rarely has these designations of the participants. 42. Section 8.2: Bullet 2 contains a forbidden character, which is not=20 within the lower 7 bit range of ascii. 43. Section 8.2: Last paragraph: Offer/Answer defines its reject=20 procedure based on the external signalling protocol (SIP). So avoid=20 using reject, by setting a certain value. It can signal or indicate, but=20 reject is really something that affects the whole session. Also I think=20 that one can avoid having spldesc to result in rejected setup in most=20 cases. 44. Section 10. "These types of attack may easily be avoided by using authentication." I think the right thing to avoid these attacks are "integrity protection=20 and source authentication". You need the integrity protection to ensure=20 that nobody can change the content en-route, and source authentication=20 to ensure that the sender really is which he claims to be. In many cases=20 implicit source authentication is sufficient. 45. Section 11.2: Reference 10, is now available as RFC 3711. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue May 18 10:49:43 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20378 for ; Tue, 18 May 2004 10:49:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5mo-0005Kr-Cf for avt-archive@odin.ietf.org; Tue, 18 May 2004 10:41:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IEfgbJ020504 for avt-archive@odin.ietf.org; Tue, 18 May 2004 10:41:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5Zb-0000aI-3d; Tue, 18 May 2004 10:28:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5V0-0007TP-SV for avt@optimus.ietf.org; Tue, 18 May 2004 10:23:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17635 for ; Tue, 18 May 2004 10:23:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ5Uy-0001EC-IJ for avt@ietf.org; Tue, 18 May 2004 10:23:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ5U2-0000qH-00 for avt@ietf.org; Tue, 18 May 2004 10:22:18 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BQ5TR-0000SP-00; Tue, 18 May 2004 10:21:41 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i4IELeAh022890; Tue, 18 May 2004 16:21:40 +0200 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 May 2004 16:21:40 +0200 Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.60]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LFSY489V; Tue, 18 May 2004 16:22:16 +0200 Message-ID: <40AA1BF4.2000908@ericsson.com> Date: Tue, 18 May 2004 16:21:40 +0200 X-Sybari-Trust: 5a5e7d8b 08d63d2e 06b283dd 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: IETF AVT WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 May 2004 14:21:40.0449 (UTC) FILETIME=[6FD1F510:01C43CE3] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [AVT] Soliciting comments on Offer/Answer procedures Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Any reply to this mail should be directed to the AVT mailing list. The mail is BCC to MMUSIC, SIP and SIPPING to avoid cross postings. In the RTP payload format for the H.264/AVC video codec, we authors had to write a rather special procedure in the offer/answer. This procedure is there to make the distribution of the video codecs parameter sets work. However we would like to have further review from people knowing SIP and Offer/Answer thoroughly, to ensure that we have not created any problems. Therefore I would be very thankful if you could take a look at: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-h264-06.txt and review the Offer/Answer consideration section (8.2). I wouldn't expect that you will need to read more than some further parts of section 8, and possibly some of the introduction in section 1 for background information. Any comments is desired within two weeks, i.e. before 9th of June. Thanks Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue May 18 12:46:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26702 for ; Tue, 18 May 2004 12:46:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ7aN-0007MF-QT for avt-archive@odin.ietf.org; Tue, 18 May 2004 12:36:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IGax4C028283 for avt-archive@odin.ietf.org; Tue, 18 May 2004 12:36:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ7Se-0004Fq-WF; Tue, 18 May 2004 12:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ79J-0006jn-4h for avt@optimus.ietf.org; Tue, 18 May 2004 12:09:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24858 for ; Tue, 18 May 2004 12:08:58 -0400 (EDT) From: sassan.ahmadi@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ79H-0004AI-RL for avt@ietf.org; Tue, 18 May 2004 12:08:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ78M-00048A-00 for avt@ietf.org; Tue, 18 May 2004 12:08:03 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BQ77V-000464-00 for avt@ietf.org; Tue, 18 May 2004 12:07:23 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4IG72B14034; Tue, 18 May 2004 19:07:03 +0300 (EET DST) X-Scanned: Tue, 18 May 2004 19:06:57 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i4IG6v23020081; Tue, 18 May 2004 19:06:57 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00W73Knz; Tue, 18 May 2004 19:06:56 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4IG6sH26543; Tue, 18 May 2004 19:06:54 +0300 (EET DST) Received: from sdebe002.NOE.Nokia.com ([172.19.201.138]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 18 May 2004 11:06:23 -0500 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] Re: draft-ahmadi-avt-rtp-vmr-wb-01.txt Date: Tue, 18 May 2004 09:06:23 -0700 Message-ID: <0B08EA1BF5F6304992CDC985EE02209E023429AF@sdebe002.americas.nokia.com> Thread-Topic: [AVT] Re: draft-ahmadi-avt-rtp-vmr-wb-01.txt thread-index: AcQ4SEJLn0bbomU+TDC6bbODYggyFwD3ZBPA To: Cc: , X-OriginalArrivalTime: 18 May 2004 16:06:23.0917 (UTC) FILETIME=[110F15D0:01C43CF2] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Colin, Thanks for your good comment.=20 Based on your recent comment, I revised the VMR-WB Internet Draft and = included a section on "Offer-Answer Model Considerations" similar to = that of AMR-WB+ draft (see Section 10.3) and also updated Section 12. To maintain interoperability with AMR-WB in cases where negotiation is = possible using the VMR-WB interoperable mode, a VMR-WB enabled terminal = SHOULD also declare itself capable of AMR-WB with limited mode set = (i.e., only AMR-WB codec modes 0, 1, and 2 are allowed) and octet-align = mode of operation. Example: =20 m=3Daudio 49120 RTP/AVP 98 99 a=3Drtpmap:98 VMR-WB/16000/1 a=3Drtpmap:99 AMR-WB/16000/1 a=3Dfmtp:99 octet-align=3D1; mode-set=3D0,1,2 I hope this new addition would satisfy your concern and eliminate any = signaling conflicts. I have already posted version -02 of VMR-WB payload = on IETF server (draft-ahmadi-avt-rtp-vmr-wb-02.txt) Once again, I would like to kindly ask the IETF/AVT group to adopt this = version of VMR-WB Internet Draft as a working group work item. Thanks in advance. Regards -Sassan Ahmadi >=20 > This is certainly greatly improved, however it does not=20 > address my concern=20 > with respect to the signaling of AMR-WB compatible modes. I=20 > would suggest=20 > you study the Offer-Answer Model Considerations for the=20 > AMR-WB+ payload=20 > format (draft-sjoberg-avt-rtp-amrwbplus-01.txt) and follow a=20 > similar model=20 > for interoperability (i.e. require a VMR-WB capable endpoint=20 > to advertise=20 > support for the AMR-WB payload format, in addition to native=20 > VMR-WB, as an=20 > way of avoiding interoperability problems). >=20 > With that change made, I believe this would be appropriate to=20 > accept as an=20 > AVT work item (provided there are no other objections from the list). >=20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue May 18 17:16:57 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19475 for ; Tue, 18 May 2004 17:16:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQBpX-00019g-T5 for avt-archive@odin.ietf.org; Tue, 18 May 2004 17:08:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IL8tPI004419 for avt-archive@odin.ietf.org; Tue, 18 May 2004 17:08:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQBZf-0004bI-JT; Tue, 18 May 2004 16:52:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQBLK-0006OW-00 for avt@optimus.ietf.org; Tue, 18 May 2004 16:37:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15402 for ; Tue, 18 May 2004 16:37:39 -0400 (EDT) From: shootnet@free.fr Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQBLI-0000l1-3D for avt@ietf.org; Tue, 18 May 2004 16:37:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQBJS-0000Tu-00 for avt@ietf.org; Tue, 18 May 2004 16:35:48 -0400 Received: from postfix4-1.free.fr ([213.228.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BQBHC-00006U-00 for avt@ietf.org; Tue, 18 May 2004 16:33:26 -0400 Received: from imp3-q.free.fr (imp3-q.free.fr [212.27.42.3]) by postfix4-1.free.fr (Postfix) with ESMTP id 2BB9911A953 for ; Tue, 18 May 2004 22:33:25 +0200 (CEST) Received: by imp3-q.free.fr (Postfix, from userid 33) id 223BB1DAFD; Tue, 18 May 2004 22:33:25 +0200 (MEST) Received: from charlebourg-6-81-56-41-97.fbx.proxad.net (charlebourg-6-81-56-41-97.fbx.proxad.net [81.56.41.97]) by imp3-q.free.fr (IMP) with HTTP for ; Tue, 18 May 2004 22:33:25 +0200 Message-ID: <1084912405.40aa73151208e@imp3-q.free.fr> Date: Tue, 18 May 2004 22:33:25 +0200 To: avt@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [AVT] RTP Vorbis Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, i'm actually working on an application that streams vorbis audio data using RTP. But, after asking some persons that know the subject, i found that there were some problems with headers and codebooks transmis= sion. There are compromises that we can accept like transmitting headers and codebooks either directly in the same rtp channel than vorbis, or with an TCP reliable transmission in parallel. Problems that are, for the moment, too long to resolve for me, because = i have work on my application until the 11th of june. That's why, i wanted to know if somebody knows if there was an implemen= tation (possibly simple one) of rtp vorbis that i could use for my work. Not the java one. I've already heard of it. I'm looking for a C impleme= ntation ( don't care if RTCP is implemented ). With it, i could just send packe= ts network and test transmission's reliability. Thx for any response. Yannick Limballe. yannick.limballe@etu.upmc.fr _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed May 19 05:53:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26058 for ; Wed, 19 May 2004 05:53:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNfm-0007DY-M5 for avt-archive@odin.ietf.org; Wed, 19 May 2004 05:47:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4J9lc4n027672 for avt-archive@odin.ietf.org; Wed, 19 May 2004 05:47:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQN9F-00089N-Og; Wed, 19 May 2004 05:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ72r-0004kU-2n for avt@optimus.ietf.org; Tue, 18 May 2004 12:02:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24670 for ; Tue, 18 May 2004 12:02:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ72p-0003qU-O3 for avt@ietf.org; Tue, 18 May 2004 12:02:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ71s-0003mg-00 for avt@ietf.org; Tue, 18 May 2004 12:01:20 -0400 Received: from postfix4-2.free.fr ([213.228.0.176]) by ietf-mx with esmtp (Exim 4.12) id 1BQ714-0003iq-00 for avt@ietf.org; Tue, 18 May 2004 12:00:30 -0400 Received: from ShootNet.free.fr (charlebourg-6-81-56-41-97.fbx.proxad.net [81.56.41.97]) by postfix4-2.free.fr (Postfix) with ESMTP id 7B069106EF9 for ; Tue, 18 May 2004 18:00:30 +0200 (CEST) Message-Id: <6.0.0.22.0.20040518180525.0238d7d8@pop.free.fr> X-Sender: shootnet@pop.free.fr (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 18 May 2004 18:07:35 +0200 To: avt@ietf.org From: ShootNet Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [AVT] rtp vorbis - implementation Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi, i'm actually working on an applications that streams vorbis inside rtp packets. I wanted to know if somebody here, or somewhere, could redirect me or give me an implementation corresponding to the draft about rtp vorbis made by phil kerr. If you could help me on this point, it will be nice. scottie. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed May 19 06:17:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28009 for ; Wed, 19 May 2004 06:17:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNwy-0003YP-S5 for avt-archive@odin.ietf.org; Wed, 19 May 2004 06:05:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JA5OIG013661 for avt-archive@odin.ietf.org; Wed, 19 May 2004 06:05:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNqq-00024e-9T; Wed, 19 May 2004 05:59:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNfG-00077d-3R for avt@optimus.ietf.org; Wed, 19 May 2004 05:47:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25528 for ; Wed, 19 May 2004 05:47:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQNfC-00062W-1V for avt@ietf.org; Wed, 19 May 2004 05:47:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQNe5-0005oy-00 for avt@ietf.org; Wed, 19 May 2004 05:45:54 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1BQNd5-0005Ul-00 for avt@ietf.org; Wed, 19 May 2004 05:44:51 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63643 helo=[192.168.0.3]) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:RC4-MD5:128) (Exim 4.04) id 1BQNcb-0005TQ-00 for avt@ietf.org; Wed, 19 May 2004 10:44:21 +0100 From: Colin Perkins Organization: http://csperkins.org Date: Wed, 19 May 2004 10:44:25 +0100 User-Agent: KMail/1.6.2 To: avt@ietf.org MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200405191044.26004.csp@csperkins.org> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [AVT] Fwd: Protocol Action: 'RTP: A Transport Protocol for Real-Time Applications' to Full Standard Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'm pleased to note that the IESG recently approved the RTP specification and A/V profile as Full Standard RFCs. There are no changes compared with the Draft Standard version, so the RFC numbers will not change. Colin ---------- Forwarded Message ---------- Subject: Protocol Action: 'RTP: A Transport Protocol for Real-Time Applications' to Full Standard Date: Monday 17 May 2004 20:35 From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , avt mailing list , avt chair , avt chair The IESG has approved the following documents: - 'RTP: A Transport Protocol for Real-Time Applications ' RFC 3550 as a Full Standard - 'RTP Profile for Audio and Video Conferences with Minimal Control ' RFC 3551 as a Full Standard These documents are products of the Audio/Video Transport Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary RFC 3550 describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. RFC 3551 describes the Audio-Video Profile of RTP, "RTP/AVP", providing interpretations of generic fields within the RTP specification suitable for audio and video conferences with minimal control. It defines a set of default mappings from payload type numbers to encodings, pointers to reference implementations and standards, and registrations of mediatypes. Working Group Summary The Working Group whole-heartedly supported RTP's advancement to Full Standard as soon as it had spent the minimum period in Draft Standard. Protocol Quality RTP is a mature protocol. There are dozens of full implementations. The implementation report for Draft Standard was assessed to be very complete. The determination of RTP going to Full Standard was evaluated by Allison Mankin for the IESG. There were several messages for support for this in response to the IETF Last Call, and no negative messages. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed May 19 06:43:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26059 for ; Wed, 19 May 2004 05:53:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNfm-0007Dn-RY for avt-archive@odin.ietf.org; Wed, 19 May 2004 05:47:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4J9lca5027752 for avt-archive@odin.ietf.org; Wed, 19 May 2004 05:47:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQN9G-00089Y-Jk; Wed, 19 May 2004 05:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQM8z-0008LT-41 for avt@optimus.ietf.org; Wed, 19 May 2004 04:09:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20543 for ; Wed, 19 May 2004 04:09:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQM8w-0006nh-Gg for avt@ietf.org; Wed, 19 May 2004 04:09:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQM81-0006ft-00 for avt@ietf.org; Wed, 19 May 2004 04:08:42 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BQM7S-0006XO-00 for avt@ietf.org; Wed, 19 May 2004 04:08:06 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i4J87aLc016935 for ; Wed, 19 May 2004 03:07:36 -0500 (CDT) Received: from ericsson.com (rvi2-93-21.sw.ericsson.se [153.88.93.21]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LHB7Q2BN; Wed, 19 May 2004 03:07:36 -0500 Message-ID: <40AB15C8.3090100@ericsson.com> Date: Wed, 19 May 2004 11:07:36 +0300 X-Sybari-Trust: 2bcbbc54 08d63d2e e66bfce3 00000138 From: Gonzalo Camarillo