Subject: [AVT] jitter+seqno generation 3550

From: "Lakshmi Thampi" <[email-masked]>
Date: Fri, 11 Jan 2008 15:03:28 +0530

Hello 
   In reference to RFC 3550, Appendix A.1 
 
If the RTCP functionality is not used then can we assume that sequence
no is not a valid in RTP header 
 
regards
Lakshmi
SASKEN BUSINESS DISCLAIMER
-------------------------
This message may contain confidential, proprietary or legally privileged information. In 
case you are not the original intended Recipient of the message, you must not, directly or 
indirectly, use, Disclose, distribute, print, or copy any part of this message and you are 
requested to delete it and inform the sender. Any views expressed in this message are 
those of the individual sender unless otherwise stated. Nothing contained in this message 
shall be construed as an offer or acceptance of any offer by Sasken Communication 
Technologies Limited ("Sasken") unless sent with that express intent and with due 
authority of Sasken. Sasken has taken enough precautions to prevent the spread of 
viruses. However the company accepts no liability for any damage caused by any virus 
transmitted by this email
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Greg Herlein" <[email-masked]>
Date: Fri, 11 Jan 2008 07:04:53 -0800

Well, at a minimum it's useful to detect (and correct) out of order
packets.  But, I suppose there's nothing to say you cannot just ignore
it.

Why do so few implementations support RTCP?  It's one of my pet
peeves.  RTCP is well worth adding.  Why not add it?

Greg

On 1/11/08, Lakshmi Thampi <[email-masked]> wrote:
> If the RTCP functionality is not used then can we assume that sequence no is
> not a valid in RTP header
>
> regards
> LakshmiSASKEN BUSINESS DISCLAIMER

---

From: Bob Gilman <[email-masked]>
Date: Fri, 11 Jan 2008 10:02:21 -0700

Knowledge of received sequence numbers is critical for packet loss
concealment algorithms.

It's useful, along with the timestamp, for clock synchronization with
the received stream.

The sequence number is also used, along with the rollover counter, by
SRTP to provide a unique

keystream for each packet and to prevent replay attacks.

-Bob
-------------------------------------------------------------
Bob Gilman [email-masked] 303 898 9780

Greg Herlein wrote:

Greg

Hello

regards
LakshmiSASKEN BUSINESS DISCLAIMER
-------------------------
This message may contain confidential, proprietary or legally privileged
information. In
case you are not the original intended Recipient of the message, you must
not, directly or
indirectly, use, Disclose, distribute, print, or copy any part of this
message and you are
requested to delete it and inform the sender. Any views expressed in this
message are
those of the individual sender unless otherwise stated. Nothing contained in
this message
shall be construed as an offer or acceptance of any offer by Sasken
Communication
Technologies Limited ("Sasken") unless sent with that express intent and
with due
authority of Sasken. Sasken has taken enough precautions to prevent the
spread of
viruses. However the company accepts no liability for any damage caused by
any virus
transmitted by this email

---

From: "Greg Herlein" <[email-masked]>
Date: Fri, 11 Jan 2008 09:16:30 -0800

I've heard that some use SN and TS for clock syncronization, but to be
honest, I've never seen it in the wild.  In the applications I have
seen, the clock sync is not something that really matters all that
much at the RTP layer.  It's something that matters greatly at the
MPEG payload processing layer or at the voice codec processing layer -
but both are lower layers that the RTP code is not able to really
affect.

Of course, this is in the hardware and software stacks that I have
experience with.  I'd love to learn more about applications where
clock sync is actually performed with RTP layer information.

Greg

On 1/11/08, Bob Gilman <[email-masked]> wrote:
>  It's useful, along with the timestamp, for clock synchronization with the
> received stream.
>  The sequence number is also used, along with the rollover counter, by SRTP
> to provide a unique

---

From: Bob Gilman <[email-masked]>
Date: Fri, 11 Jan 2008 11:05:51 -0700

I've seen it used on a media gateway that carried a real-time stream of
"unknown" format that

was sensitive to data loss.  So long as the RTP stream is reliable
(e.g., via redundancy or FEC),

the receiver is able to reproduce the stream exactly without knowing
the encoding rules.

(There's still a matter of delay compared to a real wired circuit, of
course.)  The clock sync is

required to avoid losses/insertions due to jitter buffer
overrun/underrun.  Some of the applications

that can use this type of transport run over ISDN data channels (H.320
framing, end-to-end

encrypted circuits) or over voice channels with modem/FAX encoding.

It's rather remarkable what one can do with a feed-forward scheme, but
feedback of some sort

is necessary to avoid eventual over/underflow (or excessive delay :-))

-Bob

Greg Herlein wrote:

Greg

Greg Herlein wrote:

Greg

Hello

regards

---

From: "Even, Roni" <[email-masked]>
Date: Sat, 12 Jan 2008 00:44:41 +0200

Hi,
First of all RTP +RTCP compose the RTP so if you do not use (send) RTCP  I would not call the implementation RTP compliant. Now if you chose to ignore the received RTCP stream and send only the minimal RTCP information this is OK if you do not have any use for it. Still the other side may want you sender/receiver reports to monitor the RTP session.

Seq no are important to verify that the delivery order is correct.

As for usage of the timing information, this is important in order to synchronize between streams like lip synch for audio and video or for sending multiple layers in a layered codecs using separate RTP sessions.

Other usage of RTCP adding to Bob's are using the RTCP feedback profile for end to end media controls and indications

Roni Even

> -----Original Message-----
> From: Greg Herlein [mailto:[email-masked]]
> Sent: Friday, January 11, 2008 7:17 PM
> To: Bob Gilman
> Cc: [email-masked]
> Subject: Re: [AVT] jitter+seqno generation 3550
> 
> the
> SRTP