One document matched: draft-barnes-sipcore-rfc4244bis-callflows-00.txt
Network Working Group M. Barnes
Internet-Draft Polycom
Intended status: Informational F. Audet
Expires: December 26, 2010 Skype
S. Schubert
NTT
J. van Elburg
Detecon International Gmbh
C. Holmberg
Ericsson
June 24, 2010
Session Initiation Protocol (SIP) History-Info Header Call Flow Examples
draft-barnes-sipcore-rfc4244bis-callflows-00.txt
Abstract
This document describes use cases and documents call flows which
require the History-Info header to capture the Request-URIs as a
Session Initiation Protocol (SIP) Request is retargeted. The use
cases are described along with the corresponding call flow diagrams
and messaging details.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 26, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Barnes, et al. Expires December 26, 2010 [Page 1]
Internet-Draft History-Info Call Flows June 2010
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. Detailed call flows . . . . . . . . . . . . . . . . . . . . . 3
3.1. Automatic Call Distribution . . . . . . . . . . . . . . . 3
3.2. Determining the Alias used. . . . . . . . . . . . . . . . 5
3.3. PBX Voicemail Example . . . . . . . . . . . . . . . . . . 7
3.4. Call Center Voicemail Example . . . . . . . . . . . . . . 9
3.5. GRUU . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.6. Limited Use Address . . . . . . . . . . . . . . . . . . . 14
3.7. Sub-Address . . . . . . . . . . . . . . . . . . . . . . . 16
3.8. Service Invocation . . . . . . . . . . . . . . . . . . . . 20
3.9. Toll Free Number . . . . . . . . . . . . . . . . . . . . . 20
4. Security Considerations . . . . . . . . . . . . . . . . . . . 23
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
5.1. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 23
6. Informative References . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Barnes, et al. Expires December 26, 2010 [Page 2]
Internet-Draft History-Info Call Flows June 2010
1. Overview
Many services that use SIP require the ability to determine why and
how the call arrived at a specific application. The use cases
provided in this document illustrate the use of the History-Info
header [I-D.ietf-sipcore-rfc4244bis] for example applications and
common scenarios. The Target parameter along with the "hit" SIP/SIPS
URI are required for several of the use cases. Descriptions of the
example use cases, call flow diagrams and messaging details are
provided.
2. Conventions and Terminology
The terms "retarget" and "forward" are used as defined in
[I-D.ietf-sipcore-rfc4244bis]. The terms "location service",
"redirect" and "AOR" are used consistent with the terminology in
[RFC3261].
3. Detailed call flows
The scenarios in this section provide sample use cases for the
History-Info header for informational purposes only. They are not
intended to be normative. In many cases, only the relevant messaging
details are included in the body of the call flow.
3.1. Automatic Call Distribution
This scenario highlights an example of an Automatic Call Distribution
service, where the agents are divided into groups based upon the type
of customers they handle. In this example, the Gold customers are
given higher priority than Silver customers, so a Gold call would get
serviced even if all the agents servicing the Gold group were busy,
by retargeting the request to the Silver Group for delivery to an
agent. Upon receipt of the call at the agent assigned to handle the
incoming call, based upon the History-Info header in the message, the
application at the agent can provide an indication that this is a
Gold call by extracting the hi-entry associated with the incoming
request which is determined by locating the hi-entry whose index is
reflected in the first hi-entry with an hi-target of "mp". An
application can also determine how many groups from which the call
may have overflowed before reaching the agent, etc. and present the
information to the agent so that the call can be handled
appropriately by the agent - i.e., "I'm so sorry for the delay, blah,
blah, blah..."
For scenarios whereby calls might overflow from the Silver to the
Barnes, et al. Expires December 26, 2010 [Page 3]
Internet-Draft History-Info Call Flows June 2010
Gold, clearly the alternate group identification, internal routing,
or actual agent that handles the call should not be sent to UA1.
Thus, for this scenario, one would expect that the Proxy would not
support the sending of the History-Info in the response, even if
requested by Alice.
As with the other examples, this is not a complete prescription of
how one would do this type of service but an example of a subset of
processing that might be associated with such a service. In
addition, this example is not addressing any aspects of Agent
availability resulting in the call being sent to an agent in another
group, which might also be done via a SIP interface.
Alice example.com Gold Silver Agent
| | | | |
| INVITE sip:Gold@example.com | | |
|------------->| | | |
| Supported: histinfo
| | | | |
| | INVITE sip:Gold@example.com |
| |------------->| | |
History-Info: <sip:Gold@example.com>;index=1
History-Info: <sip:Gold@gold.example.com>;index=1.1
| | | | |
| | 302 Moved Temporarily | |
| |<-------------| | |
History-Info: <sip:Gold@example.com>;index=1
History-Info: <sip:Gold@gold.example.com?Reason=SIP;cause=302>;\
index=1.1
Contact: <sip:Silver@example.com>
| | | |
| | INVITE sip:Silver@example.com |
| |--------------------------->| |
History-Info: <sip:Gold@example.com>;index=1
History-Info: <sip:Gold@gold.example.com?Reason=SIP;cause=302>;\
index=1.1
History-Info: <sip:Silver@example.com>;index=2;mp=1
History-Info: <sip:Silver@silver.example.com>;index=2.1
| | | | |
| | | INVITE sip:Silver@192.0.2.7
| | | |----------->|
History-Info: <sip:Gold@example.com>;index=1
History-Info: <sip:Gold@gold.example.com?Reason=SIP;cause=302>;\
index=1.1
History-Info: <sip:Silver@example.com>;index=2;mp=1
History-Info: <sip:Silver@silver.example.com>;index=2.1
History-Info: <sip:Silver@192.0.2.7>;index=2.1.1;rc
Barnes, et al. Expires December 26, 2010 [Page 4]
Internet-Draft History-Info Call Flows June 2010
| | | | |
| | | | 200 OK |
| | | |<-----------|
History-Info: <sip:Gold@example.com>;index=1
History-Info: <sip:Gold@gold.example.com?Reason=SIP;cause=302>;\
index=1.1
History-Info: <sip:Silver@example.com>;index=2;mp=1
History-Info: <sip:Silver@silver.example.com>;index=2.1
History-Info: <sip:Silver@192.0.2.7>;index=2.1.1;rc
| | | | |
| | 200 OK | |
| |<---------------------------| |
History-Info: <sip:Gold@example.com>;index=1
History-Info: <sip:Gold@gold.example.com?Reason=SIP;cause=302>;\
index=1.1
History-Info: <sip:Silver@example.com>;index=2;mp=1
History-Info: <sip:Silver@silver.example.com>;index=2.1
History-Info: <sip:Silver@192.0.2.7>;index=2.1.1;rc
| | | | |
200 OK | | | |
|<-------------| | | |
| | | | |
| ACK | | | |
|------------->| ACK |
| |---------------------------------------->|
3.2. Determining the Alias used.
SIP user agents are associated with an address-of-record (AOR). It
is possible for a single UA to actually have multiple AORs associated
with it. One common usage for this is aliases. For example, a user
might have an AOR of sip:john@example.com but also have the AORs
sip:john.smith@example.com and sip:jsmith@example.com. Rather than
registering against each of these AORs individually, the user would
register against just one of them, and the home proxy would
automatically accept incoming calls for any of the aliases, treating
them identically and ultimately forwarding them towards the UA. This
is common practice in the Internet Multimedia Subsystem (IMS), where
it is called implicit registration and each alias is called a public
identity.
It is a common requirement for a UAS, on receipt of a call, to know
which of its aliases was used to reach it. This knowledge can be
used to choose ringtones to play, determine call treatment, and so
on. For example, a user might give out one alias to friends and
family only, resulting in a special ring that alerts the user to the
importance of the call.
Barnes, et al. Expires December 26, 2010 [Page 5]
Internet-Draft History-Info Call Flows June 2010
The following call-flow and example messages show how History-Info
can be used to find out the alias used to reach the callee. The
alias for the call is determined by the UAS extracting the hi-entry
prior to the last hi-entry with the "rc" tag.
Alice Example.com John
| | REGISTER F1 |
| |<--------------------|
| | 200 OK F2 |
| |-------------------->|
| INVITE F3 | |
|-------------------->| |
| | INVITE F4 |
| |-------------------->|
* Rest of flow not shown *
F1 REGISTER John -> Example.com
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7
Max-Forwards: 70
From: John <sip:john@example.com>;tag=a73kszlfl
To: John <sip:john@example.com>
Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
CSeq: 1 REGISTER
Contact: <sip:john@192.0.2.1>
Content-Length: 0
F2 200 OK Example.com -> John
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7
From: John <sip:john@example.com>;tag=a73kszlfl
To: John <sip:john@example.com>
Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
CSeq: 1 REGISTER
Contact: <sip:john@192.0.2.1>;expires=3600
Content-Length: 0
F3 INVITE Alice -> Example.com
INVITE sip:john.smith@example.com SIP/2.0
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>
To: John <sip:john.smith@example.com>
Supported: histinfo
Call-Id: 12345600@example.com
Barnes, et al. Expires December 26, 2010 [Page 6]
Internet-Draft History-Info Call Flows June 2010
CSeq: 1 INVITE
History-Info: <sip:john.smith@example.com>;index=1;
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate value>
[SDP Not Shown]
F4 INVITE Example.com -> Bob
INVITE sip:john@192.0.2.1 SIP/2.0
Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>
To: John <sip:john.smith@example.com>
Supported: histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
Record-Route: <sip:proxy.example.com;lr>
History-Info: <sip:john.smith@example.com>;index=1;
History-Info: <sip:john@192.0.2.1>;index=1.1;rc
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate value>
[SDP Not Shown]
Figure 1: Alias Example
3.3. PBX Voicemail Example
A typical use case for voicemail is one whereby the original called
party is not reachable and the call arrives at a voicemail system.
In some cases multiple alternate destinations may be tried without
success. The voicemail system typically requires the original called
party information to determine the appropriate mailbox so an
appropriate greeting can be provided and the appropriate party
notified of the message.
In this example, Alice calls Bob, whose SIP client is forwarded to
Carol. Carol does not answer the call, thus it is forwarded to a VM
(voicemail) server (VMS). In order to determine the appropriate
mailbox to use for this call, the VMS needs the original target for
the request. The original target is determined by finding the first
hi-entry tagged with "rc" and using the hi-entry just prior as the
target for determining the appropriate mailbox. This hi-entry is
used to populate the "target" URI parameter as defined in [RFC4458].
Barnes, et al. Expires December 26, 2010 [Page 7]
Internet-Draft History-Info Call Flows June 2010
The reason associated with the first entry tagged with "rc" (i.e.,
302) could be used to provide a customized voicemail greeting and is
used to populate the "cause" URI parameter as defined in [RFC4458].
Note that some VMSs may also (or instead) use the information
available in the History-Info headers for custom handling of the VM
in terms of how and why the called arrived at the VMS.
Alice example.com Bob Carol VM
| INVITE sip:bob@example.com | | |
|------------->| | | |
| | INVITE sip:bob@192.0.2.3 | |
| |------------->| | |
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.3>;index=1.1;rc
| | | | |
| 100 Trying | | | |
|<-------------| 302 Moved Temporarily | |
| |<-------------| | |
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.3>; index=1.1;rc
Contact: <sip:carol@example.com>
| | | | |
| | INVITE sip:Carol@192.0.2.4 | |
| |--------------------------->| |
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.3?Reason=SIP;cause=302>;\
index=1.1;rc
History-Info: <sip:carol@example.com>;index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc
| | | | |
| | 180 Ringing | |
| |<---------------------------| |
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.3?Reason=SIP;cause=302>;\
index=1.1;rc
History-Info: <sip:carol@example.com>;index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc
| | | | |
| 180 Ringing | | | |
|<-------------| | | |
| | | | |
| . . . | | | |
| | (timeout) | |
| | | | |
| | INVITE sip:vm@192.0.2.5;\
| | target=sip:bob@example.com>;\
| | cause=302
Barnes, et al. Expires December 26, 2010 [Page 8]
Internet-Draft History-Info Call Flows June 2010
| |-------------------------------------->|
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.3?Reason=SIP;cause=302>;\
index=1.1;rc
History-Info: <sip:carol@example.com>;index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc
History-Info: <sip:vm@example.com>;\
target=sip:bob@example.com;cause=302>\
index=1.3;mp=1.2
History-Info: <sip:vm@192.0.2.5>;\
target=sip:bob@example.com;cause=302>\
index=1.3.1
| | | | |
| | 200 OK |
| |<--------------------------------------|
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.3?Reason=SIP;cause=302>;\
index=1.1;rc
History-Info: <sip:carol@example.com>;index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc
History-Info: <sip:vm@example.com>;\
target=sip:bob@example.com;cause=302>\
index=1.3;mp=1.2
History-Info: <sip:vm@192.0.2.5>;
target=sip:bob@example.com;cause=302>\
index=1.3.1
| 200 OK | | | |
|<-------------| | | |
| | | | |
| ACK | | | |
|------------->| ACK |
| |-------------------------------------->|
3.4. Call Center Voicemail Example
In the case a call centers, where the original called number does not
necessarily represent a specific individual, but rather is associated
with a set of individuals, any of whom would handle an incoming call
in much the same manner (e.g., insurance company representatives).
In some cases multiple alternate destinations may be tried without
success. The voicemail system typically requires the original called
party information to determine the appropriate mailbox so an
appropriate greeting can be provided and the appropriate party
notified of the message.
In this example, Alice calls the direct number for her insurance
agent. Bob has temporarily forwarded his phone to Carol because she
Barnes, et al. Expires December 26, 2010 [Page 9]
Internet-Draft History-Info Call Flows June 2010
is the co-worker assigned as his backup. Carol does not answer the
call, thus it is forwarded to a VM (voicemail) server (VMS). In
order to determine the appropriate mailbox to use for this call, the
VMS needs the appropriate target for the request. The original
target is determined by finding the last hi-entry tagged with "rc"
and using the hi-entry just prior as the target for determining the
appropriate mailbox. This hi-entry is used to populate the "target"
URI parameter as defined in [RFC4458]. Note that some VMSs may also
(or instead) use the information available in the History-Info
headers for custom handling of the VM in terms of how and why the
called arrived at the VMS.
Alice example.com Bob Carol VM
| INVITE sip:bob@example.com | | |
|------------->| | | |
| | INVITE sip:bob@192.0.2.3 | |
| |------------->| | |
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.3>;index=1.1;rc
| | | | |
| 100 Trying | | | |
|<-------------| 302 Moved Temporarily | |
| |<-------------| | |
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.3>; index=1.1;rc
Contact: <sip:carol@example.com>
| | | | |
| | INVITE sip:Carol@192.0.2.4 | |
| |--------------------------->| |
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.3?Reason=SIP;cause=302>;\
index=1.1;rc
History-Info: <sip:carol@example.com>;index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc
| | | | |
| | 180 Ringing | |
| |<---------------------------| |
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.3?Reason=SIP;cause=302>;\
index=1.1;rc
History-Info: <sip:carol@example.com>;index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc
| | | | |
| 180 Ringing | | | |
|<-------------| | | |
| | | | |
| . . . | | | |
Barnes, et al. Expires December 26, 2010 [Page 10]
Internet-Draft History-Info Call Flows June 2010
| | (timeout) | |
| | | | |
| | INVITE sip:vm@192.0.2.5;\
| | target=sip:carol@example.com
| |-------------------------------------->|
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.3?Reason=SIP;cause=302>;\
index=1.1;rc
History-Info: <sip:carol@example.com>;index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc
History-Info: <sip:vm@example.com;
target=sip:carol@example.com>;\
index=1.3;mp=1.2
History-Info: <sip:vm@192.0.2.5;\
target=sip:carol@example.com>;\
index=1.3.1
| | | | |
| | 200 OK |
| |<--------------------------------------|
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.3?Reason=SIP;cause=302>;\
index=1.1;rc
History-Info: <sip:carol@example.com>;index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc
History-Info: <sip:vm@example.com;\
target=sip:carol@example.com>;\
index=1.3;mp=1.2
History-Info: <sip:vm@192.0.2.5>;
target=sip:carol@example.com>;\
index=1.3.1
| 200 OK | | | |
|<-------------| | | |
| | | | |
| ACK | | | |
|------------->| ACK |
| |-------------------------------------->|
3.5. GRUU
A variation on the problem in Section 3.2 occurs with Globally
Routable User Agent URI (GRUU) [RFC5627]. A GRUU is a URI assigned
to a UA instance which has many of the same properties as the AOR,
but causes requests to be routed only to that specific instance. It
is desirable for a UA to know whether it was reached because a
correspondent sent a request to its GRUU or to its AOR. This can be
used to drive differing authorization policies on whether the request
should be accepted or rejected, for example. However, like the AOR
Barnes, et al. Expires December 26, 2010 [Page 11]
Internet-Draft History-Info Call Flows June 2010
itself, the GRUU is lost in translation at the home proxy. Thus, the
UAS cannot know whether it was contacted via the GRUU or its AOR.
Following call-flow and example messages show how History-Info can be
used to find out the GRUU used to reach the callee.
GRUU is merely an AoR with a URI parameter that distinguishes the
target instance, and as any URI parameters are preserved in history-
info as Request-URI is trasnlated, UA can see if the request was
addressed to a specific instance (gruu) by evaluating the presence of
"gr" parameter in the hi-entry prior to the last hi-entry with the
"rc" tag.
Alice Example.com John
| | REGISTER F1 |
| |<--------------------|
| | 200 OK F2 |
| |-------------------->|
| INVITE F3 | |
|-------------------->| |
| | INVITE F4 |
| |-------------------->|
* Rest of flow not shown *
F1 REGISTER John -> Example.com
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7
Max-Forwards: 70
From: John <sip:John@example.com>;tag=a73kszlfl
Supported: gruu
To: John <sip:john@example.com>
Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
CSeq: 1 REGISTER
Contact: <sip:john@192.0.2.1>
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
Content-Length: 0
F2 200 OK Example.com -> John
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7
From: John <sip:john@example.com>;tag=a73kszlfl
To: John <sip:john@example.com> ;tag=b88sn
Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
CSeq: 1 REGISTER
Contact: <sip:john@192.0.2.1>
;pub-gruu="sip:john@example.com
Barnes, et al. Expires December 26, 2010 [Page 12]
Internet-Draft History-Info Call Flows June 2010
;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
;temp-gruu=
"sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr"
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
;expires=3600
Content-Length: 0
Assuming Alice has a knowledge of a gruu either through
prior communication or through other means such as presence
places a call to John's gruu.
F3 INVITE Alice -> Example.com
INVITE sip:john@example.com
;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>;tag=kkaz-
To: <sip:john@example.com
;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>
Supported: gruu, histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
History-Info: <sip:john@example.com
;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;index=1
Contact: Alice <sip:alice@192.0.2.3>
Content-Length: <appropriate value>
F4 INVITE Example.com -> John
INVITE sip:john@192.0.2.1 SIP/2.0
Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>;tag=kkaz-
To: John <sip:john@example.com>
Supported: gruu, histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
Record-Route: <sip:proxy.example.com;lr>
History-Info: <sip:john@example.com
;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;index=1
History-Info: <sip:john@192.0.2.1>;index=1.1;rc
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate value>
Figure 2: GRUU Example
Barnes, et al. Expires December 26, 2010 [Page 13]
Internet-Draft History-Info Call Flows June 2010
3.6. Limited Use Address
A limited use address is a SIP URI that is minted on-demand, and
passed out to a small number (usually one) remote correspondent.
Incoming calls targeted to that limited use address are accepted as
long as the UA still desires communications from the remote target.
Should they no longer wish to be bothered by that remote
correspondent, the URI is invalidated so that future requests
targeted to it are rejected.
Limited use addresses are used in battling voice spam [RFC5039]. The
easiest way to provide them would be for a UA to be able to take its
AOR, and "mint" a limited use address by appending additional
parameters to the URI. It could then give out the URI to a
particular correspondent, and remember that URI locally. When an
incoming call arrives, the UAS would examine the parameter in the URI
and determine whether or not the call should be accepted.
Alternatively, the UA could push authorization rules into the
network, so that it need not even see incoming requests that are to
be rejected.
This approach, especially when executed on the UA, requires that
parameters attached to the AOR, but not used by the home proxy in
processing the request, will survive the translation at the home
proxy and be presented to the UA. This will not be the case with the
logic in RFC 3261, since the Request-URI is replaced by the
registered contact, and any such parameters are lost.
Using the history-info John's UA can easily see if the call was
addressed to its AoR, GRUU or a temp-gruu and treat the call
accordingly by looking at the hi-entry prior to the last hi-entry
with the "rc" tag.
Alice Example.com John
| | REGISTER F1 |
| |<--------------------|
| | 200 OK F2 |
| |-------------------->|
| INVITE F3 | |
|-------------------->| |
| | INVITE F4 |
| |-------------------->|
* Rest of flow not shown *
F1 REGISTER John -> Example.com
REGISTER sip:example.com SIP/2.0
Barnes, et al. Expires December 26, 2010 [Page 14]
Internet-Draft History-Info Call Flows June 2010
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7
Max-Forwards: 70
From: John <sip:John@example.com>;tag=a73kszlfl
Supported: gruu
To: John <sip:john@example.com>
Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
CSeq: 1 REGISTER
Contact: <sip:john@192.0.2.1>
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
Content-Length: 0
F2 200 OK Example.com -> John
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7
From: John <sip:john@example.com>;tag=a73kszlfl
To: John <sip:john@example.com> ;tag=b88sn
Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
CSeq: 1 REGISTER
Contact: <sip:john@192.0.2.1>
;pub-gruu="sip:john@example.com
;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
;temp-gruu=
"sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr"
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
;expires=3600
Content-Length: 0
Assuming Alice has a knowledge of a temp-gruu, she places a
call to the temp-gruu.
F3 INVITE Alice -> Example.com
INVITE sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com
;gr SIP/2.0
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>;tag=kkaz-
To: <sip:sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com
;gr>
Supported: gruu, histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
History-Info:
<sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr>
;index=1
Contact: Alice <sip:alice@192.0.2.3>
Content-Length: <appropriate value>
Barnes, et al. Expires December 26, 2010 [Page 15]
Internet-Draft History-Info Call Flows June 2010
F4 INVITE Example.com -> John
INVITE sip:john@192.0.2.1 SIP/2.0
Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>;tag=kkaz-
To: John <sip:john@example.com>
Supported: gruu, histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
Record-Route: <sip:proxy.example.com;lr>
History-Info:
<sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr>
;index=1
History-Info: <sip:john@192.0.2.1>;index=1.1;rc
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate value>
Figure 3: Limited Use Address Example
3.7. Sub-Address
Sub-Addressing is very similar to limited use addresses. Sub-
addresses are addresses within a subdomain that are multiplexed into
a single address within a parent domain. The concept is best
illustrated by example. Consider a VoIP service provided to
consumers. A consumer obtains a single address from its provider,
say sip:family@example.com. However, Joe is the patriarch of a
family with four members, and would like to be able to have a
separate identifier for each member of his family. One way to do
that, without requiring Joe to purchase new addresses for each member
from the provider, is for Joe to mint additional URI by adding a
parameter to the AOR. For example, his wife Judy with have the URI
sip:family@example.com;member=judy, and Joe himself would have the
URI sip:family@example.com;member=joe. The SIP server provider would
receive requests to these URI, and ignoring the unknown parameters
(as required by [RFC3261]) route the request to the registered
contact, which corresponds to a SIP server in Joes home. That
server, in turn, can examine the URI parameters and determine which
phone in the home to route the call to.
This feature is not specific to VoIP, and has existing in Integrated
Services Digital Networking (ISDN) for some time. It is particularly
useful for small enterprises, in addition to families. It is also
similar in spirit (though not mechanism) to the ubiquitous home
routers used by consumers, which allow multiple computers in the home
Barnes, et al. Expires December 26, 2010 [Page 16]
Internet-Draft History-Info Call Flows June 2010
to "hide" behind the single IP address provided by the service
provider, by using the TCP and UDP port as a sub-address.
The sub-addressing feature is not currently feasible in SIP because
of the fact that any SIP URI parameter used to convey the sub-address
would be lost at the home proxy, due to the fact that the Request-URI
is rewritten there.
Call-flow and example messages below show the how History-Info can be
used to deliver the sub-address. UAS or Proxy can determine the sub-
address by looking at the hi-entry prior to the last hi-entry with
the "rc" tag.
Alice Example.com John's Home Judy John
| | REGISTER F1 | | |
| |<-------------| | |
| | 200 OK F2 | | |
| |------------->| | |
| | | REGISTER F3 | |
| | |<-------------| |
| | | 200 OK F4 | |
| | |------------->| |
| | | | REGISTER F5 |
| | |<----------------------------|
| | | | 200 OK F6 |
| | |---------------------------->|
| INVITE F7 | | | |
|----------->| | | |
| | INVITE F8 | | |
| |------------->| | |
| | | INVITE F9 | |
| | |------------->| |
* Rest of flow not shown *
F1 REGISTER John's Home Server -> Example.com
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7
Max-Forwards: 70
From: John <sip:johnhome@example.com>;tag=a73kszlfl
To: John <sip:johnhome@example.com>
Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
CSeq: 1 REGISTER
Contact: <sip:johnhome@192.0.2.1>
Content-Length: 0
F2 200 OK Example.com -> John's Home Server
Barnes, et al. Expires December 26, 2010 [Page 17]
Internet-Draft History-Info Call Flows June 2010
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7
From: John <sip:johnhome@example.com>;tag=a73kszlfl
To: John <sip:johnhome@example.com> ;tag=b88sn
Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
CSeq: 1 REGISTER
Contact: <sip:johnhome@192.0.2.1>;expires=3600
Content-Length: 0
We assume that John's server acts as a proxy allowing
each of the device in the house to register.
F3 REGISTER Judy's phone -> John's Home Server
REGISTER sip:198.51.100.1 SIP/2.0
Via: SIP/2.0/UDP 198.51.100.2;branch=z9hG4bKnasdds
Max-Forwards: 70
From: Judy <sip:judy@198.51.100.1>;tag=a73kszlfl
To: Judy <sip:judy@198.51.100.1>
Call-ID: 12345pLxk3uxtm8tn@198.51.100.2
CSeq: 1 REGISTER
Contact: <sip:judy@198.51.100.2>
Content-Length: 0
F4 200 OK John's Home Server -> Judy's phone
SIP/2.0 200 OK
Via: SIP/2.0/UDP 198.51.100.2;branch=z9hG4bKnashds7
From: Judy <sip:judy@198.51.100.1>;tag=a73kszlfl
To: Judy <sip:judy@198.51.100.1>tag=b88sn
Call-ID: 12345pLxk3uxtm8tn@198.51.100.2
CSeq: 1 REGISTER
Contact: <sip:judy@198.51.100.2>;expires=3600
Content-Length: 0
F5 REGISTER John's phone -> John's Home Server
REGISTER sip:198.52.100.1 SIP/2.0
Via: SIP/2.0/UDP 198.52.100.3;branch=z9hG4bKnasdds
Max-Forwards: 70
From: Judy <sip:john@198.51.100.1>;tag=a73kszlfl
To: Judy <sip:john@198.51.100.1>
Call-ID: 12346pLxk3uxtm8tn@198.51.100.3
CSeq: 1 REGISTER
Contact: <sip:john@198.51.100.3>
Content-Length: 0
F6 200 OK John's Home Server -> John's phone
Barnes, et al. Expires December 26, 2010 [Page 18]
Internet-Draft History-Info Call Flows June 2010
SIP/2.0 200 OK
Via: SIP/2.0/UDP 198.51.100.3;branch=z9hG4bKnashds7
From: John <sip:john@198.51.100.1>;tag=a73kszlfl
To: John <sip:john@198.51.100.1> ;tag=b88sn
Call-ID: 12346pLxk3uxtm8tn@198.51.100.3
CSeq: 1 REGISTER
Contact: <sip:john@198.51.100.3>;expires=3600
Content-Length: 0
F7 INVITE Alice -> Example.com
INVITE sip:johnhome@example.com;member=judy SIP/2.0
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>
To: Judy <sip:johnhome@example.com;member=judy>
Supported: histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
History-Info: <sip:johnhome@example.com;member=judy>;index=1;
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate value>
[SDP Not Shown]
F8 INVITE Example.com -> John's Home
INVITE sip:johnhome@192.0.2.1 SIP/2.0
Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>
To: Judy <sip:johnhome@example.com;member=judy>
Supported: histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
Record-Route: <sip:proxy.example.com;lr>
History-Info: <sip:johnhome@example.com;member=judy>;index=1;
History-Info: <sip:john@192.0.2.1>;index=1.1;rc
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate value>
[SDP Not Shown]
John's Home server can see that the call was addressed to
Judy by evaluating the entry prior to the last entry with the
"rc" tag and forwards the call accordingly.
Barnes, et al. Expires December 26, 2010 [Page 19]
Internet-Draft History-Info Call Flows June 2010
F9 INVITE John's Home -> Judy
INVITE sip:judy@198.51.100.2 SIP/2.0
Via: SIP/2.0/TCP 198.51.100.1:5060;branch=abc2334se
Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>
To: Judy <sip:johnhome@example.com;member=judy>
Supported: histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
Record-Route: <sip:proxy.example.com;lr>
History-Info: <sip:johnhome@example.com;member=judy>;index=1;
History-Info: <sip:john@192.0.2.1>;index=1.1;rc
History-Info: <sip:judy@198.51.100.1>;index=1.1.1;mp=1.1
History-Info: <sip:judy@198.51.100.2>;index=1.1.1.1;rc
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate value>
[SDP Not Shown]
Figure 4: Sub-Address Example
3.8. Service Invocation
Several SIP specifications have been developed which make use of
complex URIs to address services within the network rather than
subscribers. The URIs are complex because they contain numerous
parameters that control the behavior of the service. Examples of
this include the specification which first introduced the concept,
[RFC3087], control of network announcements and IVR with SIP URI
[RFC4240], and control of voicemail access with SIP URI [RFC4458].
A common problem with all of these mechanisms is that once a proxy
has decided to rewrite the Request-URI to point to the service, it
cannot be sure that the Request-URI will not be destroyed by a
downstream proxy which decides to forward the request in some way,
and does so by rewriting the Request-URI.
Section on voicemail (Section 3.3) shows how History-Info can be used
to invocate a service.
3.9. Toll Free Number
Toll free numbers, also known as 800 or 8xx numbers in the United
States, are telephone numbers that are free for users to call.
Barnes, et al. Expires December 26, 2010 [Page 20]
Internet-Draft History-Info Call Flows June 2010
In the telephone network, toll free numbers are just aliases to
actual numbers which are used for routing of the call. In order to
process the call in the PSTN, a switch will perform a query (using a
protocol called TCAP), which will return either a phone number or the
identity of a carrier which can handle the call.
There has been recent work on allowing such PSTN translation services
to be accessed by SIP proxy servers through IP querying mechanisms.
ENUM, for example [RFC3761] has already been proposed as a mechanism
for performing Local Number Portability (LNP) queries [RFC4769], and
recently been proposed for performing calling name queries
[I-D.ietf-enum-cnam]. Using it for 8xx number translations is a
logical next-step.
Once such a translation has been performed, the call needs to be
routed towards the target of the request. Normally, this would
happen by selecting a PSTN gateway which is a good route towards the
translated number. However, one can imagine all-IP systems where the
8xx numbers are SIP endpoints on an IP network, in which case the
translation of the 8xx number would actually be a SIP URI and not a
phone number. Assuming for the moment it is a PSTN connected entity,
the call would be routed towards a PSTN gateway. Proper treatment of
the call in the PSTN (and in particular, correct reconciliation of
billing records) requires that the call be marked with both the
original 8xx number AND the target number for the call. However, in
our example here, since the translation was performed by a SIP proxy
upstream from the gateway, the original 8xx number would have been
lost, and the call will not interwork properly with the PSTN.
Furthermore, even if the translation of the 8xx number was a SIP URI,
the enterprise or user who utilize the 8xx service would like to know
whether the call came in via 8xx number in order to treat the call
differently (for example to play a special announcement..) but if the
original R-URI is lost through translation, there is no way to tell
if the call came in via 8xx number.
Similar problems arise with other "special" numbers and services used
in the PSTN, such as operator services, pay numbers (9xx numbers in
the U.S), and short service codes such as 311.
To find the service number, the UAS can extract the hi-entry whose
index matches the value of the first hi-entry with an "mp" tag.
Technically the call can be forwarded to these "special" numbers from
non "special" numbers, however, that is uncommon based on the way
these services authorize translations.
Alice Toll Free Service Atlanta.com John
| | | |
Barnes, et al. Expires December 26, 2010 [Page 21]
Internet-Draft History-Info Call Flows June 2010
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| |------------->| |
| | | INVITE F3 |
| | |------------------>|
* Rest of flow not shown *
F1: INVITE 192.0.2.1 -> proxy.example.com
INVITE sip:+18005551002@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+18005551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Supported: histinfo
History-Info: <sip:+18005551002@example.com;user=phone >;index=1
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: <appropriate value>
[SDP Not Shown]
F2: INVITE proxy.example.com -> atlanta.com
INVITE sip:+15555551002@atlanta.com SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+18005551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Supported: histinfo
History-Info: <sip:+18005551002@example.com;user=phone >;index=1,
<sip:+15555551002@atlanta.com>;index=1.1;mp=1
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: <appropriate value>
[SDP Not Shown]
F3: INVITE atlanta.com -> Joe
INVITE sip:joe@198.51.100.2 SIP/2.0
Via: SIP/2.0/TCP 198.51.100.1:5060;branch=z9hG4bK-pxk7g-3
Barnes, et al. Expires December 26, 2010 [Page 22]
Internet-Draft History-Info Call Flows June 2010
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+18005551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Supported: histinfo
History-Info: <sip:+18005551002@example.com;user=phone >;index=1,
<sip:+15555551002@atlanta.com>;index=1.1;mp=1,
<sip:joe@atlanta.com>;index=1.1.1;mp=1.1,
<sip:joe@198.51.100.2>;index=1.1.2;rc
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: <appropriate value>
[SDP Not Shown]
Figure 5: Service Number Example
4. Security Considerations
The security considerations for the History-Info header are specified
in [I-D.ietf-sipcore-rfc4244bis].
5. IANA Considerations
This document has no IANA considerations.
5.1. Acknowledgements
Jonathan Rosenberg et al produced the document that provided
additional use cases precipitating the requirement for the new
"target" parameter in the History-Info header and the new SIP/SIPS
URI parameter.
6. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User
Barnes, et al. Expires December 26, 2010 [Page 23]
Internet-Draft History-Info Call Flows June 2010
Agent URIs (GRUUs) in the Session Initiation Protocol
(SIP)", RFC 5627, October 2009.
[RFC3087] Campbell, B. and R. Sparks, "Control of Service Context
using SIP Request-URI", RFC 3087, April 2001.
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
Media Services with SIP", RFC 4240, December 2005.
[RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation
Protocol (SIP) and Spam", RFC 5039, January 2008.
[RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session
Initiation Protocol (SIP) URIs for Applications such as
Voicemail and Interactive Voice Response (IVR)", RFC 4458,
April 2006.
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
Resource Identifiers (URI) Dynamic Delegation Discovery
System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[RFC4769] Livingood, J. and R. Shockey, "IANA Registration for an
Enumservice Containing Public Switched Telephone Network
(PSTN) Signaling Information", RFC 4769, November 2006.
[I-D.ietf-enum-cnam]
Shockey, R., "IANA Registration for an Enumservice Calling
Name Delivery (CNAM) Information and IANA Registration for
URI type 'pstndata'", draft-ietf-enum-cnam-08 (work in
progress), September 2008.
[I-D.ietf-sipcore-rfc4244bis]
Barnes, M., Audet, F., Schubert, S., Netherlands, T., and
C. Holmberg, "An Extension to the Session Initiation
Protocol (SIP) for Request History Information",
draft-ietf-sipcore-rfc4244bis-00 (work in progress),
February 2010.
Authors' Addresses
Mary Barnes
Polycom
TX
US
Email: mary.ietf.barnes@gmail.com
Barnes, et al. Expires December 26, 2010 [Page 24]
Internet-Draft History-Info Call Flows June 2010
Francois Audet
Skype
Email: francois.audet@skype.net
Shida Schubert
NTT
Email: shida@agnada.com
Hans Erik van Elburg
Detecon International Gmbh
Oberkasseler str. 2
Bonn,
Germany
Email: ietf.hanserik@gmail.com
Christer Holmberg
Ericsson
Hirsalantie 11, Jorvas
Finland
Email: christer.holmberg@ericsson.com
Barnes, et al. Expires December 26, 2010 [Page 25]
| PAFTECH AB 2003-2026 | 2026-04-23 04:12:21 |