<xs:element name="duration" type="xs:nonNegativeInteger"
minOccurs="0" maxOccurs="1"/>
<xs:element name="replaces" minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:attribute name="call-id" type="xs:string"
use="required"/>
<xs:attribute name="local-tag" type="xs:string"
use="required"/>
<xs:attribute name="remote-tag" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="referred-by" type="tns:nameaddr"
minOccurs="0" maxOccurs="1"/>
<xs:element name="route-set" minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:sequence>
<xs:element name="hop" type="xs:string"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="local" type="tns:participant"
minOccurs="0" maxOccurs="1"/>
<xs:element name="remote" type="tns:participant"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="call-id" type="xs:string"
use="optional"/>
<xs:attribute name="local-tag" type="xs:string"
use="optional"/>
<xs:attribute name="remote-tag" type="xs:string"
use="optional"/>
<xs:attribute name="direction" use="optional">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="initiator"/>
<xs:enumeration value="recipient"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:complexType name="participant">
<xs:sequence>
<xs:element name="identity" type="tns:nameaddr"
minOccurs="0" maxOccurs="1"/>
<xs:element name="target" minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:sequence>
<xs:element name="param" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="pname" type="xs:string"
use="required"/>
<xs:attribute name="pval" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="uri" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="session-description" type="tns:sessd"
minOccurs="0" maxOccurs="1"/>
<xs:element name="cseq" type="xs:nonNegativeInteger"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="nameaddr">
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute name="display-name" type="xs:string"
use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="sessd">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="type" type="xs:string"
use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="state">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="event" use="optional">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="cancelled"/>
<xs:enumeration value="rejected"/>
<xs:enumeration value="replaced"/>
<xs:enumeration value="local-bye"/>
<xs:enumeration value="remote-bye"/>
<xs:enumeration value="error"/>
<xs:enumeration value="timeout"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="code" use="optional">
<xs:simpleType>
<xs:restriction base="xs:positiveInteger">
<xs:minInclusive value="100"/>
<xs:maxInclusive value="699"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:schema>
5. Definition of New Media Feature Parameters
This section defines two new media feature parameters that are useful
as input to user presence, in conferencing applications, and in
applications like the shared-line example described in Section 6.2.
These feature parameters are especially useful in combination with
the dialog package, as they allow an authorized third party to become
aware of these characteristics.
5.1. The "sip.byeless" Parameter
The "sip.byeless" media feature parameter is a new boolean parameter,
defined in this document, that provides a positive indication that
the user agent setting the parameter is unable to terminate sessions
on its own (for example, by sending a BYE request). For example,
continuous announcement services and certain recording services are
unable to determine when it would be desirable to terminate a
session, and therefore they do not have the ability to terminate
sessions at all. Also, many human call centers are configured so
that they never terminate sessions. (This is to prevent call center
agents from accidentally disconnecting the caller). (Note that per
[10], this parameter name must be preceded by a "+" character when
used in a SIP Contact header field.)
Contact: <sip:recording-service@host.example.net>
;automaton;+sip.byeless
5.2. The "sip.rendering" Parameter
The "sip.rendering" media feature parameter is a new string
parameter, defined in this document, that can provide a positive
indication whether the user agent setting the parameter is currently
rendering any of the media it is receiving in the context of a
specific session. It MUST only be used in a Contact header field in
a dialog created using the INVITE request.
This parameter has three legal values: "yes", "no", and "unknown".
The value "yes" indicates positive knowledge that the user agent is
rendering at least one of the streams of media that it is receiving.
The value "no" indicates positive knowledge that the user agent is
rendering none of the media that it is receiving. The value
"unknown" indicates that the user agent does not know whether the
media associated with the session is being rendered (which may be the
case if the user agent is acting as a 3pcc (Third Party Call Control)
[19] controller).
The "sip.rendering" parameter is useful in applications such as
shared appearances, conference status monitoring, or as an input to
user presence.
Contact: <sip:musak-onhold@host.example.net>
;automaton;+sip.rendering="no"
6. Examples
6.1. Basic Example
For example, if a UAC sends an INVITE that looks, in part, like:
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.example.com>
Content-Type: application/sdp
Content-Length: 142
[SDP not shown]
The XML document in a notification from Alice might look like:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0"
state="full"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" direction="initiator">
<state>trying</state>
</dialog>
</dialog-info>
If the following 180 response is received:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@example.com>;tag=456887766
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:bob@host.example.com>
The XML document in a notification might look like:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="1"
state="full"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="456887766"
direction="initiator">
<state>early</state>
</dialog>
</dialog-info>
If it receives a second 180 with a different tag:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@example.com>;tag=hh76a
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:jack@host.example.com>
This results in the creation of a second dialog:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="2"
state="full"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="456887766"
direction="initiator">
<state>early</state>
</dialog>
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="hh76a"
direction="initiator">
<state>early</state>
</dialog>
</dialog-info>
If a 200 OK response is received on the second dialog, the dialog
moves to confirmed:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="3"
state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="hh76a"
direction="initiator">
<state>confirmed</state>
</dialog>
</dialog-info>
32 seconds later, the other early dialog terminates because no 2xx
response has been received for it. This implies that it was
successfully cancelled, and therefore the following notification is
sent:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="4"
state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="hh76a"
direction="initiator">
<state event="cancelled">terminated</state>
</dialog>
</dialog-info>
6.2. Emulating a Shared-Line Phone System
The following example shows how a SIP telephone user agent can
provide detailed state information and also emulate a shared-line
telephone system (the phone "lies" about having a dialog while it is
merely offhook).
Idle:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="full"
entity="sip:alice@example.com">
</dialog-info>
Seized:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="1" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8">
<state>trying</state>
</dialog>
</dialog-info>
Dialing:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="2" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" direction="initiator">
<state>trying</state>
<local>
<identity display="Alice Smith">
sip:alice@example.com
</identity>
<target uri="sip:alice@pc33.example.com"/>
</local>
<remote>
<identity>sip:bob@example.net</identity>
</remote>
</dialog>
</dialog-info>
Ringing:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="3" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="07346y131" direction="initiator">
<state code="180">early</state>
<remote>
<target uri="sip:bobster@host2.example.net"/>
</remote>
</dialog>
</dialog-info>
Answered (by voicemail):
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="4" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="07346y131" direction="initiator">
<state reason="cancelled">terminated</state>
</dialog>
<dialog id="zxcvbnm3" call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="8736347" direction="initiator">
<state code="200">confirmed</state>
<remote>
<target uri="sip:bob-is-not-here@vm.example.net">
<param pname="actor" pval="msg-taker"/>
<param pname="automaton" pval="true"/>
<param pname="+sip.byeless" pval="true"/>
</target>
</remote>
</dialog>
</dialog-info>
Alice would rather talk to Bob’s assistant (Cathy Jones) than to
Bob’s voicemail. She indicates this preference by pressing a key
(perhaps "0" in North America or "9" in Europe). Bob’s voicemail
system then acts on this keypress by transferring [20] Alice’s call
to Cathy’s AOR.
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="5" state="partial"
entity="sip:alice@example.com">
<dialog id="zxcvbnm3" call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="8736347" direction="initiator">
<state reason="replaced">terminated</state>
</dialog>
<dialog id="sfhjsjk12" call-id="o34oii1"
local-tag="8903j4"
remote-tag="78cjkus" direction="receiver">
<state reason="replaced">confirmed</state>
<replaces call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="8736347"/>
<referred-by>
sip:bob-is-not-here@vm.example.net
</referred-by>
<local>
<target uri="sip:alice@pc33.example.com"/>
<param pname="+sip.rendering" pval="yes"/>
</local>
<remote>
<identity display="Cathy Jones">
sip:cjones@example.net
</identity>
<target uri="sip:line3@host3.example.net">
<param pname="actor" pval="attendant"/>
<param pname="automaton" pval="false"/>
</target>
</remote>
</dialog>
</dialog-info>
Alice and Cathy talk, Cathy adds Alice to a local conference:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="6" state="partial"
entity="sip:alice@example.com">
<dialog id="sfhjsjk12" call-id="o34oii1"
local-tag="8903j4"
remote-tag="78cjkus" direction="receiver">
<state>confirmed</state>
<remote>
<target uri="sip:confid-34579@host3.example.net">
<param pname="isfocus" pval="true"/>
</target>
</remote>
</dialog>
</dialog-info>
Alice puts Cathy on hold:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="7" state="partial"
entity="sip:alice@example.com">
<dialog id="sfhjsjk12" call-id="o34oii1"
local-tag="8903j4"
remote-tag="78cjkus" direction="receiver">
<state>confirmed</state>
<local>
<target uri="sip:alice@pc33.example.com"/>
<param pname="+sip.rendering" pval="no"/>
</target>
</local>
</dialog>
</dialog-info>
Cathy hangs up:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="8" state="partial"
entity="sip:alice@example.com">
<dialog id="sfhjsjk12" call-id="o34oii1"
local-tag="8903j4"
remote-tag="78cjkus" direction="receiver">
<state reason="remote-bye">terminated</state>
</dialog>
<dialog id="08hjh1345">
<state>trying</state>
</dialog>
</dialog-info>
Alice hangs up:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="9" state="full"
entity="sip:alice@example.com">
</dialog-info>
6.3. Minimal Dialog Information with Privacy
The following example shows the same user agent providing minimal
information to maintain privacy for services like automatic callback.
Onhook:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="full"
entity="sip:alice@example.com">
</dialog-info>
Offhook: (implementation/policy choice for Alice to transition to
this "state" when "seized", when Trying, when Proceeding, or when
Confirmed.)
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="1" state="full"
entity="sip:alice@example.com">
<dialog id="1">