Transporting User to User Call Control Information in SIP for ISDN Interworking

This document describes the transport of User to User Information (UUI) in ISDN interworking scenarios using SIP . Specifically, we discuss the transport of call control related ITU-T Q.931 User to User Information Element (UU IE) data in SIP. Five different use case call flows are discussed. It is important to note that standardization of the UUI content is explicitly out of scope for this specification. For cases where the content of user to user information is relevant to SIP, it is expected a new SIP header field will be created to transport the information. For example, location information is an example of user to user information, and obviously it needs to be transported in a specifically named SIP header rather than transported using this generic mechanism.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 .

This section discusses four uses cases for the transport of call control related user to user information. What is not discussed here is the transport of non-call control UUI. We define call control UUI as information that is generated, transported, and consumed at the time of call setup (i.e. during a pending INVITE transaction). The information can be used for call routing, alerting, call distribution, or simply rendering. The exact usage and semantics of call control UUI is out of scope - SIP is simply providing the transport function for this that ISDN Provides in the PSTN. Non-call control UUI can be sent using the INFO method and not using the extensions described in this specification.

In this scenario, the originator UA includes UUI in the INVITE sent through a proxy to the terminating UA. The terminator can use the UUI in any way. If it is an ISDN gateway, it could map the UUI into the appropriate Q.931 element. Alternatively, it might render the information to the user, or use it for alerting or as a lookup for a screen pop. In this case, the proxy does not need to understand the UUI mechanism, but normal proxy rules should result in the UUI being forwarded without modification. This call flow is shown in Figure 1.

| INVITE (UUI) F2 | | 100 Trying F3 |------------------->| |<-------------------| 200 OK F4 | | 200 OK F5 |<-------------------| |<-------------------| | | ACK F6 | | |------------------->| ACK F7 | | |------------------->| ]]> Figure 1. Call flow with UUI exchanged between Originator and Terminator.

In this scenario, proxy inserts the UUI into the INVITE from the originating UA which is then processed by the terminating UA. The proxy can insert the UUI based on the identity of the originator, the time of day, the dialed URI or any other service specific information available when the INVITE is received. This call flow is shown in Figure 2.

| INVITE (UUI) F2 | | 100 Trying F3 |------------------->| |<-------------------| 200 OK F4 | | 200 OK F5 |<-------------------| |<-------------------| | | ACK F6 | | |------------------->| ACK F7 | | |------------------->| ]]> Figure 2. Call flow with UUI inserted by Proxy for the Terminator.

In this scenario, the originator UA includes UUI in the INVITE sent through a proxy to the terminating UA. The proxy inspects the UUI in the INVITE and either modifies it or inserts new UUI. This information is then processed by the terminating UA. This call flow is shown in Figure 3.

| INVITE (UUI') F2 | | 100 Trying F3 |------------------->| |<-------------------| 200 OK F4 | | 200 OK F5 |<-------------------| |<-------------------| | | ACK F6 | | |------------------->| ACK F7 | | |------------------->| ]]> Figure 3. Call flow with UUI exchanged between Originator and Terminator and modified by the Proxy.

In this scenario, UUI is inserted by a redirect server which is then included in the INVITE sent by the Originator to the Terminator. In this case, the Originator does not need to support the UUI mechanism but does need to support the SIP redirection mechanism used to include the UUI information.

| | | 302 Moved (UUI) F2 | | |<-------------------| | | ACK F3 | | |------------------->| | | INVITE (UUI) F4 | | |---------------------------------------->| | 200 OK F5 | |<----------------------------------------| | ACK F6 | |---------------------------------------->| ]]> Figure 4. Call flow with UUI exchanged between Redirect Server and Terminator A common application of this call flow is an Automatic Call Distributer (ACD) in a PSTN contact center. The originator would be a PSTN gateway. The ACD would act as a Redirect Server, inserting UUI based on called number, calling number, time of day, and other information. The resulting UUI would be passed to the agent's handset which acts as the Terminator. The UUI could be used to lookup information rendered to the agent at the time of call answering.

In this scenario, a Referrer UA causes an INVITE to be generated between the Originator and Terminator with UUI information inserted by the Referrer UA. Note that this REFER could be part of a transfer operation or it might be unrelated to an existing call, such as out-of-dialog REFER call control. In some cases, this call flow is used in place of the redirection call flow, but where immediately upon answer, the REFER is sent. This scenario is shown in Figure 5.

| | | NOTIFY (100 Trying) F3 | |------------------->| | | 200 OK F4 | | |<-------------------| | | INVITE (UUI) F5 | | |---------------------------------------->| | 200 OK F6 | |<----------------------------------------| | ACK F7 | |---------------------------------------->| | NOTIFY (200 OK) F8 | | |------------------->| | | 200 OK F9 | | |<-------------------| | ]]> Figure 5. Call flow with transfer after answer. Some scenarios involving referral have been proposed to use a REFER sent during an early dialog. . This NOT RECOMMENDED call flow is shown in Figure 6. This flow is not recommended due to the number of messages exchanged (due to the REFER, CANCEL, and 487 responses) and the sending of the REFER in the early dialog.

| | | 180 Ringing F2 | | |<-------------------| | | REFER (UUI) F3 | | |<-------------------| | | 202 Accepted F4 | | |------------------->| | | NOTIFY (100 Trying) F5 | |------------------->| | | 200 OK F6 | | |<-------------------| | | INVITE (UUI) F7 | | |---------------------------------------->| | 200 OK F8 | |<----------------------------------------| | ACK F9 | |---------------------------------------->| | NOTIFY (200 OK) F10| | |------------------->| | | 200 OK F11 | | |<-------------------| | | CANCEL F12 | | |------------------->| | | 200 OK F13 | | |<-------------------| | | 487 Request Terminated F14 | |<-------------------| | | ACK F15 | | |------------------->| | ]]> Figure 6. NOT RECOMMENDED call flow showing REFER prior to answer.

