draft-ietf-rohc-sigcomp-sip-07.txt   draft-ietf-rohc-sigcomp-sip-08.txt 
Robust Header Compression C. Bormann Robust Header Compression C. Bormann
Internet-Draft Universitaet Bremen TZI Internet-Draft Universitaet Bremen TZI
Intended status: Standards Track Z. Liu Intended status: Standards Track Z. Liu
Expires: January 4, 2008 Nokia Research Center Expires: March 19, 2008 Nokia Research Center
R. Price R. Price
EADS Defence and Security Systems EADS Defence and Security Systems
Limited Limited
G. Camarillo, Ed. G. Camarillo, Ed.
Ericsson Ericsson
July 3, 2007 September 20, 2007
Applying Signaling Compression (SigComp) to the Session Initiation Applying Signaling Compression (SigComp) to the Session Initiation
Protocol (SIP) Protocol (SIP)
draft-ietf-rohc-sigcomp-sip-07.txt draft-ietf-rohc-sigcomp-sip-08.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 4, 2008. This Internet-Draft will expire on March 19, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes some specifics that apply when Signaling This document describes some specifics that apply when Signaling
Compression (SigComp) is applied to the Session Initiation Protocol Compression (SigComp) is applied to the Session Initiation Protocol
(SIP), such as default minimum values of SigComp parameters, (SIP), such as default minimum values of SigComp parameters,
skipping to change at page 2, line 25 skipping to change at page 2, line 25
3. Compliance with this Specification . . . . . . . . . . . . . . 3 3. Compliance with this Specification . . . . . . . . . . . . . . 3
4. Minimum Values of SigComp Parameters for SIP/SigComp . . . . . 3 4. Minimum Values of SigComp Parameters for SIP/SigComp . . . . . 3
4.1. decompression_memory_size (DMS) for SIP/SigComp . . . . . 4 4.1. decompression_memory_size (DMS) for SIP/SigComp . . . . . 4
4.2. state_memory_size (SMS) for SIP/SigComp . . . . . . . . . 4 4.2. state_memory_size (SMS) for SIP/SigComp . . . . . . . . . 4
4.3. cycles_per_bit (CPB) for SIP/SigComp . . . . . . . . . . . 5 4.3. cycles_per_bit (CPB) for SIP/SigComp . . . . . . . . . . . 5
4.4. SigComp_version (SV) for SIP/SigComp . . . . . . . . . . . 5 4.4. SigComp_version (SV) for SIP/SigComp . . . . . . . . . . . 5
4.5. locally available state (LAS) for SIP/SigComp . . . . . . 5 4.5. locally available state (LAS) for SIP/SigComp . . . . . . 5
5. Delimiting SIP Messages and SigComp Messages on the Same 5. Delimiting SIP Messages and SigComp Messages on the Same
Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Continuous Mode over TCP . . . . . . . . . . . . . . . . . . . 6 6. Continuous Mode over TCP . . . . . . . . . . . . . . . . . . . 6
7. Too Large SIP Messages . . . . . . . . . . . . . . . . . . . . 6 7. Too Large SIP Messages . . . . . . . . . . . . . . . . . . . . 7
8. SIP Retransmissions . . . . . . . . . . . . . . . . . . . . . 7 8. SIP Retransmissions . . . . . . . . . . . . . . . . . . . . . 7
9. Compartment and State Management for SIP/SigComp . . . . . . . 7 9. Compartment and State Management for SIP/SigComp . . . . . . . 7
9.1. Remote Application Identification . . . . . . . . . . . . 7 9.1. Remote Application Identification . . . . . . . . . . . . 8
9.2. Identifier Comparison Rules . . . . . . . . . . . . . . . 10 9.2. Identifier Comparison Rules . . . . . . . . . . . . . . . 10
9.3. Compartment Opening and Closure . . . . . . . . . . . . . 10 9.3. Compartment Opening and Closure . . . . . . . . . . . . . 11
9.4. Lack of a Compartment . . . . . . . . . . . . . . . . . . 12 9.4. Lack of a Compartment . . . . . . . . . . . . . . . . . . 13
10. Recommendations for Network Administrators . . . . . . . . . . 13 10. Recommendations for Network Administrators . . . . . . . . . . 13
11. Private Agreements . . . . . . . . . . . . . . . . . . . . . . 13 11. Private Agreements . . . . . . . . . . . . . . . . . . . . . . 14
12. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 14 12. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 14
13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 13. Interactions with TLS . . . . . . . . . . . . . . . . . . . . 14
14. Security Considerations . . . . . . . . . . . . . . . . . . . 17 14. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 15. Security Considerations . . . . . . . . . . . . . . . . . . . 17
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
17.1. Normative References . . . . . . . . . . . . . . . . . . . 18 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
17.2. Informative References . . . . . . . . . . . . . . . . . . 19 18.1. Normative References . . . . . . . . . . . . . . . . . . . 18
18.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 21
1. Introduction 1. Introduction
SigComp [RFC3320] is a solution for compressing messages generated by SigComp [RFC3320] is a solution for compressing messages generated by
application protocols. Although its primary driver is to compress application protocols. Although its primary driver is to compress
SIP [RFC3261] messages, the solution itself has been intentionally SIP [RFC3261] messages, the solution itself has been intentionally
designed to be application agnostic so that it can be applied to any designed to be application agnostic so that it can be applied to any
application protocol; this is denoted as ANY/SigComp. Consequently, application protocol; this is denoted as ANY/SigComp. Consequently,
skipping to change at page 5, line 26 skipping to change at page 5, line 26
[RFC3320]. [RFC3320].
Minimum value for SIP/SigComp: 16 (same as above) Minimum value for SIP/SigComp: 16 (same as above)
4.4. SigComp_version (SV) for SIP/SigComp 4.4. SigComp_version (SV) for SIP/SigComp
For ANY/SigComp: 0x01, as specified in section 3.3.2 of [RFC3320]. For ANY/SigComp: 0x01, as specified in section 3.3.2 of [RFC3320].
For SIP/SigComp: >= 0x02 (at least SigComp + NACK) For SIP/SigComp: >= 0x02 (at least SigComp + NACK)
Note that this implies that the provisions of [RFC4077] apply. That
is, decompression failures result in SigComp NACK messages sent back
to the originating compressor. It also implies that the compressor
need not make use of the methods detailed in Section 2.4 of [RFC4077]
(Detecting Support for NACK); for example, it can use optimistic
compression methods right from the outset.
4.5. locally available state (LAS) for SIP/SigComp 4.5. locally available state (LAS) for SIP/SigComp
Minimum LAS for ANY/SigComp: none, see section 3.3.3 of [RFC3320]. Minimum LAS for ANY/SigComp: none, see section 3.3.3 of [RFC3320].
Minimum LAS for SIP/SigComp: the SIP/SDP static dictionary as defined Minimum LAS for SIP/SigComp: the SIP/SDP static dictionary as defined
in [RFC3485]. in [RFC3485].
Note that, since support for the static SIP/SDP dictionary is Note that, since support for the static SIP/SDP dictionary is
mandatory, it does not need to be advertised. mandatory, it does not need to be advertised.
skipping to change at page 7, line 27 skipping to change at page 7, line 33
The reason for this behavior is that it is impossible to know whether The reason for this behavior is that it is impossible to know whether
the failure causing the retransmission occurred on the message being the failure causing the retransmission occurred on the message being
retransmitted or on the response to that message. If the response retransmitted or on the response to that message. If the response
was lost, any state changes effected by the first instance of the was lost, any state changes effected by the first instance of the
retransmitted message would already have taken place. If these state retransmitted message would already have taken place. If these state
changes removed a state that the previously-transmitted message changes removed a state that the previously-transmitted message
relied upon, then retransmission of the same compressed message would relied upon, then retransmission of the same compressed message would
lead to a decompression failure. lead to a decompression failure.
Note that a SIP retransmission may be caused by the original message
or its response being lost by a decompression failure. In this case,
a NACK will have been sent by the decompressor to the compressor,
which may use the information in this NACK message to adjust its
compression parameters. Note that, on an unreliable transport, such
a NACK message may still be lost, so if a compressor used some form
of optimistic compression it MAY want to switch to a method less
likely to cause any form of decompression failure when compressing a
SIP retransmission.
9. Compartment and State Management for SIP/SigComp 9. Compartment and State Management for SIP/SigComp
An application exchanging compressed traffic with a remote An application exchanging compressed traffic with a remote
application has a compartment that contains state information needed application has a compartment that contains state information needed
to compress outgoing messages and to decompress incoming messages. to compress outgoing messages and to decompress incoming messages.
To increase the compression efficiency, the application must assign To increase the compression efficiency, the application must assign
distinct compartments to distinct remote applications. distinct compartments to distinct remote applications.
9.1. Remote Application Identification 9.1. Remote Application Identification
SIP/SigComp applications identify remote applications by their SIP/ SIP/SigComp applications identify remote applications by their SIP/
SigComp identifiers. Each SIP/SigComp application MUST have a SIP/ SigComp identifiers. Each SIP/SigComp application MUST have a SIP/
SigComp identifier URN (Uniform Resource Name) that uniquely SigComp identifier URN (Uniform Resource Name) that uniquely
identifies the application. Usage of a URN provides a persistent and identifies the application. Usage of a URN provides a persistent and
unique name for the SIP/SigComp identifier. It also provides an easy unique name for the SIP/SigComp identifier. It also provides an easy
way to guarantee uniqueness. This URN MUST be persistent as long as way to guarantee uniqueness. This URN MUST be persistent as long as
the application stores compartment state related to other SIP/SigComp the application stores compartment state related to other SIP/SigComp
applications. applications.
A SIP/Sigcomp application SHOULD use a UUID (Universally Unique A SIP/Sigcomp application SHOULD use a UUID (Universally Unique
IDentifier) URN as its SIP/SigComp identifier. The UUID URN IDentifier) URN as its SIP/SigComp identifier, due to the
[RFC4122] allows for non-centralized computation of a URN based on difficulties in equality comparisons for other kinds of URNs. The
time, unique names (such as a MAC address), or a random number UUID URN [RFC4122] allows for non-centralized computation of a URN
generator. If a URN scheme other than UUID is used, the URN MUST be based on time, unique names (such as a MAC address), or a random
selected such that the application can be certain that no other SIP/ number generator. If a URN scheme other than UUID is used, the URN
SigComp application would choose the same URN value. MUST be selected such that the application can be certain that no
other SIP/SigComp application would choose the same URN value.
Note that the definition of SIP/SigComp identifier is similar to the Note that the definition of SIP/SigComp identifier is similar to the
definition of instance identifier in [I-D.ietf-sip-outbound]. One definition of instance identifier in [I-D.ietf-sip-outbound]. One
difference is that instance identifiers are only required to be difference is that instance identifiers are only required to be
unique within their AoR (Address of Record) while SIP/SigComp unique within their AoR (Address of Record) while SIP/SigComp
identifiers are required to be globally unique. identifiers are required to be globally unique.
Even if instance identifiers are only required to be unique within Even if instance identifiers are only required to be unique within
their AoR, devices may choose to generate globally unique instance their AoR, devices may choose to generate globally unique instance
identifiers. A device with a globally unique instance identifier identifiers. A device with a globally unique instance identifier
skipping to change at page 10, line 38 skipping to change at page 11, line 6
the URN. If the element performing the comparisons does not the URN. If the element performing the comparisons does not
understand the URN scheme, it performs the comparisons using the understand the URN scheme, it performs the comparisons using the
lexical equality rules defined in RFC 2141 [RFC2141]. Lexical lexical equality rules defined in RFC 2141 [RFC2141]. Lexical
equality may result in two URNs being considered unequal when they equality may result in two URNs being considered unequal when they
are actually equal. In this specific usage of URNs, the only element are actually equal. In this specific usage of URNs, the only element
which provides the URN is the SIP/SigComp application identified by which provides the URN is the SIP/SigComp application identified by
that URN. As a result, the SIP/SigComp application SHOULD provide that URN. As a result, the SIP/SigComp application SHOULD provide
lexically equivalent URNs in each registration it generates. This is lexically equivalent URNs in each registration it generates. This is
likely to be normal behavior in any case; applications are not likely likely to be normal behavior in any case; applications are not likely
to modify the value of their SIP/SigComp identifiers so that they to modify the value of their SIP/SigComp identifiers so that they
remain functionally equivalent yet lexigraphically different from remain functionally equivalent yet lexicographically different from
previous identifiers. previous identifiers.
9.3. Compartment Opening and Closure 9.3. Compartment Opening and Closure
SIP applications need to know when to open a new compartment and when SIP applications need to know when to open a new compartment and when
to close it. The lifetime of SIP/SigComp compartments is linked to to close it. The lifetime of SIP/SigComp compartments is linked to
registration state. Compartments are opened at SIP registration time registration state. Compartments are opened at SIP registration time
and are typically closed when the registration expires or is and are typically closed when the registration expires or is
canceled. canceled.
skipping to change at page 14, line 28 skipping to change at page 14, line 38
When this document was written, there already were a few existing When this document was written, there already were a few existing
SIP/SigComp deployments. The rules in this document have been SIP/SigComp deployments. The rules in this document have been
designed to maximize interoperability with those legacy SIP/SigComp designed to maximize interoperability with those legacy SIP/SigComp
implementations. Nevertheless, implementers should be aware that implementations. Nevertheless, implementers should be aware that
legacy SIP/SigComp implementations may not conform to this legacy SIP/SigComp implementations may not conform to this
specification. Examples of problems with legacy applications would specification. Examples of problems with legacy applications would
be smaller DMS than mandated in this document, lack of NACK support, be smaller DMS than mandated in this document, lack of NACK support,
or a different compartment mapping. or a different compartment mapping.
13. Example 13. Interactions with TLS
Endpoints exchanging SIP traffic over a TLS [RFC4346] connection can
use the compression provided by TLS. Two endpoints exchanging SIP/
SigComp traffic over a TLS connection that provides compression need
to first compress the SIP messages using SigComp and, then, pass them
to the TLS layer, which will compress them again. When receiving
data, the processing order is reversed.
However, compressing messages twice this way does not typically bring
significant gains. Once a message is compressed using SigComp, TLS
is not usually able to compress it further. Therefore, TLS will
normally only be able to compress SigComp code sent between
compressor and decompressor. Since the gain of having SigComp code
compressed should be in most cases minimal, it is NOT RECOMMENDED
using TLS compression when SigComp compression is being used.
14. Example
Figure 1 shows an example message flow where the user agent and the Figure 1 shows an example message flow where the user agent and the
outbound proxy exchange compressed SIP traffic. Compressed messages outbound proxy exchange compressed SIP traffic. Compressed messages
are marked with a (c). are marked with a (c).
User Agent Outbound Proxy Registrar User Agent Outbound Proxy Registrar
|(1) REGISTER (c) | | |(1) REGISTER (c) | |
|---------------->| | |---------------->| |
| |(2) REGISTER | | |(2) REGISTER |
skipping to change at page 15, line 37 skipping to change at page 16, line 4
|(11) BYE (c) | | |(11) BYE (c) | |
|---------------->| | |---------------->| |
| |(12) BYE | | |(12) BYE |
| |------------------------------> | |------------------------------>
| |(13) 200 OK | | |(13) 200 OK |
| |<------------------------------ | |<------------------------------
|(14) 200 OK (c) | | |(14) 200 OK (c) | |
|<----------------| | |<----------------| |
Figure 1: Example message flow Figure 1: Example message flow
The user agent in Figure 1 is initially configured (e.g., using the
The user agent in Figure 1 is initialy configured (e.g., using the
SIP configuration framework [I-D.ietf-sipping-config-framework]) with SIP configuration framework [I-D.ietf-sipping-config-framework]) with
the URI of its outbound proxy. That URI contains the outbound the URI of its outbound proxy. That URI contains the outbound
proxy's SIP/SigComp identifier, referred to as 'Outbound-id', in a proxy's SIP/SigComp identifier, referred to as 'Outbound-id', in a
'sigcomp-id' parameter. 'sigcomp-id' parameter.
When the user agent sends an initial REGISTER request (1) to the When the user agent sends an initial REGISTER request (1) to the
outbound proxy's URI, the user agent opens a new compartment for outbound proxy's URI, the user agent opens a new compartment for
'Outbound-id'. This compartment will be valid, at least, for the 'Outbound-id'. This compartment will be valid, at least, for the
duration of the registration. duration of the registration.
skipping to change at page 17, line 5 skipping to change at page 17, line 17
the INVITE request. the INVITE request.
On receiving the INVITE request (5), the outbound proxy Record Routes On receiving the INVITE request (5), the outbound proxy Record Routes
and relays the INVITE request (6) forward. The outbound proxy Record and relays the INVITE request (6) forward. The outbound proxy Record
Routes to ensure that all SIP messages related to this new dialog are Routes to ensure that all SIP messages related to this new dialog are
routed through the outbound proxy. routed through the outbound proxy.
Finally the dialog is terminated by a BYE transaction (11) that also Finally the dialog is terminated by a BYE transaction (11) that also
traverses the outbound proxy. traverses the outbound proxy.
14. Security Considerations 15. Security Considerations
The same security considerations as described in [RFC3320] apply to The same security considerations as described in [RFC3320] apply to
this document. Note that keeping SigComp states longer than the this document. Note that keeping SigComp states longer than the
duration of a SIP dialog should not pose new security risks for two duration of a SIP dialog should not pose new security risks because
reasons: a) the state has been allowed to be created in the first the state has been allowed to be created in the first place.
place; and b) this is on voluntary basis and a SigComp endpoint can
choose not to offer it.
15. IANA Considerations 16. IANA Considerations
The IANA is requested to register the 'sigcomp-id' Via header field The IANA is requested to register the 'sigcomp-id' Via header field
parameter, which is defined in Section 9.1, under the Header Field parameter, which is defined in Section 9.1, under the Header Field
Parameters and Parameter Values subregistry within the SIP Parameters Parameters and Parameter Values subregistry within the SIP Parameters
registry: registry:
Predefined Predefined
Header Field Parameter Name Values Reference Header Field Parameter Name Values Reference
---------------------------- --------------- --------- --------- ---------------------------- --------------- --------- ---------
Via sigcomp-id No [RFCxxxx] Via sigcomp-id No [RFCxxxx]
skipping to change at page 17, line 37 skipping to change at page 18, line 5
which is defined in Section 9.1, under the SIP/SIPS URI Parameters which is defined in Section 9.1, under the SIP/SIPS URI Parameters
subregistry within the SIP Parameters registry: subregistry within the SIP Parameters registry:
Parameter Name Predefined Values Reference Parameter Name Predefined Values Reference
-------------- ----------------- --------- -------------- ----------------- ---------
sigcomp-id No [RFCxxxx] sigcomp-id No [RFCxxxx]
Note to the RFC Editor: please, substitute RFCxxxx with the RFC Note to the RFC Editor: please, substitute RFCxxxx with the RFC
number this document will get. number this document will get.
16. Acknowledgements 17. Acknowledgements
The authors would like to thank the following people for their The authors would like to thank the following people for their
comments and suggestions: Jan Christoffersson, Joerg Ott, Mark West, comments and suggestions: Jan Christoffersson, Joerg Ott, Mark West,
Pekka Pessi, Robert Sugar, Jonathan Rosenberg, Robert Sparks, Juergen Pekka Pessi, Robert Sugar, Jonathan Rosenberg, Robert Sparks, Juergen
Schoenwaelder, and Tuukka Karvonen. Abigail Surtees and Adam Roach Schoenwaelder, and Tuukka Karvonen. Abigail Surtees and Adam Roach
performed thorough reviews of this document. performed thorough reviews of this document.
17. References 18. References
17.1. Normative References 18.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
skipping to change at page 18, line 47 skipping to change at page 19, line 9
[RFC4077] Roach, A., "A Negative Acknowledgement Mechanism for [RFC4077] Roach, A., "A Negative Acknowledgement Mechanism for
Signaling Compression", RFC 4077, May 2005. Signaling Compression", RFC 4077, May 2005.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
July 2005. July 2005.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, October 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4896] Surtees, A., West, M., and A. Roach, "Signaling [RFC4896] Surtees, A., West, M., and A. Roach, "Signaling
Compression (SigComp) Corrections and Clarifications", Compression (SigComp) Corrections and Clarifications",
RFC 4896, June 2007. RFC 4896, June 2007.
[I-D.ietf-sip-outbound] 18.2. Informative References
Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-08 (work in progress), March 2007.
17.2. Informative References
[I-D.ietf-sipping-config-framework] [I-D.ietf-sipping-config-framework]
Petrie, D. and S. Channabasappa, "A Framework for Session Petrie, D. and S. Channabasappa, "A Framework for Session
Initiation Protocol User Agent Profile Delivery", Initiation Protocol User Agent Profile Delivery",
draft-ietf-sipping-config-framework-12 (work in progress), draft-ietf-sipping-config-framework-12 (work in progress),
June 2007. June 2007.
[I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-08 (work in progress), March 2007.
Authors' Addresses Authors' Addresses
Carsten Bormann Carsten Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
Bremen D-28334 Bremen D-28334
Germany Germany
Phone: +49 421 218 7024 Phone: +49 421 218 7024
Fax: +49 421 218 7000 Fax: +49 421 218 7000
 End of changes. 24 change blocks. 
41 lines changed or deleted 77 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/