Subject: [rohc] ROHC: Header parsing

From: "Jagan S" <[email-masked]>
Date: Sat, 13 Mar 2004 10:57:50 +0530

Hi,

3095 specifies context identification at compressor  by parsing RTP/UDP/IP
header fields.

Yes. We can identify IP header by analyzing :' Version' / 'Length' fields
of IP header.
UDP header by analyzing: 'protocol type' field from IP header

My question is about: How to identify the presence of RTP header ?

Thanks in advance
- Jagan
.............................................................................................................................................................................................................

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "kamal deep singh" <[email-masked]>
Date: Mon, 15 Mar 2004 12:26:34 +0100

hi,

We can discuss that.

I use RTP version field and also I look at the values
where SN field is supposed to be there. If the values are showing sequential
behaviour then it should be SN and header should be RTP.

This can be extended further to check TS. If TS is showing the expected
behaviour of
TS = n*TS_STRIDE + TS_OFFSET (n is an integer and all others constant) then
it should be TS.

Also RTP uses even UDP port numbers according to RFC.

If anybody has another better idea? please tell me.

regards,
Kamal

----- Original Message -----
From: "Jagan S" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, March 13, 2004 6:27 AM
Subject: [rohc] ROHC: Header parsing

> My question is about: How to identify the presence of RTP header ?
............................................................................
............................................................................
.....................................................

---

From: "kamal deep singh" <[email-masked]>
Date: Wed, 24 Mar 2004 22:03:58 +0100

Hi Magnus,

I meant to use mostly the SN behaviour to predict RTP packets as it is the
base of ROHC
compression.

But, I also find the compression ratio to be "most reliable" way of
detecting wrong choice of RTP profile and switching to other ROHC profiles.

Though I feel compression ratio method to be little inefficient if we
consider costly bandwidth.

regards,
Kamal

> Hi Kamal,
>
> I think some of your checks are oversimplifying the behaviour of RTP.
> There are many users of RTP and not all are as well behaved as audio.
>
> First, the TS behaviour you are describing is present for certain media
> types, but not all, one media type that will definitely not follow that
> usage and still be valid RTP usage is text/t140, which encodes
> transmission time for when the packet is sent. As this is normally for
> each keystroke, I can guarantee you that a valid TS_stride will be quite
> impossible to get.
>
> Secondly, the restriction of using RTP on even ports has also been
> removed, and is now only a recommendation. The reason for removing this
> was simply to allow RTP to work across NATs.
>
> Also the Sequence number check is not 100% as network reorder can cause
> this to jump. There are also certain users of RTP that are a bit
> misbehaving and sends RTP packets with out of order RTP sequence
> numbers. If one needs to take into consideration of misbehaving hosts is
> of course a question, however the network reorder is of course a valid
> reason for small scale jumping around of the RTP sequence number.
>
> So in conclusion, I would only recommend that one uses static fields,
> like version number, and the over several packet compression ratio as
> better measurements.
>
> Cheers
>
> Magnus
>
> kamal deep singh wrote:
>
> > hi,
> >
> > We can discuss that.
> >
> >>3095 specifies context identification at compressor  by parsing
> >
> > RTP/UDP/IP
> >
> >>header fields.
> >>
> >>Yes. We can identify IP header by analyzing :' Version' / 'Length'
> >
> > fields
> >
> >>of IP header.
> --
> Magnus Westerlund
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
>
>
> This communication is confidential and intended solely for the
addressee(s). Any unauthorized review, use, disclosure or distribution is
prohibited. If you believe this message has been sent to you in error,
please notify the sender by replying to this transmission and delete the
message without disclosing it. Thank you.
>
> E-mail including attachments is susceptible to data corruption,
interruption, unauthorized amendment, tampering and viruses, and we only
send and receive e-mails on the basis that we are not liable for any such
corruption, interception, amendment, tampering or viruses or any
consequences thereof.

---

From: Simran Suri <[email-masked]>
Date: Wed, 24 Mar 2004 19:04:27 -0600

Hi All,

