One document matched: draft-barnes-sipcore-rfc4244bis-callflows-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "http://xml.resource.org/authoring/rfc2629.dtd" [
<!ENTITY rfc3326 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3326.xml">
<!ENTITY rfc3323 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3323.xml">
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc4244 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4244.xml">
<!ENTITY rfc5630 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5630.xml">
<!ENTITY rfc3969 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3969.xml">
<!ENTITY rfc3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY rfc3665 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3665.xml">
<!ENTITY rfc5627 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5627.xml">
<!ENTITY rfc3087 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3087.xml">
<!ENTITY rfc4240 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4240.xml">
<!ENTITY rfc5039 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5039.xml">
<!ENTITY rfc4458 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4458.xml">
<!ENTITY rfc3761 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3761.xml">
<!ENTITY rfc4769 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4769.xml">
<!ENTITY I-D.ietf-enum-cnam SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-enum-cnam.xml">
<!ENTITY I-D.ietf-sipcore-rfc4244bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sipcore-rfc4244bis">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no"?>
<?rfc sortrefs="no" ?>
<rfc category="info" docName="draft-barnes-sipcore-rfc4244bis-callflows-01.txt"
ipr="trust200902" >
<front>
<title abbrev="History-Info Call Flows "> Session Initiation
Protocol (SIP) History-Info Header Call Flow Examples </title>
<author fullname="Mary Barnes" initials="M." surname="Barnes">
<organization>Polycom</organization>
<address>
<postal>
<street></street>
<city></city>
<region>TX</region>
<code></code>
<country>US</country>
</postal>
<email>mary.ietf.barnes@gmail.com</email>
</address>
</author>
<author fullname="Francois Audet" initials="F." surname="Audet">
<organization>Skype</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>francois.audet@skype.net</email>
</address>
</author>
<author fullname="Shida Schubert" initials="S.S." surname="Schubert">
<organization>NTT</organization>
<address>
<postal>
<street></street>
<city></city>
<region>Tokyo</region>
<country>Japan</country>
</postal>
<email>shida@ntt-at.com</email>
</address>
</author>
<author fullname="Hans Erik van Elburg" initials="J.F.J."
surname="van Elburg">
<organization>
Detecon International Gmbh
</organization>
<address>
<postal>
<street>
Oberkasseler str. 2
</street>
<city>
Bonn
</city>
<region></region>
<country>
Germany
</country>
</postal>
<email>ietf.hanserik@gmail.com</email>
</address>
</author>
<author fullname="Christer Holmberg" initials="C.H." surname="Holmberg">
<organization>Ericsson</organization>
<address>
<postal>
<street></street>
<city>Hirsalantie 11</city>
<region>Jorvas</region>
<country>Finland</country>
</postal>
<email>christer.holmberg@ericsson.com</email>
</address>
</author>
<date day="13" month="Mar" year="2011" />
<abstract>
<t>This document describes use cases and documents call flows which
require the History-Info header field 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.
</t>
</abstract>
</front>
<middle>
<section title="Overview">
<t>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 <xref target="I-D.ietf-sipcore-rfc4244bis"/> for example applications and
common scenarios. The optional "rc" and "mp" header field parameters defined in <xref target="I-D.ietf-sipcore-rfc4244bis"/>
are required for several of the use cases. Descriptions of the example use cases,
call flow diagrams and messaging details are provided. </t>
</section>
<section title="Conventions and Terminology">
<t>The term "retarget" is used as defined in <xref target="I-D.ietf-sipcore-rfc4244bis"/>.
The terms "location service", "redirect", "redirect" and "AOR" are used consistent with
the terminology in <xref target="RFC3261"></xref>.</t>
</section>
<section anchor="callflows" title="Detailed call flows">
<t>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.</t>
<section anchor="acd" title="Automatic Call Distribution">
<t>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".
In the example this would be the hi-entry referenced by the value of
the last "mp" header field parameter -i.e., the hi-entry containing an index of "1".
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..."</t>
<t>For scenarios whereby calls might overflow from the Silver to the
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.</t>
<t>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.</t>
<figure>
<artwork><![CDATA[
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>;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%3BSIP%3Dcause%3B302>;\
index=1.1
History-Info: <sip:Silver@example.com>;index=1.2;mp=1
History-Info: <sip:Silver@silver.example.com>;index=1.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%3BSIP%3Dcause%3B302>;\
index=1.1
History-Info: <sip:Silver@example.com>;index=1.2;mp=1
History-Info: <sip:Silver@silver.example.com>;index=1.2.1
History-Info: <sip:Silver@192.0.2.7>;index=1.2.1.1;rc=1.2.1
| | | | |
| | | | 200 OK |
| | | |<-----------|
History-Info: <sip:Gold@example.com>;index=1
History-Info: <sip:Gold@gold.example.com?Reason%3BSIP%3Dcause%3B302>;\
index=1.1
History-Info: <sip:Silver@example.com>;index=1.2;mp=1
History-Info: <sip:Silver@silver.example.com>;index=1.2.1
History-Info: <sip:Silver@192.0.2.7>;index=1.2.1.1;rc=1.2.1
| | | | |
| | 200 OK | |
| |<---------------------------| |
History-Info: <sip:Gold@example.com>;index=1
History-Info: <sip:Gold@gold.example.com?Reason%3BSIP%3Dcause%3B302>;\
index=1.1
History-Info: <sip:Silver@example.com>;index=1.2;mp=1
History-Info: <sip:Silver@silver.example.com>;index=1.2.1
History-Info: <sip:Silver@192.0.2.7>;index=1.2.1.1;rc=1.2.1
| | | | |
200 OK | | | |
|<-------------| | | |
| | | | |
| ACK | | | |
|------------->| ACK |
| |---------------------------------------->|
]]></artwork>
</figure>
<t>The last hi-entry with the "mp" header field parameter contains a
"mp" header field parameter value of 1 which points to the original-target
which allows the operator to identify that the call was from
the "Gold" customer.</t>
</section>
<section anchor="sec-solvealias" title="Determining the Alias used.">
<t>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.</t>
<t>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.</t>
<t>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 hi-entry with the index that matches
the value of the last hi-entry with a "rc" header field parameter
in the Request received.</t>
<figure anchor="fig-alias" title="Alias Example">
<artwork><![CDATA[
Alice example.com Agent1 Agent2
| | | |
| | REGISTER |
| |<------------------------------------|
| | 200 OK |
| |------------------------------------>|
| INVITE sip:john.smith@example.com | |
|-------------------->| | |
| | INVITE | |
| |-------------------->| |
History-Info: <sip:john.smith@example.com>;index=1;
History-Info: <sip:john@192.0.2.1>;index=1.1;rc=1;
| | 180 Ringing | |
| |<--------------------| |
History-Info: <sip:john.smith@example.com>;index=1;
History-Info: <sip:john@192.0.2.1>;index=1.1;rc=1;
| 180 Ringing | | |
|<--------------------| | |
History-Info: <sip:john.smith@example.com>;index=1;
History-Info: <sip:john@192.0.2.1>;index=1.1;rc=1;
| | (Time out) | |
| | INVITE |
| |------------------------------------>|
History-Info: <sip:john.smith@example.com>;index=1;
History-Info: <sip:john@192.0.2.1?Reason%3BSIP%3Dcause%3B408>;index=1.1;rc=1;
History-Info: <sip:john@192.0.2.5>;index=1.2;rc=1;
| | | |
* Rest of flow not shown *
]]></artwork>
</figure>
<t>The last hi-entry with the "rc" header field parameter references the
source of retargeting pointing at the alias AoR, which in the example
is "john.smith@example.com".
</t>
</section>
<section anchor="voicemail" title="PBX Voicemail Example">
<t>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. </t>
<t>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 referenced by the
index of "rc" header field parameter as
the target for determining the appropriate mailbox. This hi-entry is used to populate the
"target" URI parameter as defined in <xref target="RFC4458"/>.
The reason associated with the first
hi-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 <xref target="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 call arrived at the VMS. </t>
<t>Furthermore it is the proxy forwarding the call to VMS that determines the
target of the voicemail, it is the proxy that sets the target of voicemail which
is also the entity that utilizes RFC4244bis to find the target which is usually
based on local policy installed by the user or an administrator.</t>
<figure>
<artwork><![CDATA[
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=1
| | | | |
| 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=1
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%3BSIP%3Dcause%3B302>;\
index=1.1;rc=1
History-Info: <sip:carol@example.com>;index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc=1.2
| | | | |
| | 180 Ringing | |
| |<---------------------------| |
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.3?Reason%3BSIP%3Dcause%3B302>;\
index=1.1;rc=1
History-Info: <sip:carol@example.com>;index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc=1.2
| | | | |
| 180 Ringing | | | |
|<-------------| | | |
| | | | |
| . . . | | | |
| | (timeout) | |
| | | | |
| | INVITE sip:vm@192.0.2.5;\
| | target=sip:bob@example.com>;\
| | cause=408
| |-------------------------------------->|
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.3?Reason%3BSIP%3Dcause%3B302>;\
index=1.1;rc=1
History-Info: <sip:carol@example.com>;index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4?Reason%3BSIP%3Dcause%3B408>;\
index=1.2.1;rc=1.2
History-Info: <sip:vm@example.com;\
target=sip:bob@example.com;cause=408>\
index=1.3;mp=1.2
History-Info: <sip:vm@192.0.2.5;\
target=sip:bob@example.com;cause=408>\
index=1.3.1
| | | | |
| | 200 OK |
| |<--------------------------------------|
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.3?Reason%3BSIP%3Dcause%3B302>;\
index=1.1;rc=1
History-Info: <sip:carol@example.com>;index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4?Reason%3BSIP%3Dcause%3B408>;\
index=1.2.1;rc=1.2
History-Info: <sip:vm@example.com;\
target=sip:bob@example.com;cause=408>\
index=1.3;mp=1.2
History-Info: <sip:vm@192.0.2.5;\
target=sip:bob@example.com;cause=408>\
index=1.3.1
| 200 OK | | | |
|<-------------| | | |
| | | | |
| ACK | | | |
|------------->| ACK |
| |-------------------------------------->|
]]></artwork>
</figure>
<t>The VMS can look at the last hi-entry and find the
target of the mailbox by looking at the URI entry in
the "target" URI parameter in the hi-entry.
</t>
</section>
<section anchor="voicemailcc" title="Consumer Voicemail Example">
<t>In the case of a consumer, when the call is retargeted, it is usually to
another administrative domain.
The voicemail
system in these environment typically requires the last called party information to determine
the appropriate mailbox so an appropriate greeting can be provided and the appropriate
party notified of the message. </t>
<t>In this example, Alice calls the Bob but
Bob has temporarily
forwarded his phone to Carol
because she is his wife.
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 last target is determined
by finding the hi-entry referenced by the index of last hi-entry tagged with "rc"
for determining the appropriate mailbox. This hi-entry is used to populate the
"target" URI parameter as defined in <xref target="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. </t>
<figure>
<artwork><![CDATA[
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=1
| | | | |
| 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=1
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%3BSIP%3Dcause%3B302>;\
index=1.1;rc=1
History-Info: <sip:carol@example.com>;index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc=1.2
| | | | |
| | 180 Ringing | |
| |<---------------------------| |
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.3?Reason%3BSIP%3Dcause%3B302>;\
index=1.1;rc=1
History-Info: <sip:carol@example.com>;index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc=1.2
| | | | |
| 180 Ringing | | | |
|<-------------| | | |
| | | | |
| . . . | | | |
| | (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%3BSIP%3Dcause%3B302>;\
index=1.1;rc
History-Info: <sip:carol@example.com?Reason%3BSIP%3Dcause%3B408>;\
index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc=1.2
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%3BSIP%3Dcause%3B302>;\
index=1.1;rc
History-Info: <sip:carol@example.com?Reason%3BSIP%3Dcause%3B408>;\
index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc=1.2
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 |
| |-------------------------------------->|
]]></artwork>
</figure>
<t>The VMS can look at the last hi-entry and find the
target of the mailbox by looking for the "target" URI
parameter in the hi-entry.
</t>
</section>
<section anchor="sec-solvegruu" title="GRUU">
<t>A variation on the problem in <xref target="sec-solvealias"></xref>
occurs with Globally Routable User Agent URI (GRUU) <xref
target="RFC5627"></xref>. 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 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.</t>
<t>Following call-flow and example messages show how History-Info can
be used to find out the GRUU used to reach the callee.</t>
<t>While a GRUU is comprised of an AoR with a URI parameter as defined in
<xref target="RFC5627"></xref> , the GRUU construct itself is not an AoR. Thus, the retargeting
of a request based on a GRUU does not result in the addition of an "rc" header
field parameter to the hi-entry containting the GRUU.
The lack of an "rc" header field parameter in the hi-entries can be a hint that
the source of retargeting is
a GRUU. However, to ensure this is the case, the UAS needs to search for a
"gr" parameter in the hi-entry prior to the last hi-entry. If there
is a GRUU, the URI will always be prior to the last hi-entry as GRUU
doesn not allow multiple instance to be mapped to a contact address.</t>
<figure anchor="fig-gruu" title="GRUU Example">
<artwork><![CDATA[
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
;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
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate value>
]]></artwork>
</figure>
<t>The last hi-entry has no "rc" header field parameter which indicates
that source of retargeting is likely to be a GRUU. UAS can look
for a "gr" URI parameter in the hi-entry prior to the last hi-entry
to ensure it is indeed a GRUU.
</t>
</section>
<section anchor="sec-solvelimit" title="Limited Use Address">
<t>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.</t>
<t>Limited use addresses are used in battling voice spam <xref
target="RFC5039"></xref>. 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.</t>
<t>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.</t>
<t>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 for a "gr" tag in the hi-entry prior to the
last hi-entry.</t>
<figure anchor="fig-luae" title="Limited Use Address Example">
<artwork><![CDATA[
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
;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>
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
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate value>
]]></artwork>
</figure>
<t>The last hi-entry has no "rc" header field parameter which indicates
that source of retargeting is likely to be a GRUU. UAS can look
for a "gr" URI parameter in the hi-entry prior to the last hi-entry
to ensure it is indeed a GRUU. UAS can further diagnose the URI
to see that it's a temp GRUU.
</t>
</section>
<section anchor="sec-solveservice" title="Service Invocation">
<t>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, <xref
target="RFC3087"></xref>, control of network announcements and IVR
with SIP URI <xref target="RFC4240"></xref>, and control of voicemail
access with SIP URI <xref target="RFC4458"></xref>.</t>
<t>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.</t>
<t>Section on <xref target="voicemail">voicemail</xref> shows how
History-Info can be used to invocate a service.</t>
</section>
<section anchor="sec-solvetollfree" title="Toll Free Number">
<t>Toll free numbers, also known as 800 or 8xx numbers in the United
States, are telephone numbers that are free for users to call.</t>
<t>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.</t>
<t>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 <xref target="RFC3761"></xref> has
already been proposed as a mechanism for performing Local Number
Portability (LNP) queries <xref target="RFC4769"></xref>, and recently
been proposed for performing calling name queries <xref
target="I-D.ietf-enum-cnam"></xref>. Using it for 8xx number
translations is a logical next-step.</t>
<t>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.</t>
<t>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.</t>
<t>Similar problems arise with other "special" numbers and services
used in the PSTN, such as operator services, pay/premium numbers (9xx numbers
in the U.S), and short service codes such as 311.</t>
<t>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.</t>
<figure anchor="fig-tollfree" title="Service Number Example">
<artwork><![CDATA[
Alice Toll Free Service Atlanta.com John
| | | |
| 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 -> John
INVITE sip:john@198.51.100.2 SIP/2.0
Via: SIP/2.0/TCP 198.51.100.1:5060;branch=z9hG4bK-pxk7g-3
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:john@atlanta.com>;index=1.1.1,
<sip:john@198.51.100.2>;index=1.1.2;rc=1.1
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: <appropriate value>
[SDP Not Shown]
]]></artwork>
</figure>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>The security considerations for the History-Info header field are specified in <xref
target="I-D.ietf-sipcore-rfc4244bis"></xref>.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document has no IANA considerations.</t>
<section title="Acknowledgements">
<t>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 field and the new
SIP/SIPS URI parameter. Hadriel Kaplan provided some comments.</t>
</section>
</section>
</middle>
<back>
<references title="Informative References">
&rfc3261;
&rfc3326;
&rfc3323;
&rfc2119;
&rfc5246;
&rfc4244;
&rfc5627;
&rfc5630;
&rfc3087;
&rfc4240;
&rfc5039;
&rfc4458;
&rfc3761;
&rfc4769;
&rfc3969;
&I-D.ietf-enum-cnam;
&I-D.ietf-sipcore-rfc4244bis;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:24:13 |