Re: Question about ROHC configuration
Soyoung Lee <soyounglee <at> lge.com>
2002-09-03 04:23:53 GMT
Dear Lars-Erik and ROHC experts,
Thanks for your comments.
But I still have some curiosity.
Let's assume just a streaming service over ROHC (i.e asymmetric bi-directional communication).
Then, one way(DL) is used for RTP (multimedia data), and of course,the other way(UL) is used for RTCP (RTP
control information).
At this time, I wonder if the number of CIDs should be same for both ways.
Is it possible that 3 CIDs are used for RTP and 1 CID is used for RTCP?
And I think my earlier second question was ambiguous.
You're right. RFC3095 says "ROHC can handle a certain number of concurrent packet streams."
But, what I want to know is that if it's possible a RTP session (for example, Video or multimedia data)
can be divided into several packet streams and these streams are transmitted concurrently.
(I think a "channel" in RFC3095 means a session. Am I right? )
In this case, is there only one RTCP or several RTCPs for each stream?
Thanks in advance.
Best Regards,
SoYoung
===========================
Soyoung Lee
LG Electronics Inc. Korea
e-mail: soyounglee <at> lge.com <mailto:soyounglee <at> lge.com>
phone: +82-31-450-7859
fax: +82-31-450-7912
===========================
-----Original Message-----
From: rohc-admin <at> ietf.org [mailto:rohc-admin <at> ietf.org]
Sent: Friday, August 30, 2002 5:04 PM
To: 'Soyoung Lee'; ROHC
Subject: RE: [rohc] Question about ROHC configuration
Soyoung,
> First, when I configure the ROHC parameters, shoud I always
> configure these parameters in the compressor and decompressor
> the same? That is, the Uplink and Downlink have to be configured
> the same?
First of all, I am not totally sure which parameters you are
talking about. ROHC has a few parameters that must be agreed
between compressor and decompressor. These are the "Per-channel
parameters" listed in RFC3095 section 5.1.1, i.e. MAX_CID,
LARGE_CIDS, PROFILES supported, MRRU, and optionally FEEDBACK_FOR.
How these are configured/negotiated depends on the actual link
technology, where RFC3241 (ROHC-over-PPP) is a good example of
how such a negotiation can be defined.
RFC3095 (section 6.3) also lists a number of parameters suggested
as useful in an interface to a ROHC compressor or decompressor.
It should be noted that these parameters are for configuration
of a ROHC compressor OR decompressor, thus not subject to
negotiation. Remember also that the parameters listed are just
suggestions, an implementation might implement a subset of these,
an extended parameter set, or completely different parameters.
Which parameters that are useful depend of course on the actual
link technology the implementation is supposed to be used in.
Regarding your uplink/downlink question, I think that it is a
different question. RFC3095 does not consider specific link
integration, e.g. wireless links (as in your question).
For RFC3095, bi-directional communication (i.e. the fact that
you have both an "uplink" and a "downlink") has not in principle
affect the standard. RFC3095 defines how to do compression from
a compressor to a decompressor, and thus each direction
corresponds to its own ROHC configuration. In your example,
the downlink configuration is totally independent of the
uplink configuration, from an RFC3095 point of view. However,
this is of course a matter of how ROHC is integrated in the
actual link technology, i.e. in the "ROHC-over-whatever"
standard applicable to your case. Note that the IETF ROHC WG
only defines ROHC-over-PPP, integration into other link
technologies must be addressed in other standard bodies.
> Second, I wonder if it's possible to have several streams
> for one service at the same time.
ROHC can handle a certain number of concurrent packet streams,
depending on how ROHC is configured over the channel, i.e.
whether large or small CID's are used. Small CID allows 16
concurrent streams, while large CID can support up to 16383.
With streams, we mean any packet stream compressed by a
ROHC profile, including "non-compressed" sent with ROHC
profile 0x0000.
Then, as usual, the actual link technology and implementation
restrictions might affect these limits.
Regards.
/Lars-Erik
--------------------------------------
Lars-Erik Jonsson
IETF ROHC WG Chair
E-mail: lars-erik.jonsson <at> ericsson.com
Phone: +46 920 20 21 07
Home: +46 920 999 57
My opinions are my personal opinions and should not be considered
as the opinions of my employer, if not explicitly stated.
_______________________________________________
Rohc mailing list
Rohc <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rohc
RSS Feed