Subject: [rohc] packet traces availability?

From: "Smith, Stephen" <[email-masked]>
Date: Tue, 3 Feb 2009 11:24:06 -0600

All,

Sorry for spamming the list, but I have seen several references (for example, the 2001 bake off slides) to the availability of ROHC packet traces to aid in testing.  Does anyone have any information?  I googled through this list, didn't see anything offhand, but could have missed it.

If none are available, what is the general consensus on interop testing during development?

Any help would be appreciated.

Thanks,
Stephen

_______________________________________________
Rohc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rohc

Date: Wed, 04 Feb 2009 10:23:30 +0530
From: Sarkar Biplab <[email-masked]>
To: "Smith, Stephen" <[email-masked]>
OpenPGP: url=http://pgp.mit.edu:11371/pks/lookup?search=0x6D543EEE&op=index
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [rohc] packet traces availability?

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig150B9F327B885289727A4D01
Content-Type: multipart/alternative;
 boundary="------------040501000307040505040003"

This is a multi-part message in MIME format.
--------------040501000307040505040003
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello Stephen,

A stateless packet tracer can understand but not distinguish all the
ROHC packets. There are some proprietary implementations of the same.
But I haven't seen an open source implementation yet.

Thanks
Biplab

Smith, Stephen wrote:
> All,
>
> Sorry for spamming the list, but I have seen several references (for ex=
ample, the 2001 bake off slides) to the availability of ROHC packet trace=
s to aid in testing.  Does anyone have any information?  I googled throug=
h this list, didn't see anything offhand, but could have missed it.
>
> If none are available, what is the general consensus on interop testing=
 during development?
>
> Any help would be appreciated.
>
> Thanks,
> Stephen
>
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rohc
>  =20

--------------040501000307040505040003
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content=3D"text/html;charset=3DISO-8859-1" http-equiv=3D"Content-=
Type">
</head>
<body bgcolor=3D"#ffffff" text=3D"#000066">
Hello Stephen,<br>
<br>
A stateless packet tracer can understand but not distinguish all the
ROHC packets. There are some proprietary implementations of the same.
But I haven't seen an open source implementation yet.<br>
<br>
Thanks<br>
Biplab<br>
<br>
<br>
Smith, Stephen wrote:
<blockquote
 cite=3D"mid:[email-masked]"
 type=3D"cite">
  <pre wrap=3D"">All,

Sorry for spamming the list, but I have seen several references (for exam=
ple, the 2001 bake off slides) to the availability of ROHC packet traces =
to aid in testing.  Does anyone have any information?  I googled through =
this list, didn't see anything offhand, but could have missed it.

If none are available, what is the general consensus on interop testing d=
uring development?

Any help would be appreciated.

Thanks,
Stephen

_______________________________________________
Rohc mailing list
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:[email-masked]">Rohc@=
ietf.org</a>
<a class=3D"moz-txt-link-freetext" href=3D"https://www.ietf.org/mailman/l=
istinfo/rohc">https://www.ietf.org/mailman/listinfo/rohc</a>
  </pre>
</blockquote>
<br>
</body>
</html>

--------------040501000307040505040003--

--------------enig150B9F327B885289727A4D01
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig150B9F327B885289727A4D01--

Date: Wed, 4 Feb 2009 18:40:03 +0530
From: pradeep shambhu <[email-masked]>
To: [email-masked]
Subject: [rohc] Two-way matching operation in ROHC-FN(4887)

--0015175cdeb2801975046217813f
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

What is two way matching process in ROHC-FN & in what way it is similar to
unification process?

With Regards,
Pradeep Shambhu
Kyocera Wireless India
9986484414

On Wed, Feb 4, 2009 at 1:30 AM, <[email-masked]> wrote:

> Send Rohc mailing list submissions to
>        [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://www.ietf.org/mailman/listinfo/rohc
> or, via email, send a message with subject or body 'help' to
>        [email-masked]
>
> You can reach the person managing the list at
>        [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Rohc digest..."
>
>
> Today's Topics:
>
>   1. packet traces availability? (Smith, Stephen)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 3 Feb 2009 11:24:06 -0600
> From: "Smith, Stephen" <[email-masked]>
> Subject: [rohc] packet traces availability?
> To: "[email-masked]" <[email-masked]>
> Message-ID:
>        <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
>
> All,
>
> Sorry for spamming the list, but I have seen several references (for
> example, the 2001 bake off slides) to the availability of ROHC packet traces
> to aid in testing.  Does anyone have any information?  I googled through
> this list, didn't see anything offhand, but could have missed it.
>
> If none are available, what is the general consensus on interop testing
> during development?
>
> Any help would be appreciated.
>
> Thanks,
> Stephen
>
>
>
> ------------------------------
>
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rohc
>
>
> End of Rohc Digest, Vol 58, Issue 2
> ***********************************
>

--0015175cdeb2801975046217813f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

What is two way matching process in ROHC-FN &amp; in what way it is similar=
 to unification process?<br><br><br><br clear=3D"all">With Regards,<br>Prad=
eep Shambhu<br>Kyocera Wireless India<br>9986484414<br><br>
<br><br><div class=3D"gmail_quote">On Wed, Feb 4, 2009 at 1:30 AM,  <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]=
rg</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"bord=
er-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-l=
eft: 1ex;">
Send Rohc mailing list submissions to<br>
 &nbsp; &nbsp; &nbsp; &nbsp;<a href=3D"mailto:[email-masked]">[email-masked]<=
/a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
 &nbsp; &nbsp; &nbsp; &nbsp;<a href=3D"https://www.ietf.org/mailman/listinf=
o/rohc" target=3D"_blank">https://www.ietf.org/mailman/listinfo/rohc</a><br=
or, via email, send a message with subject or body &#39;help&#39; to<br>
 &nbsp; &nbsp; &nbsp; &nbsp;<a href=3D"mailto:[email-masked]">rohc-r=
[email-masked]</a><br>
<br>
You can reach the person managing the list at<br>
 &nbsp; &nbsp; &nbsp; &nbsp;<a href=3D"mailto:[email-masked]">rohc-own=
[email-masked]</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than &quot;Re: Contents of Rohc digest...&quot;<br>
<br>
<br>
Today&#39;s Topics:<br>
<br>
 &nbsp; 1. packet traces availability? (Smith, Stephen)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 3 Feb 2009 11:24:06 -0600<br>
From: &quot;Smith, Stephen&quot; &lt;<a href=3D"mailto:[email-masked]">smsm=
[email-masked]</a>&gt;<br>
Subject: [rohc] packet traces availability?<br>
To: &quot;<a href=3D"mailto:[email-masked]">[email-masked]</a>&quot; &lt;<a h=
ref=3D"mailto:[email-masked]">[email-masked]</a>&gt;<br>
Message-ID:<br>
 &nbsp; &nbsp; &nbsp; &nbsp;&lt;<a href=3D"mailto:23D0CDE7C386D144A4F26EB0F=
[email-masked]">23D0CDE7C386D144A4F26EB0F427F8C021EC808A=
@dlee04.ent.ti.com</a>&gt;<br>
Content-Type: text/plain; charset=3D&quot;us-ascii&quot;<br>
<br>
All,<br>
<br>
Sorry for spamming the list, but I have seen several references (for exampl=
e, the 2001 bake off slides) to the availability of ROHC packet traces to a=
id in testing. &nbsp;Does anyone have any information? &nbsp;I googled thro=
ugh this list, didn&#39;t see anything offhand, but could have missed it.<b=
r>

<br>
If none are available, what is the general consensus on interop testing dur=
ing development?<br>
<br>
Any help would be appreciated.<br>
<br>
Thanks,<br>
Stephen<br>
<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
Rohc mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/rohc" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/rohc</a><br>
<br>
<br>
End of Rohc Digest, Vol 58, Issue 2<br>
***********************************<br>
</blockquote></div><br>

--0015175cdeb2801975046217813f--

Date: Thu, 26 Feb 2009 11:41:27 +0800
From: Mihir Mehta <[email-masked]>
To: [email-masked]
Subject: [rohc] Calculating TS_Stride value

--001636e1fd018720f40463ca20d4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Dear All,

Could anyone help me to know how to calculate the TS_Stride value by looking
at the RTP TS field.

In most cases, it is assumed to be 160 assuming that the audio sampling rate
is 8khz and and 1 voice frame 'may' cover 20ms. There could be a possibility
that the voice frame may cover less than 20ms. In that case what would be
the best way to calculate the TS_Stride value?

Further,assuming that the sampling rate is also unknown, in that case how
can one caculate the TS_Stride value?

Could someone kindly help me?

Thanks in advance
Mihir

--001636e1fd018720f40463ca20d4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Dear All,<div><br></div><div><br></div><div>Could anyone help me to know ho=
w to calculate the TS_Stride value by looking at the RTP TS field.</div><di=
v><br></div><div>In most cases, it is assumed to be 160 assuming that the a=
udio sampling rate is 8khz and and 1 voice frame &#39;may&#39; cover 20ms. =
There could be a possibility that the voice frame may cover less than 20ms.=
 In that case what would be the best way to calculate the TS_Stride value?<=
/div>
<div><br></div><div>Further,assuming that the sampling rate is also unknown=
, in that case how can one caculate the TS_Stride value?</div><div><br></di=
v><div>Could someone kindly help me?</div><div><br></div><div>Thanks in adv=
ance</div>
<div>Mihir</div>

--001636e1fd018720f40463ca20d4--

From: "Chaitanya Pradeep" <[email-masked]>
To: <[email-masked]>
Date: Thu, 26 Feb 2009 18:37:05 +0530
Importance: High
Subject: [rohc] Query regarding V2 Profile Classification (Profile 0x104)
Reply-To: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0006_01C99841.3992FBC0
Content-Type: text/plain;
	charset="iso-8859-1"
content-transfer-encoding: 7bit

Dear RoHC ers,

     I am facing ambiguity regarding (Profile 0x104) classification in RoHC
V2 Profiles.

     1. On what basis we will choose Profile 0x104 in Version-2 Profiles?

         Because, as mentioned in RFC 5225, all the Profiles present
         in Rohc Version-2 support arbitrary number of IP Levels. So how do
we differentiate between Profile0x104 and
         rest of Profiles (i.e, like Profile0x101 , Profile0x102 ,
Profile0x103 etc) in V2 to classify which Profile the
         Packet stream belongs to?

     2. Is the interpretation correct?

          a) Profile 0x104 is chosen when the Input packet contains only IP