Three mechanisms for transporting UUI will be described: MIME body, header field, and URI parameter transport.

Since the INFO method ., was developed for ISUP interworking of user-to-user information, it might seem to be the logical choice here. For non-call control user-to-user information, INFO can be utilized for end to end transport. However, for transport of call control user-to-user information, INFO can not be used. As the call flows in the previous section show, the information is related to an attempt to establish a session and must be passed with the session setup request (INVITE), responses to that INVITE, or session termination requests. As a result, it is not possible to use INFO in these cases.

One method of transport is to transport the UUI information as a MIME body. This is in keeping with the SIP-T architecture in which MIME bodies are used to transport ISUP information. However, in the SIP-T example, the body is added by the originator and used by the terminator. Since the INVITE will normally have an SDP message body, the INVITE with SDP and UUI will be multipart MIME. The insertion of a UUI message body by a proxy is not permitted by RFC 3261. The insertion of a UUI message body by a redirect server or in a REFER is difficult. The body would need to be encoded in the Contact URI of the 3xx response or the Refer-To URI of a REFER. For example:

Contact: ]]> Note that the <allOneLine> tag convention from SIP Torture Test Messages is used to show that there are no line breaks in the actual message syntax.

Another proposed approach is to encode the UUI as a URI parameter into the Contact or Refer-To URI.

Contact: ]]> The resulting INVITE would contain UUI in the Request-URI of the INVITE. The URI parameter has a drawback in that a URI parameter will not survive retargeting by a proxy. That is, if the URI is an Address of Record instead of a Contact URI, the URI parameter will not be copied over the Contact URI, resulting in the loss of the information.

Another approach that has been proposed is to use a header field to transport the UUI information. The header field would be escaped into the Contact or Refer-To URI. The header field approach will work with the redirection, REFER, and proxy call flows. The Call-Info header field is related to the UUI information. However, there are a number of important differences: Call-Info is for rendering to the user. While some of the UUI information may ultimately be rendered to the user, most of the UUI information will be consumed by the end device. Call-Info contains a URI pointer the information instead of the actual information itself. UUI is always a small amount of data and must be carried with the request. For these reasons, a separate header field needs to be defined, described here as User-to-User. For example, here is an example User-to-User header field from message F1 in Figure 1:

For example, here is an escaped User-to-User header field from the redirection response F2 of Figure 4:

Contact: ]]> The resulting INVITE F5 would contain the User-to-User header field of the previous example. An escaped User-to-User header field from the REFER message response F1 of Figure 5:

Refer-To: ]]> This would result in the INVITE F4 containing the User-to-User header field of the first example.

The recommendation is to define a new SIP header field User-to-User to transport UUI information in ISDN interworking applications. The format of the UUI information is a topic of future standardization. Currently, UUI is proprietary, requiring coordinated configuration between servers. Standardizing the format or providing content tags would provide additional benefits.

Editor's Note: Eventually this text will move to a SIP Working Group document to define the new header field. The User-to-User header field can be present in INVITE requests and responses only and in BYE requests and responses. Current usage is to interoperate with ISDN User to User Signaling (UUS), a supplementary service in which manufacturer specific information is transported via the codeset 0 User-user Information IE. Three services are defined: service 1, service 2, and service 3. This draft only addresses the SIP equivalent of service 1 although it could easily be expanded later to address services 2 and 3. UUS Service 1 involves user to user signaling exchanged during call setup and clearing within the following Q.931 call control messages: SETUP, ALERT, CONNECT, DISCONNECT, RELEASE, and RELEASE COMPLETE. UUS Service 2 involves user to user signaling exchanged during call establishment (between ALERT and CONNECT) via the USER INFORMATION message. This service usually has a maximum of 2 USER INFORMATION messages in each direction. UUS Service 3 involves user to user signaling exchanged on an active call via the USER INFORMATION message. The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 2234 and extends RFC 3261.

Only one User-to-User header field may be present in a request or response. The only defined parameter for the User-to-User header field is the encoding parameter. "encoding=hex" is used to indicate that the UUI information is encoded as hex digits per the ISDN specification. The first octet is the protocol discriminator). Other encoding methods of encoding may also be standardized. Note that ISDN limits UUI to 128 octets in length. While this header field has no such limitations, transporting UUI longer than 128 octets will result in interoperability failures when interworking with ISDN.

This document defines a new SIP header field named "User-to-User". The following row shall be added to the "Header Fields" section of the SIP parameter registry:

Editor's Note: [RFCXXXX] should be replaced with the designation of this document.

This document defines a parameter for the header field defined in the preceding section. The header field "User-to-User" can contain the parameter "encoding". The following rows shall be added to the "Header Field Parameters and Parameter Values" section of the SIP parameter registry:

Editor's Note: [RFCXXXX] should be replaced with the designation of this document.

User to user information can be exchanged over SIP on a hop-by-hop or end-to-end basis. In some cases, it may carry private information that may need confidential transport and integrity protection. Standard SIP security mechanisms can be used to secure this header field. For example, TLS transport can provide single hop confidentiality and integrity protection. For multiple hop or end-to-end confidentiality and integrity protection, S/MIME can be utilized. Information contained in a User-to-User header field should only be trusted if it is received within a trust domain. For example, Spec-T, defined in could be used to define a trust domain. When utilized by a gateway to map information to or from ISDN Q.931, appropriate policy should be applied based on the PSTN trust domain.

The authors wish to thank Francois Audet, Denis Alexeitsev, and Keith Drage for their comments.