Internet DRAFT - draft-songyue-dispatch-invite-usage-indication
draft-songyue-dispatch-invite-usage-indication
SIPCORE Working Group Y. Song
Internet-Draft Y. Jiang
Intended status: Standards Track China Mobile
Expires: February 2, 2013 Aug 2012
Private Header (P-Header) Extensions to the Session Initiation Protocol
(SIP) for support of Indication of Dialog Type
draft-songyue-dispatch-invite-usage-indication-00
Abstract
This document describes private extensions to the Session Initiation
Protocol (SIP) that enable a SIP entity to indicate in the INVITE
message the exact purpose of the INVITE transaction, e.g. media
negotiation, session refresh or creation of an pure signaling dialog.
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 February 2, 2013.
Copyright Notice
Copyright (c) 2012 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
(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.
Song & Jiang Expires February 2, 2013 [Page 1]
Internet-Draft INVITE Usage Indication Aug 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. P-INVITE-Type Header Field definition . . . . . . . . . . . . 5
4. UA behavior . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Creating a normal session with media negotiation . . . . . 7
5.2. Creating a pure signaling session . . . . . . . . . . . . 8
5.3. Doing session refresh . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. Normative References . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Song & Jiang Expires February 2, 2013 [Page 2]
Internet-Draft INVITE Usage Indication Aug 2012
1. Introduction
The Session Initiation Protocol (SIP) provides capability to create a
dialog using INVITE transaction. When creating dialog with INVITE,
there always media negotiation accompanied. When the UAC includes an
SDP offer in the INVITE message, the UAS will also includes SDP
answer in the response message. If there is no body in the INVITE
message, the UAS will include SDP offer in the response message, for
example 200 OK, then the UAC must send SDP answer in the ACK message,
so the media negotiation is done.
In some scenarios the using of INVITE transaction is only to create a
pure signaling session, no media is needed. Example could be the
media server control using MSML. The controller uses INVITE to
create a control dialog with the media server, and then send INFO
messages that carrying MSML body within the dialog. The second
example is within the Third Generation Partnership Project (3GPP) IP
Multimedia Subsystem (IMS). When Unstructured Supplementary Service
Data (USSD) service is provided in IMS, a dialog is created between
UE and the network, then the USSD data is transmit using INFOs within
the dialog. In such scenarios, the media negotiation is unnecessary
and it may make overhead to reserve media resource. Third example is
for the session refresh, in which the refresher sends INVITE only to
refresh the session timer, media re-negotiation is unnecessary.
This document attempts to provide a mechanism that enables the SIP
entity to indicate in the INVITE message the exact purpose of the
INVITE transaction.
Song & Jiang Expires February 2, 2013 [Page 3]
Internet-Draft INVITE Usage Indication Aug 2012
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Song & Jiang Expires February 2, 2013 [Page 4]
Internet-Draft INVITE Usage Indication Aug 2012
3. P-INVITE-Type Header Field definition
The P-INVITE-Type header field conveys the usage of the INVITE
message. It is place only in INVITE requests.
The syntax of the P-INVITE-Type header field is as follow:
P-INVITE-Type = "P-INVITE-Type" HCOLON invite-type
Invite-type = "media-negotiation"/"ini-sig-dialog"/
"refresh-session"
The P-INVITE-Type value "media-negotiation" indicates that the INVITE
request is to create a normal session with media negotiation, which
is the current usage of INVITE request. The value "ini-sig-session"
indicates that the current INVITE request is to create a pure
signaling dialog, no media negotiation is needed. The value
"refresh-session" indicates that the INVITE request is used to
refresh an existing session.
Song & Jiang Expires February 2, 2013 [Page 5]
Internet-Draft INVITE Usage Indication Aug 2012
4. UA behavior
When UAC is sending an INVITE request, it SHOULD insert a P-INVITE-
Type header into the message and set the value according to the
purpose of this INVITE request. If the value is set to "ini-sig-
session" or "refresh-session", the UAC MUST NOT include SDP body in
the INVITE request. If the UAC is to create a normal session with
media negotiation, it may not insert the P-INVITE-Type header field.
When UAS receive an INVITE request with a P-INVITE-Type header field,
it must check the value of this header. If the value is "ini-sig-
session" or "refresh-session" the UAS will know that this INVITE
transaction does not do media negotiation and MUST NOT include any
SDP body in the corresponding response messages. If the INVITE
request does not contain P-INVITE-Type header field, the UAS MUST
treat it as the P-INIVTE-Type value is "media-negotiation".
Song & Jiang Expires February 2, 2013 [Page 6]
Internet-Draft INVITE Usage Indication Aug 2012
5. Examples
5.1. Creating a normal session with media negotiation
Alice Bob
|(1) INVITE |
|P-INVITE-Type: |
|media-negotiation |
|----------------->|
|(2) 200 OK |
|<-----------------|
|(3) ACK |
|----------------->|
| |
|------------------|
| media setup |
|------------------|
Figure 1: Example of creating normal session
Figure 1 gives an example of a normal use of INVITE request. In this
example, UAC includes a P-INVITE-Type header field in the INVITE
message and the value is set to "media-negotiation". The INVITE
request generated by UAC (message 1) might look like this:
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP alice.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: 1 INVITE
Contact: <sips:alice@example.com>
P-INVITE-Type: media-negotiation
Content-Type: application/sdp
Content-Length: 200
(Alice's SDP not shown)
This request indicates that Alice wants to create a normal session
with Bob and the SDP body is included in the message.
When Bob receive this message, deals with the SDP offer in the
request then send SDP answer in the 200 OK response.
Song & Jiang Expires February 2, 2013 [Page 7]
Internet-Draft INVITE Usage Indication Aug 2012
5.2. Creating a pure signaling session
Alice Bob
|(1) INVITE |
|P-INVITE-Type: |
|ini-sig-session |
|----------------->|
|(2) 200 OK |
|<-----------------|
|(3) ACK |
|----------------->|
| |
|------------------|
| no media setup |
|------------------|
| |
|(4) INFO |
|----------------->|
|(5) 200 OK |
|<-----------------|
|(6) IFNO |
|<-----------------|
|(7) 200 OK |
|----------------->|
|(8) BYE |
|----------------->|
|(9) 200 OK |
|<-----------------|
Figure 2: Example of creating pure signaling session
Figure 2 shows how to use INVITE request to create a pure signaling
session. In this example, a signaling dialog is first created
between Alice and Bob, then they exchange data using INFO request
within the dialog. Alice inserts P-INVITE-Type into the INVITE
message and sets the value to "ini-sig-dialog". The INVITE message
sent by Alice (message 1) has no body and may look like this:
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP alice.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: 1 INVITE
Contact: <sips:alice@example.com>
P-INVITE-Type: ini-sig-dialog
Song & Jiang Expires February 2, 2013 [Page 8]
Internet-Draft INVITE Usage Indication Aug 2012
Content-Length: 0
Bob receives the INVITE request and finds that the P-INIVTE-Type
header is set to "ini-sig-dialog", then it will not include any
message body in the response message.
The INFO requests sent between Alice and Bob use the same Call-ID as
the previous INVITE request, like this:
INFO sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP alice.example.com;branch=z9hG4bKnashDFSD2
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 2 INFO
Contact: <sips:alice@example.com>
Content-Type: -- content-type --
Content-Length: -- content-length--
-- Content in the INFO request --
5.3. Doing session refresh
Alice Bob
| |
|------------------|
| session exsiting |
|------------------|
| |
|(1) INVITE |
|P-INVITE-Type: |
|refresh-session |
|----------------->|
|(2) 200 OK |
|<-----------------|
|(3) ACK |
|----------------->|
Figure 3: Example of session refreshing
Figure 3 gives an example of session refreshing. A session has been
created between Alice and Bob, and session timer is required. When
Alice sends INVITE request for session refreshing, it inserts a
P-INVITE-Type header into the message and sets the value to "refresh-
session", no message body is included in the request. Message 1 may
Song & Jiang Expires February 2, 2013 [Page 9]
Internet-Draft INVITE Usage Indication Aug 2012
look like this:
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP alice.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: 3 INVITE
Contact: <sips:alice@example.com>
P-INVITE-Type: refresh-session
Content-Length: 0
Song & Jiang Expires February 2, 2013 [Page 10]
Internet-Draft INVITE Usage Indication Aug 2012
6. Security Considerations
Song & Jiang Expires February 2, 2013 [Page 11]
Internet-Draft INVITE Usage Indication Aug 2012
7. IANA Considerations
Song & Jiang Expires February 2, 2013 [Page 12]
Internet-Draft INVITE Usage Indication Aug 2012
8. Acknowledgements
Song & Jiang Expires February 2, 2013 [Page 13]
Internet-Draft INVITE Usage Indication Aug 2012
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Song & Jiang Expires February 2, 2013 [Page 14]
Internet-Draft INVITE Usage Indication Aug 2012
Authors' Addresses
Yue Song
China Mobile
32 Xuanwumenxi Ave,
Xuanwu District
Beijing 100053
P.R.China
Email: songyue@chinamobile.com
Yi Jiang
China Mobile
32 Xuanwumenxi Ave,
Xuanwu District
Beijing 100053
P.R.China
Email: jiangyi@chinamobile.com
Song & Jiang Expires February 2, 2013 [Page 15]