headers and not ended by any RTP/UDP/ESP/TCP headers. (or)
          b) Profile 0x104 is chosen only when no other V2 profile is
supported by the compressor entity other than Profile 0x104.

  Pls share your valuble thoughts regarding the same.

Thanks,
Pradeep.

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it.

------=_NextPart_000_0006_01C99841.3992FBC0
Content-Type: text/html;
	charset="iso-8859-1"
content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-8859-1=
">

<META content=3D"MSHTML 6.00.2800.1528" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D883285312-26022009>Dear RoHC=
 
ers,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009>&nbsp;&nbsp;&nbsp;&nbsp; I am facing ambiguity 
regarding (Profile 0x104)&nbsp;classification in RoHC V2 
Profiles.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009>&nbsp;&nbsp;&nbsp;&nbsp; 1. On what basis we will=
 
choose Profile 0x104&nbsp;in Version-2 Profiles?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
&nbsp;Because, as&nbsp;mentioned in RFC 5225,&nbsp;all the Profiles present=
 
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 in 
Rohc Version-2 support arbitrary number of IP Levels. So how do we different=
iate 
between Profile0x104 and </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 rest 
of Profiles (i.e, like Profile0x101 , Profile0x102 , Profile0x103 etc) in V2=
 to 
classify which Profile the</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D883285312-26022009>&nbsp; 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Packet stream belongs 
to?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.&nbsp;Is the 
interpretation correct?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;a) 
Profile 0x104 is chosen when the Input packet contains only IP headers and n=
ot 
ended by any RTP/UDP/ESP/TCP headers. (or)</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D883285312-26022009>&nbsp; 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b) Profile 0x104 is chosen only 
when&nbsp;no other V2 profile is supported by the compressor entity other th=
an 
Profile 0x104.&nbsp;</SPAN></FONT><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D883285312-26022009>&nbsp; 
Pls&nbsp;share your valuble thoughts regarding the same.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009>Thanks,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009>Pradeep.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN 
class=3D883285312-26022009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D883285312-26022009>&nbsp;&nbs=
p;&nbsp; 
</SPAN></FONT></DIV><p>The information contained in this electronic message=
 and any attachments to this message are intended for the exclusive use of t=
he addressee(s) and may contain proprietary, confidential or privileged info=
rmation. If you are not the intended recipient, you should not disseminate,=
 distribute or copy this e-mail. Please notify the sender immediately and de=
stroy all copies of this message and any attachments contained in it.</p>
</BODY></HTML>

------=_NextPart_000_0006_01C99841.3992FBC0--

Date: Thu, 26 Feb 2009 07:13:20 -0800
From: Robert Stangarone <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: [rohc] [Fwd: Query regarding V2 Profile Classification (Profile 0x104)]

This is a multi-part message in MIME format.
--------------080001050801010102000308
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Pradeep,

Re 1):

In the case of the decompressor, the IR packet explicitly binds the 
Context ID to a Profile and Context, and that is how the ROHC 
decompressor determines which Profile the Packet stream belongs to.

In the case of the compressor, I'd think that any incoming packets that 
matched an available Profile would be compared to the existing 
Context(s) to determine if the packets were related to an existing 
Compressed flow in order to determine what action to take, such as 
creating a new Context, or updating an existing one.

Re 2):

I'd say that you would use Profile 0x0104 as the last choice of your 
ROHC Profiles.

This would allow you to use any other supported Profiles first, and 
benefit from the resulting compression.

Profile 0x0104 would only be used after it was found that none of the 
other non-IP headers were present to be compressed.

Bob

-------- Original Message --------
Subject: 	Query regarding V2 Profile Classification (Profile 0x104)
Date: 	Thu, 26 Feb 2009 18:35:19 +0530
From: 	Chaitanya Pradeep <[email-masked]>
Reply-To: 	[email-masked]
To: 	<[email-masked]>

Dear RoHC ers,

      I am facing ambiguity regarding (Profile 0x104) classification in
RoHC V2 Profiles.

      1. On what basis we will choose Profile 0x104 in Version-2 Profiles?

          Because, as mentioned in RFC 5225, all the Profiles present
          in Rohc Version-2 support arbitrary number of IP Levels. So how
do we differentiate between Profile0x104 and
          rest of Profiles (i.e, like Profile0x101 , Profile0x102 ,
Profile0x103 etc) in V2 to classify which Profile the
          Packet stream belongs to?

      2. Is the interpretation correct?

           a) Profile 0x104 is chosen when the Input packet contains only
IP headers and not ended by any RTP/UDP/ESP/TCP headers. (or)
           b) Profile 0x104 is chosen only when no other V2 profile is
supported by the compressor entity other than Profile 0x104.

   Pls share your valuble thoughts regarding the same.

Thanks,
Pradeep.

The information contained in this electronic message and any attachments
to this message are intended for the exclusive use of the addressee(s)
and may contain proprietary, confidential or privileged information. If
you are not the intended recipient, you should not disseminate,
distribute or copy this e-mail. Please notify the sender immediately and
destroy all copies of this message and any attachments contained in it.

--------------080001050801010102000308
Content-Type: text/plain;
 name="Attached Message Part"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Attached Message Part"

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

--------------080001050801010102000308--

Date: Fri, 27 Feb 2009 15:40:28 +0530
From: Sarkar Biplab <[email-masked]>
To: Mihir Mehta <[email-masked]>
OpenPGP: url=http://pgp.mit.edu:11371/pks/lookup?search=0x6D543EEE&op=index
Cc: [email-masked]
Subject: Re: [rohc] Calculating TS_Stride value

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig0E8C34D0D2761338FCD2B4D3
Content-Type: multipart/alternative;
 boundary="------------080205040305050709080507"

This is a multi-part message in MIME format.
--------------080205040305050709080507
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello Mihir,

You can use  statistical approach to calculate TS_Stride.

Thanks
Biplab

Mihir Mehta wrote:
> Dear All,
>
>
> Could anyone help me to know how to calculate the TS_Stride value by
> looking at the RTP TS field.
>
> In most cases, it is assumed to be 160 assuming that the audio
> sampling rate is 8khz and and 1 voice frame 'may' cover 20ms. There
> could be a possibility that the voice frame may cover less than 20ms.
> In that case what would be the best way to calculate the TS_Stride valu=
e?
>
> Further,assuming that the sampling rate is also unknown, in that case
> how can one caculate the TS_Stride value?
>
> Could someone kindly help me?
>
> Thanks in advance
> Mihir
> -----------------------------------------------------------------------=
-
>
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rohc
>  =20

--------------080205040305050709080507
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content=3D"text/html;charset=3DISO-8859-1" http-equiv=3D"Content-=
Type">
</head>
<body bgcolor=3D"#ffffff" text=3D"#000066">
Hello Mihir,<br>
<br>
You can use&nbsp; statistical approach to calculate TS_Stride. <br>
<br>
Thanks<br>
Biplab<br>
<br>
<br>
Mihir Mehta wrote:
<blockquote
 cite=3D"mid:[email-masked]"=

 type=3D"cite">Dear All,
  <div><br>
  </div>
  <div><br>
  </div>
  <div>Could anyone help me to know how to calculate the TS_Stride
value by looking at the RTP TS field.</div>
  <div><br>
  </div>
  <div>In most cases, it is assumed to be 160 assuming that the audio
sampling rate is 8khz and and 1 voice frame 'may' cover 20ms. There
could be a possibility that the voice frame may cover less than 20ms.
In that case what would be the best way to calculate the TS_Stride
value?</div>
  <div><br>
  </div>
  <div>Further,assuming that the sampling rate is also unknown, in that
case how can one caculate the TS_Stride value?</div>
  <div><br>
  </div>
  <div>Could someone kindly help me?</div>
  <div><br>
  </div>
  <div>Thanks in advance</div>
  <div>Mihir</div>
  <pre wrap=3D"">
<hr size=3D"4" width=3D"90%">
_______________________________________________
Rohc mailing list
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:[email-masked]">Rohc@=
ietf.org</a>
<a class=3D"moz-txt-link-freetext" href=3D"https://www.ietf.org/mailman/l=
istinfo/rohc">https://www.ietf.org/mailman/listinfo/rohc</a>
  </pre>
</blockquote>
<br>
</body>
</html>

--------------080205040305050709080507--

--------------enig0E8C34D0D2761338FCD2B4D3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig0E8C34D0D2761338FCD2B4D3--