I had a basic doubt regarding record marking (RFC 3320- Section 4.2.2) 
by SigComp when stream-based transport protocols like TCP are used. This 
section describes the decompression dispatcher behavior upon 
encountering OxFF in the compressed data stream, but it does not say 
anything about the behavior of the compression dispatcher. What action 
does the compression dispatcher take when say it encounters OxFF in the 
compressed data stream? How does it "modify the message" before sending 
it out on the wire so that the remote decompression dispatcher 
understands it (besides adding a '0xFF FF' to signal the end of the 
message)?

Thanks,
Simran

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Mar 2004 08:25:49 +0100

RFC3320 section 4.2.2 says:

4.2.2.  Record Marking

    For a stream-based transport, the dispatcher delimits messages by
    parsing the compressed data stream for instances of 0xFF and taking
    the following actions:

    Occurs in data stream:     Action:

    0xFF 00                    one 0xFF byte in the data stream
    0xFF 01                    same, but the next byte is quoted (could
                               be another 0xFF)
       :                                           :
    0xFF 7F                    same, but the next 127 bytes are quoted
    0xFF 80 to 0xFF FE         (reserved for future standardization)
    0xFF FF                    end of SigComp message

So, a simple compressor could simply replace every 0xFF by 0xFF 0x00.
A more advanced compressor will probably look out for any additional 
0xFF in the stream and use the alternate forms to save escape bytes.

Gruesse, Carsten

---

From: Simran Suri <[email-masked]>
Date: Thu, 25 Mar 2004 19:25:13 -0600

Hi Carsten,
Just a small point : in the passage below, do you mean the 'compressor' 
OR do you mean the 'compression dispatcher'? Also, is the record marking 
performed on the compressed data(which goes into the 'remaining SigComp 
message' field) or is it performed on the whole SigComp message passed 
down to the TCP layer?
Am I missing something here?
Thanks,
Simran

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 26 Mar 2004 09:05:27 +0100

>  Just a small point : in the passage below, do you mean the 
> 'compressor' OR do you mean the 'compression dispatcher'?

The quip answer is: "I don't care".
The text says "dispatcher", but then where you do this has little 
impact on the protocol on the wire.
If you had asked whether the inverse is done in the decompressor (which 
runs in the UDVM) or the decompressor's dispatcher, there would be a 
difference, as in the first case the UDVM code would have to include 
code to handle record unmarking (it doesn't -- the UDVM gets passed 
entire messages, already unmarked).

Generally, we include passages about architecture in protocol standards 
less to structure implementations than to:
-- provide a mental model into which the reader can fit the 
explanations in the specification, and to
-- provide motivation and some general direction for the further 
development of the protocol or related protocols.
Of course, you are free to use the architecture in your implementation.

> Also, is the record marking performed on the compressed data(which 
> goes into the 'remaining SigComp message' field) or is it performed on 
> the whole SigComp message passed down to the TCP layer?

Since the purpose of the record marking is to delimit messages, it is 
applied to entire messages.

(RFC 3320 says so, too:

4.2.2.  Record Marking

    parsing ...
)

Gruesse, Carsten

---

From: Chintan Thakker <[email-masked]>
Date: Fri, 26 Mar 2004 10:20:49 -0600

But the UDVM can say it is an end of a message when it sees END-MESSAGE.

In that case (when the actual message is escaped by the compressor) is a 
0xFF taken as an indication of END-MESSAGE by the decompressor in the UDVM ?

Thanks,

Carsten Bormann wrote:

> If you had asked whether the inverse is done in the decompressor 
> (which runs in the UDVM) or the decompressor's dispatcher, there would 
> be a difference, as in the first case the UDVM code would have to 
> include code to handle record unmarking (it doesn't -- the UDVM gets 
> passed entire messages, already unmarked).
>
> Generally, we include passages about architecture in protocol 
> standards less to structure implementations than to:
>> goes into the 'remaining SigComp message' field) or is it performed 
>> on the whole SigComp message passed down to the TCP layer?
>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 16 Mar 2004 12:36:06 +0100

Hi Kamal,

Cheers

Magnus

-- 

Magnus Westerlund

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.