Hani Hu | 1 Sep 20:07 2002
Picon

Some questions

Hello everybody;

I am a graduate student. Currently I have started to read the rfc3095 document. Most probably I am going to implement it as a part of my thesis but I have some basically problems with the document. I would greatly appreciate it if you guys kindly help me regarding the following difficulties.

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!)

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

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

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

Lars-Erik Jonsson (EAB | 2 Sep 09:31 2002
Picon
Picon

RE: Some questions

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
Ana Carolina Minaburo | 2 Sep 15:14 2002
Picon
Picon

Re: Invitation to the 4th ROHC interop: "ROHC in the City"

Hi,

We are working in the IPv6 deployment of ROHC, we have the profile 1 
(IPv6/UDP/RTP) of RFC 3095 over PPPoe implementated (RFC 3241)  for the 
moment, we will want to participate to your interop test event, but we 
want to know if there is another implementation with whom we can interop?

Ana

Stefan Hendrata wrote:

>Dear ROHClers,
>
>please be invited to the 4th ROHC interop test which will take place from
>
>		Wednesday, October 30th, 2002
>	to	Friday, November 8th, 2002
>
>in Berlin, Germany.
>
>The duration of the interop test has been extended due to some concerns that 
>the one week time frame of earlier interops would not be sufficient.
>
>The "ROHC in the City" webpage containing information on this event and
>online registering capability is located at
>
>	http://www.acticom.de/interop.html
>
>Please check it out regularly since we will update it with current
>information.
>
>The ROHC interop test is open to everyone who has a ROHC implementation. We 
>especially want to encourage those who have not gone to a ROHC interop yet to 
>participate and make it a successful event. Those of you who plan to 
>participate at "ROHC in the City" should indicate your interest not later 
>than October 1st in order to guarantee your attendance. It is also a good 
>idea to book hotel rooms as early as possible because there are other events 
>taking place in Berlin at the same time which could make it difficult to get 
>the desired hotel room.
>
>Since this is the fourth ROHC interoperability test of ROHC, focus will be on 
>the more advanced features of ROHC, and on robustness under hard link 
>conditions. However, basic features will also be tested besides these 
>challenging ones. Details on the test contents will be published on the 
>webpage.
>
>Here is a link for touristic information about Berlin:
>
>	http://www.berlin.de/english/index.html
>
>
>With best regards,
>
>Stefan Hendrata
>Frank Fitzek
>Enno Ewers
>Rolf Morich
>Gerrit Schulte
>- acticom GmbH -
>
>_______________________________________________
>Rohc mailing list
>Rohc <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/rohc
>
Soyoung Lee | 3 Sep 06:23 2002

Re: Question about ROHC configuration

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
Sukanta Kumar Hazra | 3 Sep 08:21 2002
Picon

Re: Invitation to the 4th ROHC interop: "ROHC in the City"

Hi!

We are also working on  IPv6/UDP/RTP. However it is over PPP and not
PPPoe. I will have to look into the effort required to add PPPoe
support.

Hope to interop. Will keep you posted.

Regards,
Sukanta

 
On Mon, 2002-09-02 at 21:14, Ana Carolina Minaburo wrote:
> Hi,
> 
> We are working in the IPv6 deployment of ROHC, we have the profile 1 
> (IPv6/UDP/RTP) of RFC 3095 over PPPoe implementated (RFC 3241)  for the 
> moment, we will want to participate to your interop test event, but we 
> want to know if there is another implementation with whom we can interop?
> 
> Ana
> 
> Stefan Hendrata wrote:
> 
> >Dear ROHClers,
> >
> >please be invited to the 4th ROHC interop test which will take place from
> >
> >		Wednesday, October 30th, 2002
> >	to	Friday, November 8th, 2002
> >
> >in Berlin, Germany.
> >
> >The duration of the interop test has been extended due to some concerns that 
> >the one week time frame of earlier interops would not be sufficient.
> >
> >The "ROHC in the City" webpage containing information on this event and
> >online registering capability is located at
> >
> >	http://www.acticom.de/interop.html
> >
> >Please check it out regularly since we will update it with current
> >information.
> >
> >The ROHC interop test is open to everyone who has a ROHC implementation. We 
> >especially want to encourage those who have not gone to a ROHC interop yet to 
> >participate and make it a successful event. Those of you who plan to 
> >participate at "ROHC in the City" should indicate your interest not later 
> >than October 1st in order to guarantee your attendance. It is also a good 
> >idea to book hotel rooms as early as possible because there are other events 
> >taking place in Berlin at the same time which could make it difficult to get 
> >the desired hotel room.
> >
> >Since this is the fourth ROHC interoperability test of ROHC, focus will be on 
> >the more advanced features of ROHC, and on robustness under hard link 
> >conditions. However, basic features will also be tested besides these 
> >challenging ones. Details on the test contents will be published on the 
> >webpage.
> >
> >Here is a link for touristic information about Berlin:
> >
> >	http://www.berlin.de/english/index.html
> >
> >
> >With best regards,
> >
> >Stefan Hendrata
> >Frank Fitzek
> >Enno Ewers
> >Rolf Morich
> >Gerrit Schulte
> >- acticom GmbH -
> >
> >_______________________________________________
> >Rohc mailing list
> >Rohc <at> ietf.org
> >https://www1.ietf.org/mailman/listinfo/rohc
> >
> 
> 
> _______________________________________________
> Rohc mailing list
> Rohc <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
Lars-Erik Jonsson (EAB | 3 Sep 09:55 2002
Picon
Picon

RE: Question about ROHC configuration

SoYoung,

> 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?

The number of CID's IN USE for each direction depends on the number of
concurrent packet streams over the channel in that direction. The CID
SPACE must be large enough to handle the possible number of streams.

A stream for RTP is usually defined as having constant:
- IP source and destination addresses
- UDP ports
- RTP SSRC

How many streams that will be generated for your streaming service
may of course differ. For example, the media combination and the way
the application(s) transmits data affect the number of RTP streams.
Note also that RTCP might be sent by both sender and receiver.

Remember that the number of actual streams matches the number
of CID's in use on each simplex ROHC channel, while the number of
possible CID's is pre-negotiated on the channel, either small (max 16
CID's) or large (max 16383). The former is about current "state" of 
application "connection", while the latter is a bout link capabilities.

> 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.

Sure they can, but that is a matter of application design. If you have
a combination of various media, you will probably have several
concurrent RTP streams.

> (I think a "channel" in RFC3095 means a session. Am I right? )

I do not know what you mean with a session. For ROHC, a channel
is a logical L2 connection on top of which a ROHC instance is
running. That is thus a "link property" and not directly related to 
for example application sessions. 

> In this case, is there only one RTCP or several RTCPs for each stream?

Please refer to RFC 1889 (bis), and direct RTP related questions to
the AVT list.

BR
/Lars-Erik
Hani Hu | 3 Sep 19:27 2002
Picon

ROHC usage

Dear all,

I am wondering where ROHC shows its efficiency better and I would appreciate it if someone could explain me about it.

I mean, in a typical RTP/UDP/IP packet (specially in real time video packets), the header size is not an important part of packet size and its size is much less than total packet size so its compression also could not have an important effect.

I know that it is mentioned in the rfc3095 document(introduction part) that ROHC is useful for mobile IP telephony, but what about video, data, and other services? I think that it should be some other usage, which I am not aware of, and I would greatly appreciate it if somebody helps me about it.

with kind regards,

Hani


Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
Francis Dupont | 4 Sep 10:02 2002
Picon
Picon

Re: Invitation to the 4th ROHC interop: "ROHC in the City"

 In your previous mail you wrote:

   We are also working on  IPv6/UDP/RTP. However it is over PPP and not
   PPPoe.

=> I don't understand your statement "it is over PPP and not PPPoE"
because PPPoE is PPP, only the encapsulation/framing is over Ethernet
and not over a serial line. BTW, do you support synchronous or
asynchronous serial lines?

   I will have to look into the effort required to add PPPoe support.

=> we use the "user mode" PPP for FreeBSD (http://www.Awfulhak.org/ppp.html)
which has support for asynchronous serial lines too. PPPoE was chosen only
because it doesn't need any hardware (no stupid problems to get the right
cable), it is very easy to trace/debug and it uses netgraph.

   Hope to interop. Will keep you posted.

=> if you don't work on a dedicated device you should look at PPPoE
(or PPP over a layer-3 but they are not very standardized) because
it has definitive advantages for interop testing of features in the
higher part of PPP (like ROHC). And PPPoE is heavily used for ADSL
so implementations are very easy to find.

Regards

Francis.Dupont <at> enst-bretagne.fr
Miguel A. Garcia | 4 Sep 10:08 2002
Picon

[Fwd: [Sipping] WGLC for draft-ietf-sipping-sigcomp-sip-dictionary]

Hi:

Although the SIP/SDP dictionary for Sigcomp falls into the SIPPING WG
work items, I believe it may be interesting for folks who are following 
this work to be informed that the document is going to WGLC now.

If you have any concern, please post it to the SIPPING mailing list.

http://www.ietf.org/internet-drafts/draft-ietf-sipping-sigcomp-sip-dictionary-04.txt

/Miguel
-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:Miguel.A.Garcia <at> ericsson.com     Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia <at> piuha.net        Mobile: +358 40 5140002
Picon
From: Rohan Mahy <rohan <at> cisco.com>
Subject: [Sipping] WGLC for draft-ietf-sipping-sigcomp-sip-dictionary
Date: 2002-09-03 18:32:21 GMT
Hi,

I'd like to begin Working Group Last Call for 
draft-ietf-sipping-sigcomp-sip-dictionary-04.txt.  Last call will close 
on Sept 20th

thanks,
-rohan

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP

Yang Chang | 4 Sep 15:04 2002
Picon

IP-ID2 in Profile 1

Dear All,

I am now implementing ROHC and I have a question as following:

In profile 1, if bits(IP-ID2) is not zero, does it mean Extension 3 must be used? Unlike Profile 2 or 3, there
is Extension 2 to hold WLSB encoded IP-ID2; In profile 1, there is only field for IP-ID in base headers and
extension header 0, 1 and 2.

Thank you very much for your help!

Yang Chang

Gmane