Subject: [rohc] a question about RTP timestamp SN-function

From: Hani Hu <[email-masked]>
Date: Mon, 16 Sep 2002 03:40:42 -0700 (PDT)

Dear Lars-Erik,
I would like to thank you a lot for your useful answers. It was really kind of you to answer my questions. But the question, which is still unsolved for me, is my last question. I know that TS field is coded by the schemes given in sections 4.5.1, 4.5.3, and 4.5.4 (I mean TS scale coding and …). But by these schemes we still need some bits for sending TS scaled, these schemes just reduce the needed bits for RTP TS field and do not omit them, although in RFC we have some packet types that do not have any available bit for RTP TS! I think the point that I should distinguish is the SN_function, which relates RTP TS or its scaled version with SN, and I would be grateful if you help me with this point.
Thank you a lot,
Regards,
Hani 
 "Lars-Erik Jonsson (EAB)" wrote: Hani,

> 4: How can we relate the RTP timestamp field with RTP Sequence
> Number (for example for a video session)?!! In the document, it
> has been mentioned that timestamp could be related to the SN by
> a function. We have also some compressed packet formats which
> do not send RTP timestamps at all but really I don't have any
> idea about such functions and I would be thankful if anybody
> guides me to the point.

How the RTP TS is encoded is defined in section 5.7, page 75. 
The actual encoding schemes used are described in sections 4.5.1,
4.5.3, and 4.5.4, and referred to by section 5.7. See also section
5.7.7.6.

Cheers,
/L-E

---------------------------------
Do you Yahoo!?
Yahoo! News - Today's headlines

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Tue, 24 Sep 2002 09:43:11 +0200

Hani,

The first paragraph of section 4.5.3 explains the rationale behind scaled TS encoding. While the SN increases with 1 for each packet
sent, the paragraph observes that for TS "the increase is normally
an integral multiple of some unit (TS_STRIDE)". Section 4.5.3
further explains how to communicate TS by establishing TS_OFFSET
and TS_STRIDE, and transmit TS_SCALED in compressed headers. If
TS_SCALED has changed with the same amount as the SN (comparing
the current packet with the context reference(s)) no bits will have
to be sent for TS_SCALED. In those optimal (normal) cases, the
compressed header types without TS bits can be used.

Similarly, no IP-ID bits will be sent when IP-ID can be
reconstructed based on the SN (refer to section 4.5.5).

BR
/Lars-Erik

-----Original Message-----
From: Hani Hu [mailto:[email-masked]]
Sent: den 16 september 2002 12:41
To: Lars-Erik Jonsson (EAB); [email-masked]
Subject: a question about RTP timestamp SN-function

> Dear Lars-Erik, 
> I would like to thank you a lot for your useful answers. It
> was really kind of you to answer my questions. But the question,
> which is still unsolved for me, is my last question. I know that
> TS field is coded by the schemes given in sections 4.5.1, 4.5.3,
> and 4.5.4 (I mean TS scale coding and ...). But by these schemes
> we still need some bits for sending TS scaled, these schemes just
> reduce the needed bits for RTP TS field and do not omit them,
> although in RFC we have some packet types that do not have any
> available bit for RTP TS! I think the point that I should
> distinguish is the SN_function, which relates RTP TS or its
> scaled version with SN, and I would be grateful if you help me
> with this point. 
>
> Thank you a lot, 
>
> Regards, 
> Hani 
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc