One document matched: draft-kaplan-sip-info-use-cases-00.txt
SIP Working Group H. Kaplan
Internet Draft Acme Packet
Intended status: Informational
Expires: June 13, 2008 December 13, 2007
SIP INFO Use Cases
draft-kaplan-sip-info-use-cases-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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/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 June 13, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Kaplan Expires June 13, 2007 [Page 1]
SIP INFO Use Cases December 2007
Abstract
This document lists several known and potential use cases for SIP
INFO requests, as discussed on the SIP WG mailing list. The use
cases were requested by the WG chairs at the SIP WG meeting in IETF
70, and are documented herein for the purpose of discussion only.
Table of Contents
1. Introduction................................................3
2. Terminology.................................................3
3. Applicability...............................................3
4. Alternative Mechanisms......................................3
5. Documented Uses of INFO.....................................4
5.1. SIP-T..................................................4
5.2. ISUP/QSIG Interworking and Exchange....................4
5.3. Media Server Control Markup Language (MSCML)...........4
5.4. User-Agent Computer Supported Telecommunications
Applications (uaCSTA)..........................................4
6. Potentially Valid Use-Cases.................................4
6.1. DTMF...................................................4
6.2. Sending a vcard asynchronously.........................5
6.3. Sending a user-icon image..............................5
6.4. Sending a vcalendar invitation.........................5
6.5. Sending an HTTP URL....................................6
6.6. Performing a session traceroute........................6
6.7. Sending soft-key labels and press events...............7
6.8. Sending geo-location information during call...........7
7. Other Known Use-Cases.......................................7
7.1. Sending RTP/RTCP statistics during call................7
7.2. Sending access-location information after call
establishment..................................................8
7.3. Sending media-control indications......................8
7.4. Sending video fast update command......................8
7.5. Sending peripheral control commands....................8
7.6. Sending charging information for a call................8
7.7. Sending a screen-pop-up message........................8
7.8. Sending Bookmark Tags..................................9
7.9. Sending Hook-Flash Indication..........................9
7.10. Session Refresh and Liveness Check.....................9
7.11. Message-Waiting Indication (MWI).......................9
8. Security Considerations.....................................9
9. IANA Considerations........................................10
10. References.................................................10
10.1. Informative References................................10
Author's Address.................................................11
Intellectual Property Statement..................................12
Full Copyright Statement.........................................12
Acknowledgment...................................................12
Kaplan Expires - June 2007 [Page 2]
SIP INFO Use Cases December 2007
1. Introduction
The SIP INFO method was defined in [RFC2976] to convey session
related control information inside an Invite-created dialog. While
it has been widely adopted for specific application use cases, and a
couple RFCs rely on it, there are known limitations and issues with
it today documented in [info-harmful]. Some of those issues,
dealing with negotiation of use and context indication, are
addressed in [info-events].
At IETF 70, the SIP WG chairs asked for a list of use-cases, for the
purpose of deciding if a general framework such as [info-events] is
warranted. This draft lists such use-cases, based on email
discussion on the SIP WG mailing list sip@ietf.org. This draft is
NOT suggesting the use-cases are legitimate or proper for SIP INFO
use - that is to be discussed on the SIP WG mailing list.
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 RFC 2119. The
terminology in this document conforms to RFC 2828, "Internet
Security Glossary".
3. Applicability
This draft relates to the [RFC2976] SIP INFO request.
4. Alternative Mechanisms
In general, most use-cases for INFO have alternative mechanisms,
which may or may not be more appropriate. Examples are:
1. Use Re-INVITE or UPDATE requests - for some cases this may make
sense, but there is a question if INVITE or the [RFC3311]
UPDATE method should be used as just carriers for things not
affecting/updating the state of the session/dialog or SDP.
(note that session-timers uses them for this though) For
example, in some systems INVITE and UPDATE are treated
differently for Call-Detail-Records and logging.
2. Use MESSAGE request - the MESSAGE request, defined in
[RFC3428], is considered to be generally useful for sending
MIME body content to be rendered for human users. It requires
Kaplan Expires - June 2007 [Page 3]
SIP INFO Use Cases December 2007
support for text/plain bodies, and is commonly expected to
handle message/cpim bodies, but it could transport any body
type. There is an argument that MESSAGE is for human-rendered
info, so vcards and vcalendars are inappropriate. However one
could argue both are in fact rendered to the user, after
processing based on their type, but that some UA's can offer to
skip rendering and do something else with them, again based on
their type (like email clients do).
3. Use SUBSCRIBE/NOTIFY - [RFC3265] was written to handle
scenarios similar to some of the use-cases listed herein.
4. Use a media-plane protocol, such as RTCP or MSRP - several use-
cases in this draft should clearly be handled in the media-
plane. Potentially any use-case could in theory be done by
media, but clearly for some doing so represents a huge amount
of overhead.
5. Documented Uses of INFO
5.1. SIP-T
This is documented in [RFC3372], which is a BCP.
5.2. ISUP/QSIG Interworking and Exchange
This is documented in [RFC4497] which is a BCP, and [RFC3204] which
is Standards Track.
5.3. Media Server Control Markup Language (MSCML)
This is documented in [RFC4722], which is Informational.
5.4. User-Agent Computer Supported Telecommunications Applications
(uaCSTA)
This is documented in [ECMA-TR/87].
6. Potentially Valid Use-Cases
The following represent known or potential use-cases which this
author believes have reasonable applicability to INFO use.
6.1. DTMF
Several proprietary uses of INFO for transferring DTMF are known to
exist, some of which are in wide use by multiple vendors.
Kaplan Expires - June 2007 [Page 4]
SIP INFO Use Cases December 2007
Alternative mechanisms: [KPML] for signaling-plane, or [RFC4733] for
media-plane if possible.
6.2. Sending a vcard asynchronously
Example: Alice calls Bob, Alice says "can you send me John's
vcard?", Bob clicks something and voila it's sent.
Reasons for INFO: it's explicit what you're doing when you send the
vcard, and you can send it knowing the other end can accept it, and
you can send it based on user input. Making it explicit means the
receiving UA can automatically store the vcard for later use, for
example into a contact list.
Alternative mechanisms: send a re-INVITE or UPDATE with a Call-Info,
with either a URL reference, data URI, or MIME and CID URL; send a
MESSAGE request.
Counter-Arguments to alternative mechanisms: sending it in an
INVITE/UPDATE Call-Info would conflict with the purpose of that
header being for caller/cllee information only (as opposed to third
party info, which this example shows). Furthermore, the DATA URL is
generally discouraged, and a URL reference is hard to actually do in
practice.
6.3. Sending a user-icon image
Example: Alice Alice calls Bob, Bob has an icon that represents
himself, sends it when he picks up the phone or upon clicking what
image he wants to represent himself.
Reasons for INFO: it's explicit what you're doing when you send the
image, and you can send it knowing the other end can accept it and
its type (jpeg/gif/bmp/etc.), and you can send it based on user
input. Making it explicit means the receiving UA can automatically
store the image for later use, for example as a contact/buddy image,
which sending it in a MESSAGE would not do.
Alternative mechanisms: send a 200-ok, re-INVITE or UPDATE with a
Call-Info, which has an explicit type for "icon"; send a MESSAGE
request. P. Kyzivat notes MESSAGE is appropriate. J. Rosenberg
notes that if the image is big, which it easily could be, media-path
makes more sense.
6.4. Sending a vcalendar invitation
Example: Alice calls Bob, Bob says "hey let's have a con call at
time X", clicks and voila his phone sends a vcalendar.
Kaplan Expires - June 2007 [Page 5]
SIP INFO Use Cases December 2007
Reasons for INFO: it's explicit what you're doing when you send the
vcalendar, and you can send it knowing the other end can accept it,
and you can send it based on user input. Making it explicit means
the receiving UA can automatically store the calendar invite time,
for example if it has an integrated calendar app or alarm reminder.
Alternative mechanisms: send a MESSAGE request.
[Editor's note: Whether the vcalendar is related to the session or
not and thus whether it should be sent in an in-dialog request or
not is certainly debatable, and makes MESSAGE more reasonable.]
6.5. Sending an HTTP URL
Example: Alice calls Bob, a sales guy; Alice asks for more info or
a datasheet and Bob sends a URL for Alice to open with her web-
browser.
Reasons for INFO: it's explicit what you're doing when you send the
URL, and you can send it knowing the other end can accept it, and
you can send it based on user input.
Alternative mechanisms: send a MESSAGE request. J. Rosenberg notes
this can be done with a REFER with http URL based on [app-
framework].
6.6. Performing a session traceroute
Example: Alice calls Bob, Bob answers, Alice does a sip-traceroute
to figure out the path to Bob, by sending Info with an incrementing
max-forwards type header starting at 0 (but not really the Max-
Forwards header), with a sip-frag type response body or some such.
The reason it's not just using the Max-Forwards is because the 483
response generated by normal proxies would terminate the dialog.
This wiould be a new header similar in concept, but only work for
middle-boxes which support it and don't generate a 483.
Reasons for INFO: If such a thing were to be defined, it could be
done such that the response code did not terminate the dialog.
Alternative mechanisms: re-INVITE or UPDATE.
[Editor's note: It's debatable if certain types of B2BUA's (ie,
SBCs) would ever allow this type of thing to happen, due to security
concerns, but I think they may do it at domain boundary hops.]
Kaplan Expires - June 2007 [Page 6]
SIP INFO Use Cases December 2007
6.7. Sending soft-key labels and press events
Example: Alice calls her vmail server. Vmail server sends softkey-
labels for the menu items available in the response or INFO, Alice
presses softkeys and her UA sends them in INFO.
Reasons for INFO: similar to DTMF, the probability of users actually
pressing the soft-key buttons is very low, so using INFO reduces
SUBSCRIBE/NOTIFY overhead and ties it to the INVITE dialog
implicitly.
Alternative mechanisms: SUBSCRIBE/NOTIFY similar to [KPML].
[Note: J. Rosenberg notes this in the [app-framework] draft scope]
6.8. Sending geo-location information during call
Example: Alice calls Bob, a hotel receptionist. Alice asks for
directions to hotel, clicks button and sends him location info of
her phone (or Bob clicks button and sends her his location). Or
Alice calls emergency services from a mobile phone, and phone
updates location based on GPS.
Reasons for INFO: it's explicit what you're doing when you send the
geo-loc, and you can send it knowing the other end can accept it,
and you can send it based on user input.
Alternative mechanisms: send a re-INVITE or UPDATE with geo-loc
info, or SUBSCRIBE/NOTIFY.
[Editor's note: There is general agreement there is no need for this
to be done in INFO]
7. Other Known Use-Cases
These use-cases are known to exist or have been proposed.
7.1. Sending RTP/RTCP statistics during call
There is an implementation of this, and the rationale is the
signaling plane box that wants this info is not actually the media
plane box that gets RTCP.
[Editor's note: There is general agreement this should be done with
Sub/Not, so it can get stats after the call is over, and since it
will probably want periodic reports the overhead of the Subscribe
should be dwarfed by the number of Notifies]
Kaplan Expires - June 2007 [Page 7]
SIP INFO Use Cases December 2007
7.2. Sending access-location information after call establishment
There is a P-Access-Network-Info header, and some have proposed to
send an update for it as a phone roams access points or cells.
[Editor's note: I think this is an odd thing to do inside an Invite
session, vs. in a Sub/Not or Register (and besides most of the time
the "network" inserts this header, not the UA).]
7.3. Sending media-control indications
This sends play/pause/resume commands in INFO. This is done today
by at least one vendor. The argument is it's like SDP re-Invite for
hold, except at a media content layer above RTP and even RTCP, so
not done in RTCP nor SDP.
[Editor's note: There is general agreement this should be done in
the media-plane.]
[J. Rosenberg agrees and notes: "There is a requirement for low
latency here and there will be a lot of these that get sent."]
7.4. Sending video fast update command
This is an informational draft [fast-update], which documents what
has been implemented, but states it should really be done in the
media plane in the future.
[Editor's note: There is general agreement the draft is correct in
stating it should be done in the media-plane and not INFO]
7.5. Sending peripheral control commands
There is actually a patent on this. Someone thinks it makes sense
to create a SIP session to your laptop, or vice-versa, and then send
USB commands inside MIME in INFO messages.
[Editor's note: There is general agreement this should be media-
plane, if anything.]
7.6. Sending charging information for a call
There was a proposal to use this for Advice of Charge information in
TISPAN.
[Editor's note: IMO it should be a SUBSCRIBE/NOTIFY model, as they
want this to survive the Invite session.]
7.7. Sending a screen-pop-up message
There is a patent for doing screen pop-ups using INFO. One could
use MESSAGE, but I believe the patent is for generating screen pop-
ups like warnings and such, not simple user instant messages.
[P. Kyzivat notes this should be MESSAGE]
Kaplan Expires - June 2007 [Page 8]
SIP INFO Use Cases December 2007
7.8. Sending Bookmark Tags
There is a proposal in TISPAN and ATIS to indicate bookmark spots
for video streams using INFO.
[Editor's note: this seems like a media-plane thing, but the reason
they're using SIP is due to media layer processing issues, I think,
whereby the media is processed by a different box than media
control?]
7.9. Sending Hook-Flash Indication
There is a draft for doing this in [hook-flash], which is deployed.
This is along the lines of needing signaling-plane flash indication
a la DTMF. RFC 2833 included it for media-plane DTMF events, but
[RFC4733] deprecated it.
[Editor's note: although hook-flash is sometimes considered similar
to DTMF, from a user perspective it's really just a overloaded
"button" for hold, transfer, or conference invocation and thus
should be handled by the UA natively]
7.10. Session Refresh and Liveness Check
This is actually implemented by several vendors: use INFO to check
the session is still alive (and keep it so). This is clearly what
[RFC4028] was written for, which uses re-INVITEs and UPDATEs.
7.11. Message-Waiting Indication (MWI)
The idea is to set/clear the MWI light/icon on phones, but to do so
it sends INFO outside of dialogs. This is implemented by several
vendors. [Editor's note: This really should be done with
SUBSCRIBE/NOTIFY.]
8. Security Considerations
There are no security considerations, since this is merely an
informative use-case document.
Kaplan Expires - June 2007 [Page 9]
SIP INFO Use Cases December 2007
9. IANA Considerations
This document does not impact IANA.
10. References
10.1. Informative References
[RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October
2000.
[RFC3204] Zimmerer, E., et al, "MIME media types for ISUP and QSIG
Objects", RFC 3204, December 2001.
[RFC3261] Rosenberg, J., et al, "SIP: Session Initiation
Protocol", RFC 3261, June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002
[RFC3372] Vemuri, A., Peterson, J., "Session Initiation Protocol for
Telephones (SIP-T): Context and Architectures", RFC 3372,
September 2002.
[RFC3428] Campbell, B., et al, "Session Initiation Protocol (SIP)
Extension for Instant Messaging", RFC 3428, December 2002.
[RFC4497] Elwell, J., et al, "Interworking between the Session
Initiation Protocol (SIP) and QSIG", RFC 4497, May 2006.
[RFC4722] Burger, E., Van Dyke, J., Spitzer, A., "Media Server
Control Markup Language (MSCML) and Protocol", RFC 4722,
November 2006.
[KPML] Burger, E., Dolly, M., "A Session Initiation Protocol (SIP)
Event Package for Key Press Stimulus (KPML)", RFC 4730,
November 2006.
[RFC4733] Schulzrinne, H., Taylor, T., "RTP Payload for DTMF Digits,
Telephony Tones, and Telephony Signals", RFC 4733,
December 2006.
[ECMA-TR/87] "Using CSTA for SIP Phone User Agents (uaCSTA)",
ISO/IEC TR 22767 and ECMA TR/87 1st Edition, June 2004.
[info-harmful] Burger, E., "Session Initiation Protocol (SIP) INFO
Method Use", draft-burger-sip-info-02.txt, November 2007.
Kaplan Expires - June 2007 [Page 10]
SIP INFO Use Cases December 2007
[info-events] Kaplan, H., Holmberg, C., "SIP INFO Event Framework",
draft-kaplan-sip-info-events-00.txt, November 2007.
[app-framework] Rosenberg, J., "A Framework for Application
Interaction in the Session Initiation Protocol (SIP)",
draft-ietf-sipping-app-interaction-framework-05.txt, July
2005.
[fast-update] Levin, O., Even, R., Hagendorf, P., "XML Schema for
Media Control", draft-levin-mmusic-xml-media-control-
12.txt, November 2007.
[hook-flash] Hwang, J., "INFO Usage Examples for Network-based Mid-
Call Service", draft-hwang-sipping-infomidcall-00.txt,
February 2004.
Author's Address
Hadriel Kaplan
Acme Packet
71 Third Ave.
Burlington, MA 01803, USA
Email: hkaplan@acmepacket.com
Kaplan Expires - June 2007 [Page 11]
SIP INFO Use Cases December 2007
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Kaplan Expires - June 2007 [Page 12] | PAFTECH AB 2003-2026 | 2026-04-24 01:21:58 |