Subject: [rohc] FW: New Version Notification for draft-lei-rohc-sigcomp-static-dictionary-01

From: Zhu Lei <[email-masked]>
Date: Wed, 19 Aug 2009 10:44:14 +0800

The individual draft version 01 has been submitted. Please check over. 

Best regards,
Zhu Lei

----------------------------------------------------------------------------
---------------------------------------------------------
This e-mail and its attachments contain confidential information from
HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any
use of the 
information contained herein in any way (including, but not limited to,
total or partial 
disclosure, reproduction, or dissemination) by persons other than the
intended 
recipient(s) is prohibited. If you receive this e-mail in error, please
notify the sender by 
phone or email immediately and delete it!

发件人: IETF I-D Submission Tool [mailto:[email-masked]] 
发送时间: 2009年8月19日 10:38
收件人: [email-masked]
主题: New Version Notification for
draft-lei-rohc-sigcomp-static-dictionary-01

A new version of I-D, draft-lei-rohc-sigcomp-static-dictionary-01.txt has
been successfuly submitted by Lei Zhu and posted to the IETF repository.

Filename:	 draft-lei-rohc-sigcomp-static-dictionary
Revision:	 01
Title:		 Signaling Compression dictionary for SIP
Creation_date:	 2009-08-19
WG ID:		 Independent Submission
Number_of_pages: 17

Abstract:
The SigComp static dictionary for Session Initiation Protocol (SIP)
signalling was done by first version RFC3485.  SIP protocol related
extensions were completed and published in a series IETF documents.
Those SIP protocol extensions had been used in 3GPP IMS and IMS based
applications.  The new extensions to SIP protocol weaken the intention of
static dictionary for SIP signalling compressing which is to reduce overload
risks in radio access network and core network involving wireless network.

The IETF Secretariat.

---

From: "Gurushant" <[email-masked]>
Date: Wed, 19 Aug 2009 14:59:24 +0530

Dear All,

We have one small issue while understanding the following information from
the RTP implementation guidelines. Kind request you clarify on the last
sentence mentioned in below paragraph.
   Section RFC3095-5.7.7.6 defines the static and dynamic parts of the
   RTP header. This section indicates a 'Generic CSRC list' field in the
   dynamic chain, which has a variable length (see section RFC3095-
   5.8.6). This field is always at least one octet in size, even if the
   list is empty (as opposed to the CSRC list in the uncompressed RTP
   header, which is not present when the RTP CC field is set to 0).

If I am correct the last line "as opposed to the CSRC list in the
uncompressed RTP header, which is not present when the RTP CC field is set
to 0" , does it mean that for IR packet , one octet( first byte) of generic
scheme need not present.

Thanks
Gurushant

---

From: Klaus Warnke <[email-masked]>
Date: Wed, 19 Aug 2009 12:24:10 +0200

Gurushant,

> uncompressed RTP header, which is not present when the RTP CC field
> is set to 0" , does it mean that for IR packet , one octet( first
> byte) of generic scheme need not present.

No. If the CC field (CSRC count) in the original RTP header is set to
zero, there is no CSRC item at the end of the original RTP header
present. Then the CC field at the beginning of the RTP IR dynamic part
is also set to zero, but you can not omit the first octet of the
generic CSRC list. Set it simply to 0x00 (ET=0, GP=0, PS=0,
CC=0). That is, what the RFC4815-5.1. says.

I think, that the definition of the "/" means at least of octet
(3095. p 43 (in the diagram, slashes "/" indicate variable length))
where the ":" is defined (p. 42 (in the diagram, colons ":" indicate
that the part is optional)) means it can be omitted. But the generic
CSRC list field is surround by "/".

br
Klaus

At Wed, 19 Aug 2009 14:59:24 +0530,

---

From: "Gurushant" <[email-masked]>
Date: Wed, 19 Aug 2009 16:16:25 +0530

Hi Klaus,
Thanks for the quick reply.
But we are adding one extra byte ( 0x00) unnecessarily when the CC indicates
that there is no CSRC value.
I think everybody who reads RoHC RFC, they understand that "/" means it is
variable, how feasible it to mandate to at least one byte for the "/"
meaning. Specially in this example ,  isn't the understanding differs.

I am wondering, is there any special purpose to add one octet in case
generic CSRC list. I understand in case of Generic Extension Header list one
octet makes sense as there is no previous bytes or information  to indicates
its presence.

Thanks & Best Regards
Gurushant.Kotagi

-----Original Message-----
From: Klaus Warnke [mailto:[email-masked]]
Sent: Wednesday, August 19, 2009 3:54 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [rohc] Generic CSRC List Issue

Gurushant,

br
Klaus

---

From: Klaus Warnke <[email-masked]>
Date: Wed, 19 Aug 2009 13:07:12 +0200

At Wed, 19 Aug 2009 16:16:25 +0530,
> Thanks for the quick reply.

You're welcome.

> But we are adding one extra byte ( 0x00) unnecessarily when the CC
> indicates that there is no CSRC value.

This is true. This wastes on octet. But if you are not wasting this
octet, your RoHC will not able to talk "RTP" with other RoHC stacks.

> I think everybody who reads RoHC RFC, they understand that "/" means
> it is variable, how feasible it to mandate to at least one byte for
> the "/" meaning. Specially in this example , isn't the understanding
> differs.

Yes. But this is the reason why this case is extra clearified in the
rfc4815:

    This field is always at least one octet in size, even if the list
    is empty

This was a try to find a explanation why.

> I am wondering, is there any special purpose to add one octet in
> case generic CSRC list. I understand in case of Generic Extension
> Header list one octet makes sense as there is no previous bytes or
> information to indicates its presence.

Fields, which are variable and optional are looking like:

   +---+--- ---+---+---+--- --- ---+
   :                               :
   /    0, 1, or 2 octets of CID   /  1 or 2 octets if (large CIDs)
   :                               :
   +---+---+---+---+---+---+---+---+

or 

   +---+---+---+---+---+---+---+---+
   :             Size              :  if Code = 0
   +---+---+---+---+---+---+---+---+

That means, if Code == 0, Size is present. But 

      +---+---+---+---+---+---+---+---+
      /      Generic CSRC list        /  variable length
      +---+---+---+---+---+---+---+---+

looks different.

This isssues are one of the reasons to define RoHCv2 not with ascii
boxes and text but with a formal notaion.

br
Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 19 Aug 2009 13:11:43 +0200

> octet, your RoHC will not able to talk "RTP" with other RoHC stacks.

IIRC, this little byte was the first big stumbling stone on the first  
day of the first ROHC interop -- half of the implementations had it  
and the other half didn't.
The decision to always include this byte was made on the afternoon of  
that day, carried forward in all ROHC implementations since, and  
finally recorded in RFC 4815.

Gruesse, Carsten