[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [rohc] Re: multiplexing SigComp and non-SigComp messages on t hesame TCP connection
Keith,
thank you for the information. However, I want to point
out that if the statement about the multiplexing in draft-ietf-rohc-sigcomp-sip-01
is the final one- it will cause unnecessary changes in the implementations
already supporting multiplexing (and will break backwards compatibility).
That's why I think that multiplexing should be allowed without any
extra 'uncompressed SigComp headers".
regards,
paulius
> -----Original Message-----
> From: ext Drage, Keith (Keith) [mailto:drage at lucent.com]
> Sent: Tuesday, December 14, 2004 9:29 PM
> To: Meskauskas Paulius (Nokia-TP-MSW/Helsinki); cabo at tzi.org;
> abigail.surtees at ROKE.CO.UK
> Cc: rohc at ietf.org
> Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp
> messages on
> t hesame TCP connection
>
>
> For information, we ended up with the following text
> (unofficial version - official version of CR still being
> implemented) covering 3GPP IMS compression in 3GPP TS 24.229
> as a result of the latest round of meetings.
>
> Our discussions in 3GPP assumed that the statement regarding
> multiplexing of Sigcomp and non-Sigcomp in
> draft-ietf-rohc-sigcomp-sip-01 to stand.
>
> regards
>
> Keith
>
> 8 SIP compression
>
> 8.1 SIP compression procedures at the UE
>
> 8.1.1 SIP compression
>
> The UE shall support SigComp as specified in RFC 3320 [32].
> When using SigComp the UE shall send compressed SIP messages
> in accordance with RFC 3486 [55]. When the UE will create the
> compartment is implementation specific, but the compartment
> shall not be created until a set of security associations are
> set up. The compartment shall finish when the UE is
> deregistered. State creations and announcements shall be
> allowed only for messages received in a security association.
>
> NOTE: Exchange of bytecodes during registration will prevent
> unnecessary delays during session setup.
>
> Editor's note: The draft-ietf-rohc-sigcomp-sip-01 [79]
> can lead to the need for additional changes or clarifications.
>
> The UE shall support the SIP dictionary specified in RFC 3485
> [42]. If compression is enabled, the UE shall use the
> dictionary to compress the first message.
>
> The following apply when signalling compression is used:
>
> - State Memory Size (SMS) greater than zero is needed to
> give room for the UDVM byte code and make dynamic compression
> possible. A State Memory Size of at least 4096 bytes shall be
> a minimum value; and
>
> - A Decompression Memory Size (DMS) of at least 8192
> bytes should be a minimum value.
>
> 8.1.2 Compression of SIP requests and responses transmitted
> to the P-CSCF
>
> The UE should compress the requests and responses transmitted
> to the P-CSCF according to subclause 8.1.1.
>
> NOTE 1: Compression of SIP messages is an
> implementation option. However, compression is strongly recommended.
>
> NOTE 2: Since compression support is mandatory, the UE
> may send even the first message compressed. Sigcomp provides
> mechanisms to allow the UE to know if state has been created
> in the P-CSCF or not.
>
> 8.1.3 Decompression of SIP requests and responses received
> from the P-CSCF
>
> The UE shall decompress the compressed requests and responses
> received from the P-CSCF according to subclause 8.1.1.
>
> If the UE detects a decompression failure at the P-CSCF, the
> recovery mechanism is implementation specific and this may,
> as an example, include resetting the compartment, changing
> the algorithm.
>
> 8.2 SIP compression procedures at the P-CSCF
>
> 8.2.1 SIP compression
>
> The P-CSCF shall support SigComp as specified in RFC 3320
> [32]. When using SigComp the P-CSCF shall send compressed SIP
> messages in accordance with RFC 3486 [55]. When the P-CSCF
> will create the compartment is implementation specific, but
> the compartment shall not be created until a set of security
> associations are set up. The compartment shall finish when
> the UE is deregistered. State creations and announcements
> shall be allowed only for messages received in a security association.
>
> The P-CSCF shall support the SIP dictionary specified in RFC
> 3485 [42]. If compression is enabled, the P-CSCF shall use
> the dictionary to compress the first message.
>
> NOTE: Exchange of bytecodes during registration will prevent
> unnecessary delays during session setup.
>
> Editor's note: The draft-ietf-rohc-sigcomp-sip-01 [79]
> can lead to the need for additional changes or clarifications.
>
> The following apply when signalling compression is used:
>
> - State Memory Size (SMS) greater than zero is needed to
> give room for the UDVM byte code and make dynamic compression
> possible. A State Memory Size of at least 4096 bytes shall be
> a minimum value; and
>
> - A Decompression Memory Size (DMS) of at least 8192
> bytes should be a minimum value.
>
> 8.2.2 Compression of SIP requests and responses transmitted to the UE
>
> The P-CSCF should compress the requests and responses
> transmitted to the UE according to subclause 8.2.1.
>
> NOTE: Compression of SIP messages is an implementation
> option. However, compression is strongly recommended.
>
> 8.2.3 Decompression of SIP requests and responses received from the UE
>
> The P-CSCF shall decompress the compressed requests and
> responses received from the UE according to subclause 8.2.1.
>
> If the P-CSCF detects a decompression failure at the UE, the
> recovery mechanism is implementation specific and this may,
> as an example, include resetting the compartment, changing
> the algorithm.
>
>
> > -----Original Message-----
> > From: rohc-bounces at ietf.org
> [mailto:rohc-bounces at ietf.org]On Behalf Of
> > Paulius.Meskauskas at nokia.com
> > Sent: 14 December 2004 09:11
> > To: cabo at tzi.org; abigail.surtees at ROKE.CO.UK
> > Cc: mark.a.west at ROKE.CO.UK; rohc at ietf.org; zhigang.c.liu at nokia.com;
> > lwc at ROKE.CO.UK
> > Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp
> > messages on
> > t hesame TCP connection
> >
> >
> > hello,
> >
> > OMA PoC mandates the usage of SigComp and in case IMS core
> > is used - the compression must take place between UE and P-CSCF.
> >
> > IMHO there's no need for 'uncompressed SigComp header' in order
> > to keep SigComp generic and allow the multiplexing.. The main thing
> > is to break the SigComp dependency to the transport layer in
> > the implementation
> > i.e. text-based protocols know their delimiters and SigComp
> > knows its own.
> >
> > cheers,
> > paulius
> >
> >
> > > -----Original Message-----
> > > From: rohc-bounces at ietf.org
> > [mailto:rohc-bounces at ietf.org]On Behalf Of
> > > ext Carsten Bormann
> > > Sent: Tuesday, November 16, 2004 5:31 PM
> > > To: Surtees, Abigail
> > > Cc: West, Mark; Sugar Robert (Nokia-NET/Budapest); Liu Zhigang.C
> > > (Nokia-NRC/Dallas); rohc at ietf.org; Conroy, Lawrence
> (SMTP); Carsten
> > > Bormann
> > > Subject: Re: [rohc] Re: multiplexing SigComp and non-SigComp
> > > messages on
> > > t hesame TCP connection
> > >
> > >
> > > Abbie,
> > >
> > > 3GPP submission S2-043577 says:
> > >
> > > > For TCP, none of the existing standards mandates whether or not
> > > > endpoints must be able to multiplex SIP and SigComp
> > messages on the
> > > > same TCP connection however, the IETF currently see no need to
> > > > multiplex and would like to mandate that it must not be
> > > done. We note
> > > > that with the IMS security architecture there are some
> > constraints
> > > > with regards to the usage of ports on the P-CSCF and the
> > UE. During
> > > > the establishment of the IPSec security association the
> > UE and the
> > > > P-CSCF negotiate 2 ports on each side. These ports are
> > used as the
> > > > selector for the corresponding security association and are
> > > fixed for
> > > > the duration of the security association. Consequently, if
> > > there is a
> > > > need to send both SIP and SigComp messages over TCP, they
> > > would have
> > > > to be on the same connection.
> > > >
> > > > It seems, however, that the issue is not a real issue for
> > > IMS and PoC,
> > > > as it is mandated that terminals and networks will
> > support SigComp
> > > > (though its use is not mandatory). Consequently a terminal
> > > can decide
> > > > on the first message whether or not it is going to use
> > > SigComp and not
> > > > change. In this case, if there is a need to send an
> uncompressed
> > > > message (e.g. due to loss of sync between compressor and
> > > decompressor,
> > > > or to reduce processing load) when SigComp is in use, the
> > > > 'uncompressed SigComp header' can be used. This is a set
> > of 13 well
> > > > known bytes that are prepended to the SIP message to make
> > > it a SigComp
> > > > message and are removed as a block at the decompressor.
> > >
> > > This fits pretty well with what was said in the San Diego
> > WG meeting
> > > and hallway discussions, and this is what was intended by
> > my slide in
> > > Washington.
> > >
> > > (Sorry if I'm incoherent -- I'm wrestling with my usual post-IETF
> > > aircon-induced fever.)
> > >
> > > Gruesse, Carsten
> > >
> > >
> > > _______________________________________________
> > > 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
> >
>
_______________________________________________
Rohc mailing list
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc