SIPPING Working Group N. Bishai
Internet-Draft S. Loreto
Intended status: Standards Track Ericsson
Expires: September 3, 2009 A. Haruna
Nokia
March 02, 2009
Updates to Referred-By in the Session Initiation Protocol (SIP).
draft-loreto-sipping-3892bis-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 3, 2009.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
SIP has a mechanism for conveying the identity of the referrer of a
Bishai, et al. Expires September 3, 2009 [Page 1]
Internet-Draft Updates to Referred-By SIP header March 2009
request by means of the Referred-By header field. This header field
may be used when exploding a SIP MESSAGE request to a pre-defined
group URI and when exploding a SIP INVITE request to an ad-hoc group
or to a pre-defined group URI. The Referred-By header is only
included if the P-Asserted-Identity header field or From header field
in the exploded SIP requests needs to carry another value, e.g. the
URI of a pre-defined group, or a conference focus URI. In those
cases, the Referred-By header field in the resulting exploded
requests is set to the P-Asserted-Identity header field or to the
From header field of the original SIP request received before
exploding to convey to the receiver the identity of the original
inviting sender.
RFC 3892 restricts the value of the header to only one SIP URI.
However the P-Asserted-Identity header field currently allows two URI
values and may be expanded in the future to carry more than two
values as described in draft-ietf-sipping-update-pai-09. This
document extends the Referred-By definition to support more than one
value as well.
Bishai, et al. Expires September 3, 2009 [Page 2]
Internet-Draft Updates to Referred-By SIP header March 2009
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Inclusion of URIs in a Referred-By header . . . . . . . . . . 4
4. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Referrer Behaviour . . . . . . . . . . . . . . . . . . . . 5
4.2. General handling . . . . . . . . . . . . . . . . . . . . . 5
5. The Referred-By Header Field . . . . . . . . . . . . . . . . . 5
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security considerations . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informational References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Bishai, et al. Expires September 3, 2009 [Page 3]
Internet-Draft Updates to Referred-By SIP header March 2009
1. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [RFC2119] and indicate requirement
levels for compliant implementations.
2. Introduction
SIP has a mechanism for conveying the identity of the referrer of a
request by means of the Referred-By header field [RFC3892]. This
header field may be used when exploding a SIP MESSAGE request to a
pre-defined group URI and when exploding a SIP INVITE request to an
ad-hoc group or to a pre-defined group URI. The Referred-By header
is only included if the P-Asserted-Identity header field [RFC3325] or
From header field needs to carry another value, e.g. the URI of a
pre-defined group, or a conference focus URI, in the exploded SIP
requests. In those cases, the Referred-By header field in the
resulting exploded requests is set to the P-Asserted-Identity header
field or to the From header field of the original SIP request
received before exploding. However, [RFC3892] restricts the value of
the header to only one SIP URI.
Since RFC 3325 allows the P-Asserted-Identity header field to contain
at most two URIs, where one is SIP or SIPS URI [RFC3261] and the
other is a TEL URI [RFC3966], and moreover
[I-D.ietf-sipping-update-pai] provides forwards compatibility by
mandating tolerance to the receipt of unexpected URIs, then the
Referred-By definition in [RFC3892] needs to be extended to contain
more than one URI value as well.
This document extends [RFC3892] by allowing all values of the
P-Asserted-Identity header field to be carried in the Referred-By
header field.
3. Inclusion of URIs in a Referred-By header
[RFC3892] does not allow more than one URI in the Referred-By header.
However, if the contents of the Referred-By header come from a
P-Asserted-Identity header field, then all of the URIs present in the
P-Asserted-Identity header field should be copied into the
Referred-By header field.
Bishai, et al. Expires September 3, 2009 [Page 4]
Internet-Draft Updates to Referred-By SIP header March 2009
4. Behaviour
This document updates [RFC3892] by allowing a Referred-By header to
contain two or more URIs as defined for P-Asserted-Identity header
field in [I-D.ietf-sipping-update-pai].
4.1. Referrer Behaviour
A server can generate a SIP Request because of exploder functionality
for SIP MESSAGE sent to a pre-defined group URI or for SIP INVITE
sent to an ad-hoc group or to a pre-defined group URI. In this
particular case the server MAY include in the request a Referred-By
header field to report the identity of the user on behalf of which
the server is acting and whose identity the server is in a position
to assert, copying all of the URIs present in the P-Asserted-Identity
header field. A server SHOULD do so only in cases where it can
expect to be trusted by the first proxy.
If Privacy was requested then there will only be one URI in the
Referred-By header containing an anonymous URI.
4.2. General handling
If a server generates a SIP Request because of exploder functionality
for a request containing a P-Asserted-Identity header field
containing an unexpexted number of URIs or unexpected URI schemes it
MUST act as specified in Section 4.5 of
[I-D.ietf-sipping-update-pai].
5. The Referred-By Header Field
The BNF in [RFC3892] is augmented from this:
Referred-By = ("Referred-By" / "b") HCOLON referrer-uri
*( SEMI (referredby-id-param / generic-param) )
referrer-uri = ( name-addr / addr-spec )
to this:
Referred-By = ("Referred-By" / "b") HCOLON referrer-uri
( SEMI (referredby-id-param / generic-param) )
*(COMMA referrer-uri
*( SEMI (referredby-id-param / generic-param) ))
referrer-uri = ( name-addr / addr-spec )
A Referred-By header field value MUST consist of exactly one name-
addr or addr-spec. There may be one or two Referred-By values. If
Bishai, et al. Expires September 3, 2009 [Page 5]
Internet-Draft Updates to Referred-By SIP header March 2009
there is one value, it MUST be a sip, sips, or tel URI. If there are
two values, one value MUST be a sip or sips URI and the other MUST be
a tel URI.
6. Examples
Figure 1 shows an example of a server acting as conference server.
In this case a User (User1) sends an INVITE request F1 that contains
an SDP body to a pre-defined group with identity sip:
pre-definedgroup@example.com . The group has members User1, User2 ,
User3 and User4. The server answers with a 200 (OK) response and
generates an INVITE request to each of the remaining members of the
group identified by the URIs corresponding to each user in the group
membership document. The conference server includes SDP and a
Refer-by header including all the values received in the initial
request from User1 in each of the outgoing INVITE requests.
Note that these examples consist of partial SIP messages that
illustrate only the relevant headers.
+--------+ +---------+ +--------+ +--------+ +--------+
|User1 | | Server | | User2 | | User3 | | User4 |
| | | | | | | | | |
+--------+ +---------+ +--------+ +--------+ +--------+
| | | | |
| F1 INVITE | | | |
| ---------------->| | | |
| F2 200 OK | | | |
|<---------------- | F3 INVITE | | |
| | ------------->| | |
| | F4 INVITE | | |
| | ------------------------>| |
| | F5 INVITE | | |
| | ----------------------------------->|
| | F6 200 OK | | |
| |<------------- | | |
| | F7 200 OK | | |
| |<------------------------ | |
| | F8 200 OK | | |
| |<----------------------------------- |
| | | | |
| | | | |
| | | | |
Figure 1: Flow diagram
Figure 2 shows an example of the INVITE request F1 sent to a pre-
Bishai, et al. Expires September 3, 2009 [Page 6]
Internet-Draft Updates to Referred-By SIP header March 2009
defined group, which carrries an application/sdp body that describes
the session to be set up.
INVITE sip: pre-definedgroup@example.com SIP/2.0
Via: SIP/2.0/TCP atlanta.example.com
;branch=z9hG4bKhjhs8axs83
Max-Forwards: 70
To: "My Team" < sip: pre-definedgroup@example.com >
From: User1 <sip:User1@example.com>;tag=32431
Call-ID: d432fa84b4c76e65710
CSeq: 1 INVITE
Contact: <sip:User1@atlanta.example.com>
Allow: INVITE, ACK, CANCEL, BYE, REFER
Allow-Events: dialog
Content-Type: application/sdp
Content-Length:(appropriate value)
v=0
o=alice 2890844526 2890842807 IN IP4 atlanta.example.com
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 20000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 20002 RTP/AVP 31
a=rtpmap:31 H261/90000
Figure 2: INVITE request sent to the pre-defind group
Figure 3 shows an example of the INVITE request F1 received at the
server within a SIP trusted domain. The SIP proxy creates and
inserts the P-asserted identity from the identities of the user
according to [RFC 3892] and forwards it to the Server.
Bishai, et al. Expires September 3, 2009 [Page 7]
Internet-Draft Updates to Referred-By SIP header March 2009
INVITE sip: pre-definedgroup@example.com SIP/2.0
Via: SIP/2.0/TCP atlanta.example.com
;branch=z9hG4bKhjhs8axs83
Max-Forwards: 70
To: "My Team" < sip: pre-definedgroup@example.com >
From: User1 <sip:User1@example.com>;tag=32431
Call-ID: d432fa84b4c76e65710
CSeq: 2 INVITE
P-Asserted-Identity: "User1" <sip:user1@example.com>
P-Asserted-Identity: tel: +358504834400
Contact: <sip:User1@atlanta.example.com>
Allow: INVITE, ACK, CANCEL, BYE, REFER
Allow-Events: dialog
Content-Type: application/sdp
Content-Length:(appropriate value)
v=0
o=alice 2890844526 2890842807 IN IP4 atlanta.example.com
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 20000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 20002 RTP/AVP 31
a=rtpmap:31 H261/90000
Figure 3: INVITE request received at the pre-defind group
The out-going INVITE requests F3, F4, and F5 sent out by the server
(pre-defined group) to the members of the group are the same.
All those INVITE requests includes a Refer-By header field containing
the values of all the asserted identities in the initial INVITE
request F1 received by the server. The out-going INVITE requests
also contain application/sdp body that describes the session to be
set up. Figure Figure 4 shows an example of the message F3.
Bishai, et al. Expires September 3, 2009 [Page 8]
Internet-Draft Updates to Referred-By SIP header March 2009
INVITE sip:User2@example.com SIP/2.0
Via: SIP/2.0/TCP Groups.example.com
; Branch=z9hG4bKhjhs8as454
Max-Forwards: 70
To: <sip:User2@example.com>
From: "My Team" < sip: pre-definedgroup@example.com >; tag=234332
Call-ID: 389sn189dasdf
CSeq: 1 INVITE
Contact: < sip: pre-definedgroup@Groups.example.com>;isfocus
Referred-By: < sip:user1@example.com >,<tel: +358504834400>
;cid="20498723.2UWQHN307yhb3@ atlanta.example.com"
Allow: INVITE, ACK, CANCEL, BYE, REFER
Allow-Events: dialog, conference
Content-Type: application/sdp
Content-Length: (appropriate value)
v=0
o=conf 2890844343 2890844343 IN IP4 conference.example.com
s=-
c=IN IP4 192.0.2.5
t=0 0
m=audio 40000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 40002 RTP/AVP 31
a=rtpmap:31 H261/90000
Figure 4
7. IANA Considerations
This document requires no IANA actions.
8. Security considerations
The use of the Referred-By header raises a number of security
considerations, which are discussed fully in [RFC3892]. This
document raises no additional security considerations.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Bishai, et al. Expires September 3, 2009 [Page 9]
Internet-Draft Updates to Referred-By SIP header March 2009
[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.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[RFC3892] Sparks, R., "The Session Initiation Protocol (SIP)
Referred-By Mechanism", RFC 3892, September 2004.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
9.2. Informational References
[I-D.ietf-sipping-update-pai]
Elwell, J., "Updates to Asserted Identity in the Session
Initiation Protocol (SIP)",
draft-ietf-sipping-update-pai-09 (work in progress),
January 2009.
Authors' Addresses
Nadia Bishai
Ericsson
8500 Decarie Blvd.
Montreal H4P-2N2
Canada
Email: nadia.bishai@ericsson.com
Salvatore Loreto
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: salvatore.loreto@ericsson.com
Bishai, et al. Expires September 3, 2009 [Page 10]
Internet-Draft Updates to Referred-By SIP header March 2009
Adamu Haruna
Nokia
Finland
Email: adamu.haruna@nokia.com
Bishai, et al. Expires September 3, 2009 [Page 11]