BLISS A. Johnston, Ed.
Internet-Draft Avaya
Expires: August 29, 2007 M. Soroushnejad
V. Venkataramanan
Sylantro Systems Corp
P. Pepper
Citel Technologies
A. Kumar
Yahoo Inc.
February 25, 2007
Requirements and Implementation Options for the Multiple Line Appearance
Feature using the Session Initiation Protocol (SIP)
draft-johnston-bliss-mla-req-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/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 August 29, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes the requirements for implementation of a
Johnston, et al. Expires August 29, 2007 [Page 1]
Internet-Draft SIP Reqs for MLA February 2007
group telephony feature commonly known as Bridged Line Appearance
(BLA) or Multiple Line Appearance, or Shared Call/Line Appearance
(SCA). When implemented using the Session Initiation Protocol (SIP),
it is referred to as Multiple Appearances. This feature is commonly
offered in the IP Centrex services and IP-PBX offerings and is likely
to be implemented on SIP IP telephones and SIP feature servers used
in a business environment. This document lists requirements and
compares implementation options for this feature.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 3
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Implementation Options . . . . . . . . . . . . . . . . . . . . 6
5.1. Appearance Implementation Options . . . . . . . . . . . . 9
5.1.1. URI parameter Approach . . . . . . . . . . . . . . . . 9
5.1.2. Dialog Package Parameter . . . . . . . . . . . . . . . 10
5.1.3. Incoming Appearance Assignment . . . . . . . . . . . . 11
5.1.4. Appearance Contention Resolution . . . . . . . . . . . 12
5.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Informative References . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Johnston, et al. Expires August 29, 2007 [Page 2]
Internet-Draft SIP Reqs for MLA February 2007
1. Introduction
The feature and functionality requirements for SIP user agents (UAs)
supporting business telephony applications differ vastly from basic
SIP user agents, both in terms of services and end user experience.
In addition to basic SIP support, many of the services in a business
environment require the support for SIP extensions such as REFER [3],
SUBSCRIBE/NOTIFY primitives [4], the SIP Replaces [5] and Join [9]
header fields, etc. Many of the popular business services have been
documented in the SIP Service Examples [6].
This specification details a method for implementing a group
telephony feature known in telephony as Bridged Line Appearance (BLA)
or Multiple Line Appearance, one of the more popular advanced
features expected of SIP IP telephony devices in a business
environment. Another common name for the this feature is Shared
Call/Line Appearance (SCA).
This document looks at how this feature can be implemented using
standard SIP RFC 3261 [2] in conjunction with RFC 3265 [4] for
exchanging status among user agents, and the SIP dialog state event
package [7] to exchange dialog state information to achieve the same.
Different approaches will be discussed including the use of URI
parameters, feature tags, and dialog package extensions along with
the strengths and weaknesses of the various approaches.
A call flow for Single Line Extension was formerly included in the
SIP Service Examples [6]. However, the attempt to implement using
standard SIP primitives ultimately failed, leading to its removal
from that document. It is the hope of the authors that SIP
extensions to meet the requirements of this important class of
features will soon be standardized.
2. Conventions used in this document
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 [ ] and
indicate requirement levels for compliant mechanisms.
3. Usage Scenarios
The following examples are common applications of the Multiple
Appearances feature and are mentioned here as informative use cases:
1. Executive/Assistant arrangement: The executive may appear as an
Johnston, et al. Expires August 29, 2007 [Page 3]
Internet-Draft SIP Reqs for MLA February 2007
appearance on the assistant SIP telephony device. Assistant may
answer incoming calls to executive and then place the call on hold
for the executive to pick it up. The assistant can always see the
call state of the executive.
2. BLA Call Group: Users with similar business needs or tasks can be
assigned to specific groups and share the line appearances of each
other on each others SIP telephony devices. For example, an IT
department staff of five might answer a help line which has three
appearances on each phone in the IT work area. A call answered on
one phone can be put on hold and picked up on another phone. A shout
or an IM to another staff member can result in them taking over a
call on a particular appearance.
3. Virtual BLA: Allows a AOR, not assigned as a primary appearance
to any user, to be set up as a BLA on a given set of user devices.
All the example usages above can be supported by the Multiple
Appearances feature described in this document, however the details
of setup and usage of the above examples are not relevant to
understanding of the BLA mechanism itself.
Note that in this service, the AOR is commonly referred to as a
Directory Address (DA).
In traditional telephony, the line is physical. A common scenario is
for a number of business telephones to share a single or a small
number of lines. The appearance number relates to the user interface
for the telephone - typically each appearance has a visual display
(lamp that can change color or blink) and a button (used to select
the appearance). In SIP terms, the line is virtual. However, the
concept of appearance is still relevant to SIP due to the user
interface considerations. It is important to keep the appearance
number construct because:
1. Human users are used to the concept and will expect it in
replacement systems (e.g. an overhead page announcement says "Joe
pickup line 3")
2. It is a useful structure for user interface representation
3. There are cases where for bandwidth or gateway limitations, it is
useful to limit the number of concurrent sessions.
In this document, we will use the term "appearance" as a stand-in for
"line appearance". Note that this does not mean that a conventional
telephony user interface (lamps and buttons) must be used -
implementations may use another metaphor as long as the appearance
Johnston, et al. Expires August 29, 2007 [Page 4]
Internet-Draft SIP Reqs for MLA February 2007
number is readily apparent to the user.
4. Requirements
The basic requirements of the multiple appearance feature can be
summarized as follows:
REQ-1 Incoming calls to the AOR must be offered to a group of UAs and
can be answered by any of them.
REQ-2 Each UA in the group must be able to learn the call status of
the others in the group for the purpose of rendering this information
to the user.
REQ-3 Calls can be joined (also called bridged or conferenced
together) or can be picked up (taken) by another UA in the group in a
secure way.
REQ-4 The mechanism should require the minimal amount of
configuration. UAs registering against the group AOR should be able
to learn about each other and join the appearance group.
REQ-5 The mechanism must scale for large numbers of appearances, n,
and large numbers of UAs, N, without introducing excessive messaging
traffic.
REQ-6 Each call or session (incoming or outgoing) must be assigned a
common "appearance" number from a managed pool administered for the
AOR group. Once the session has terminated, the appearance number is
released back into the pool and can be reused by another incoming or
outgoing session.
REQ-7 Each UA in the group must be able to learn the line appearance
status of the the group.
REQ-8 There must be mechanisms to resolve appearance contention among
the UAs in the group.
REQ-9 The mechanism must allow all UAs receiving an incoming session
request to select the same appearance number at the time of alerting.
REQ-10 The mechanism must have a way of reconstructing appearance
state after an outage that does not result in excessive traffic and
processing.
REQ-11 The mechanism must have backwards compatibility such that a UA
which is unaware of the feature can still register against the group
Johnston, et al. Expires August 29, 2007 [Page 5]
Internet-Draft SIP Reqs for MLA February 2007
AOR and make and receive calls.
REQ-12 The mechanism must not allow UAs outside the group to select
or manipulate appearance numbers.
REQ-13 For privacy reasons, there must be a mechanism so that
appearance information is not leaked outside the group of UAs. (e.g.
"So who do you have on line 1?")
5. Implementation Options
Many of the requirements for this service can be met using standard
SIP mechanisms such as:
- A SIP Forking Proxy and Registrar/Location Service meets REQ-1.
- The SIP Dialog Package meets REQ-2.
- The SIP Replaces and Join header fields meets REQ-3.
- The SIP Registration Package meets REQ-4.
- The use of a State Agent for the Dialog Package meets REQ-5.
REQ-6 suggests the need for an entity which manages the appearance
resource. Just as conferencing systems commonly have a single point
of control, known as a focus, a Multiple Appearance group has a
single point of control of the appearance shared resource. This is
defined as an Appearance Agent for a group. While an Appearance
Agent can be part of a centralized server, it could also be co-
resident in a member User Agent who has taken on this functionality
for a group. The Appearance Agent learns the group state either by
subscribing to the dialog state of each member UA individually or by
dialog state publications from members.
While the appearance resource could be managed co-operatively by a
group of UAs without any central control, this is not discussed in
this draft, but instead is left as a research project for future
standardization. It is also possible that the Appearance Agent logic
could be distributed in all UAs in the group. For example, rules
that govern assigning appearance numbers for incoming requests (e.g.
lowest available appearance number) and rules for contention handling
(e.g. when two UAs request the use of the same appearance number,
hash dialog identifiers and compare with the lowest hash winning)
would need to be defined and implemented.
REQs 6-13 can be implemented using a number of approaches, as
Johnston, et al. Expires August 29, 2007 [Page 6]
Internet-Draft SIP Reqs for MLA February 2007
discussed in the following sections.
Figure 1 illustrates the SIP components involved in supporting these
common requirements of the Multiple Appearance using standard SIP
messages including REGISTER, INVITE, SUBSCRIBE, NOTIFY, and PUBLISH.
+----------------------------+ +----+
| | | |
| Appearance Agent | | UA |
| | | |
+----------------------------+ +----+
^ ^ |1)SUBSCRIBE ^ ^ 4)NOTIFY INVITE |
| | |(Event:reg) | | registration sip:alice@example.com|
| | V | | events V
| | +--------------------+ +----------+7)Query+--------+
| | | (example.com) | | |<===== | |
| | | |3) Store| Location | | Proxy |
| | | Registrar |=======>| Service | | |
| | | | | |=====> | |
| | +--------------------+ +----------+8)Resp +--------+
| | ^ ^ | |
| | | | 2) REGISTER (alice) | |
| | | | | |
| | +----+ +----+ | |
| | | | | | | |
| | |UA1 | |UA2 | | |
| | | | | | | |
| | +----+ +----+ | |
| | ^ ^ ^ ^ | |
| | | | | | | |
| +----+ | | | | |
| | | +--------------------------------------+ |
| +----+-------------------------------------------+
| | 8) INVITE
+--------------+ sip:alice@example.com
5-7) SUBSCRIBE and/or PUBLISH
(Event:dialog)
Figure 1.
The next section discusses normal SIP operations used to implement
parts of the multiple appearance feature.
1. The Appearance Agent SUBSCRIBES to the registration event package
as outlined in [8] for contacts registered to the group AOR. Thus,
it has knowledge of all User Agents registered against the AOR at any
point of time.
Johnston, et al. Expires August 29, 2007 [Page 7]
Internet-Draft SIP Reqs for MLA February 2007
2. UAs (UA1 and UA2 in Figure 1) belong to the appearance group and
REGISTER against the same AOR (e.g., sip:alice@example.com).
3. Each registration is stored in the Location Service.
4. The registrar notifies the Appearance Agent of successful
registration at each UA.
5. UAs PUBLISH their dialog state to the State Agent in the
Appearance Agent. Alternatively, the Appearance Agent could
SUBSCRIBE to the dialog state of each UA in the group.
6. The UAs SUBSCRIBE to the Appearance Agent for the state of all
dialogs as defined in [7]. The Request-URI of the SUBSCRIBE could be
either the AOR of the group, the Contact URI information it received
in the incoming subscription from the Appearance Agent, or a
provisioned URI.
7. The UAs PUBLISH their dialog information to the Appearance Agent
every time their dialog state changes (i.e. receive an INVITE, enter
alerting state, answer a call, terminate a call, generate an INVITE,
etc.) Note that alternatively the Appearance Agent could also
SUBSCRIBE to the dialog state of each UA in the group.
8. Forking Proxy forks an incoming INVITE for the AOR address to the
registered user agents.
The User Agents in the group could SUBSCRIBE to each other and NOTIFY
dialog state events, but in a large group the User Agents have to
manage a larger number of SUBSCRIPTIONS and NOTIFICATIONS. The State
Agent in the Appearance Agent helps in managing large groups better.
Further, the State Agent can filter dialog state events and NOTIFY
User Agents of the dialog state events which are required for the
application or feature. The State Agent can also SUBSCRIBE to dialog
state events with filters to reduce the number of NOTIFY messages
exchanged between the State Agent and the user agents in the group.
This allows a group of N UAs to each only establish a pair of dialog
state subscriptions (one in each direction) to learn the dialog state
of all other group members. This results in 2N total subscriptions
for the entire group. A full mesh of subscriptions without a state
agent would result in N(N-1) total subscriptions.
The Appearance Agent can select the appearance number for an incoming
call. The appearance number is a non-negative integer: 0,1,2, etc.
An Appearance agent can use the registration event package to learn
how many UAs are part of the group. The Appearance Agent sends a
NOTIFY of dialog state events to all the User Agents.
Johnston, et al. Expires August 29, 2007 [Page 8]
Internet-Draft SIP Reqs for MLA February 2007
5.1. Appearance Implementation Options
This section discusses and compares multiple methods of implementing,
conveying, and selecting appearances in SIP while meeting the
requirements of Section 4. These approaches are a URI parameter and
a SIP dialog package extension parameter. All the approaches here
assume the common elements and operations of Figure 1. In addition,
this section discusses approaches for incoming appearance indication,
REQ-9, and appearance contention, REQ-8. These approaches will be
discussed for an example appearance group of N phones each with n
line appearances. The usage of the word phone does not imply that
this feature is limited to telephony devices.
5.1.1. URI parameter Approach
Some implementations of this feature utilize a URI parameter such as
"line=3" on the Contact URI. Each appearance is effectively a
logical UA, so each line appearance requires a separate registration.
The number of line appearances needs to be provisioned on each phone.
Each appearance also requires a separate dialog package subscription.
Even using a State Agent for the dialog package, each phone must
maintain n subscriptions to the dialog package.
This results in 2nN total subscriptions and nN registrations for this
implementation.
Since Contact URI parameters will be conveyed by the dialog package,
REQ-7 is met.
REQ-10 can be met by having the Appearance Agent send a SUBSCRIBE to
each UA and line number to obtain the current dialog state - this
will result in nN SUBSCRIBEs and NOTIFYs.
It is not obvious how to meet REQ-11 with this approach. A UA
registering against the AOR but does not implement the appearance URI
parameter will not include a line appearance number in Contact URIs
and dialog package NOTIFYs. The Appearance Agent will have no way of
indicating to the other UAs the appearance number being used by this
UA, as adding a parameter to the Contact URI would cause call control
operations such as Replaces and Join to fail.
REQs 12 and 13 are difficult to meet with this approach as the line
appearance number will be present in the Request-URI of incoming
requests and the Contact URI in INVITE and 200 OK messages. This
approach will require integrity protection of all dialog creating
requests and responses, and privacy mechanisms to hide the Contact
URI from other UAs.
Johnston, et al. Expires August 29, 2007 [Page 9]
Internet-Draft SIP Reqs for MLA February 2007
Also, this approach will require mechanisms to protect against
another UA sending an INVITE directly to a group member with the line
appearance number already set.
5.1.2. Dialog Package Parameter
Instead of the URI parameter approach, consider an extension
parameter "appearance" to the SIP dialog package as defined in
[draft-anil-sipping-bla-04], e.g.:
...
In this approach, the appearance number is never carried in a
Request-URI or Contact URI. Instead, it is only present in dialog
package NOTIFY and PUBLISH messages. As a result, only a single
registration per AOR is required. Also, only a single dialog package
subscription in each direction per AOR.
This results in 2N total subscriptions and N registrations for this
approach.
If the dialog package is extended to carry the appearance number,
then REQ-7 is met.
REQ-10 can be met by having the Appearance Agent send a SUBSCRIBE to
each UA and line number to obtain the current dialog state - this
will result in N SUBSCRIBEs and NOTIFYs.
REQ-11 can be met by this approach. Even though a UA does not
provide an appearance number in dialog package NOTIFYs, the
Appearance Agent can assign one and include it in NOTIFYs to the
other UAs. This parameter would simply be ignored by the UAs that
did not understand the parameter, and have no impact on call control
Johnston, et al. Expires August 29, 2007 [Page 10]
Internet-Draft SIP Reqs for MLA February 2007
operations.
REQs 12 and 13 are met because the appearance number is only conveyed
in dialog package NOTIFYs. Integrity and privacy of NOTIFY bodies
can be achieved using normal SIP mechanisms independent of the
security mechanisms used for other requests.
With this approach, the number of appearances is centrally managed
and controlled by the Appearance Agent. For UAs with soft keys or
buttons, this gives a great deal of flexibility in system management.
5.1.3. Incoming Appearance Assignment
To best meet REQ-9, the appearance number for an incoming INVITE
should be contained in the INVITE itself.
For the URI parameter approach, REQ-9 is met since incoming requests
will have the line appearance number in the Request-URI. However,
this requires the forking proxy know which line appearance number has
been selected by the Appearance Agent and to fork the INVITE to only
those Contact URIs. This means that a simple forking proxy server
can not be used with this implementation option.
For the dialog package parameter approach, REQ-9 could be met in two
ways. When an incoming request is received, the Appearance Agent
could send out a NOTIFY with state trying and include the appearance
number to be used for this request. Upon receipt of this NOTIFY, the
UAs could being alerting using the appearance number selected. This
approach is sub-optimal since the UAs could receive the INVITE but be
unable to begin alerting if the NOTIFY from the Appearance Agent is
delayed or lost
An alternative approach is to define an extension parameter is
defined for the Alert-Info header field in RFC 3261 as in
[draft-anil-sipping-bla-04], e.g.
Alert-Info: ;alert=normal;appearance=0
This Alert-Info header would indicate to place the call on the first
line appearance instance.
The determination as to what value to use in the appearance parameter
can be done at the proxy that forks the incoming request to all the
registered UAs. There are a variety of ways the proxy can use to
determine what value it should use to populate this parameter. For
example, the proxy could fetch this information by initiating a
SUBSCRIBE request with Expires: 0 to the Appearance Agent for the AOR
to fetch the list of lines that are in use. Alternatively, it could
Johnston, et al. Expires August 29, 2007 [Page 11]
Internet-Draft SIP Reqs for MLA February 2007
act like a UA that is a part of the appearance group and SUBSCRIBE to
the State-Agent like any other UA. This would ensure that the active
dialog information is available without having to poll on a need
basis. It could keep track of the list of active calls for the
appearance AOR based on how many unique INVITE requests it has forked
to or received from the appearance AOR.
The Appearance Agent needs to know about all incoming requests to the
AOR in order to select the appearance number. One way in which this
could be done is for the Appearance Agent to register against the AOR
with a higher q value. This will result in the INVITE being sent to
the Appearance Agent first, then being offered to the UAs in the
group.
5.1.4. Appearance Contention Resolution
In the selection of an appearance for requests initiated by UAs in
the group, there is the possibility of contention where more than one
UA select the same appearance number.
One way to solve this and meet REQ-8 is to require UAs to send a
PUBLISH (trying) to the Appearance Agent indicating the appearance
number to be used for the session. The Appearance Agent would
confirm the allocation of the appearance number in a NOTIFY sent to
the group UAs. Should the appearance number be unavailable or
otherwise not allowed, there are two options:
- The PUBLISH could be rejected with a 500 response and a Retry-After
header field. The Appearance Agent would send an immediate NOTIFY
indicating that the appearance is unavailable. If the NOTIFY is
received before the expiration of the Retry-After time, the PUBLISHed
state information would become out of date and would be discarded
without resending. The UA would select another appearance number and
PUBLISH again.
- The PUBLISH could be accepted but an immediate NOTIFY generated by
the Appearance Agent indicating that the appearance is unavailable.
The UA would then select another appearance number and PUBLISH again.
UAs would wait for a notification from the Appearance Agent before
sending the INVITE.
5.2. Comparison
In comparing the URI parameter and the dialog package parameter,
there are clear differences in the number of registrations and
subscriptions, with the dialog package approach requiring n times
fewer in both cases.
Johnston, et al. Expires August 29, 2007 [Page 12]
Internet-Draft SIP Reqs for MLA February 2007
The security model for the dialog package parameter approach is much
cleaner, since only NOTIFYs need integrity and privacy. The security
model for the URI parameter approach would likely require a B2BUA
which introduces many undesirable properties.
The dialog package parameter approach has better backwards
compatibility than the URI parameter approach.
In summary, the dialog package parameter approach better meets REQs
5, 10, 11, 12, and 13 while the URI parameter approach better meets
REQ-9. However, the combined dialog package parameter approach and
the Alert-Info parameter approach meets REQ-9.
6. IANA Considerations
None.
7. Security Considerations
Since multiple line appearance features are implemented using
semantics provided by RFC 3261 [2], Event Package for Dialog State as
define in [7], and Event Notification [4], security considerations in
these documents apply to this draft as well.
Specifically, since dialog state information and the dialog
identifiers are supplied by UA's in an appearance group to other
members, the same is prone to "call hijacks". For example, a rogue
UA could snoop for these identifiers and send an INVITE with Replaces
header containing these call details to take over the call. As such
INVITES with Replaces header MUST be authenticated using the standard
mechanism (like Digest or S/MIME) described in RFC 3261 [2] before it
is accepted. NOTIFY message bodies that provide the dialog state
information and the dialog identifiers MAY be encrypted end-to-end
using the standard mechanics. All SUBSCRIBES between the UA's and
the Event Agent MUST be authenticated.
8. Informative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] 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.
Johnston, et al. Expires August 29, 2007 [Page 13]
Internet-Draft SIP Reqs for MLA February 2007
[3] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[5] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[6] Johnston, A., "Session Initiation Protocol Service Examples",
draft-ietf-sipping-service-examples-12 (work in progress),
January 2007.
[7] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", RFC 4235, November 2005.
[8] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004.
[9] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP)
"Join" Header", RFC 3911, October 2004.
[10] Kumar, A., "Implementing Bridged Line Appearances (BLA) Using
Session Initiation Protocol (SIP)", draft-anil-sipping-bla-03
(work in progress), June 2006.
[11] Niemi, A., "Session Initiation Protocol (SIP) Extension for
Event State Publication", RFC 3903, October 2004.
Authors' Addresses
Alan Johnston (editor)
Avaya
St. Louis, MO 63124
Email: alan@sipstation.com
Mohsen Soroushnejad
Sylantro Systems Corp
Email: mohsen.soroush@sylantro.com
Johnston, et al. Expires August 29, 2007 [Page 14]
Internet-Draft SIP Reqs for MLA February 2007
Venkatesh Venkataramanan
Sylantro Systems Corp
Email: venkatar@sylantro.com
Paul Pepper
Citel Technologies
Email: paul.pepper@citel.com
Anil Kumar
Yahoo Inc.
Email: anil@yahoo-inc.com
Johnston, et al. Expires August 29, 2007 [Page 15]
Internet-Draft SIP Reqs for MLA February 2007
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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Johnston, et al. Expires August 29, 2007 [Page 16]