Subject: RE: [rohc] Some questions

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Mon, 2 Sep 2002 09:31:54 +0200

Hani,

> 1: How could we distinguish between RTP/UDP/IP streams and
> UDP/IP streams?? (As there is no protocol fields in UDP header,
> I am wondering how could the compressor decide whether it has
> RTP header after the following UDP header or not!)

The compressor can not know, but will have to use heuristics to
find out. This means, the compressor can initially assume that
an UDP packet stream is UDP/RTP and apply the RTP compression
profile. Since the compression/decompression process is totally
transparent independent of the actual data, RTP compression will
work (correctly decompress), but of course the compression gain
will be "low" for the RTP part. In such cases, the compressor can
decide to switch to UDP compression, as briefly mentioned in
section 5.11.1. This is an established practice, originally
discussed in RFC 2508, section 3.1.

> 2: How could we decide whether we should use large-CID or not?

If one wants to support header compression for more than 15 
packet streams over the same channel, one will have to use
large-CID. This is an implementation decision. RFC 3095 provides
the tools, it is up to an implementer to decide what to use,
depending on the actual environment where ROHC is implemented.

> 3: Which policy we should use to decide about appropriate time
> for mode transitions?

There is no true answer to this question. The standard does not
specify this, and the WG does not have an official opinion in
this matter. Whether mode transitions should be performed, and
in such case to which mode(s) at what point(s) is left open for
implementers to decide. Link characteristics are expected to
influence how the different modes are used, but that does not
affect the standard.

> 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
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Hani Hu <[email-masked]>
Date: Mon, 9 Sep 2002 10:26:46 -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,

Cheers,
/L-E

---------------------------------
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes