Internet DRAFT - draft-allen-sipcore-sip-tree-cap-indicators
draft-allen-sipcore-sip-tree-cap-indicators
Sipcore Working Group A. Allen, Ed.
Internet-Draft Blackberry
Intended status: Informational R. Jesske
Expires: July 22, 2018 Deutsche Telekom
January 18, 2018
Internet Assigned Numbers Authority (IANA) Registration of the Session
Initiation Protocol (SIP) Feature-Capability indicators
draft-allen-sipcore-sip-tree-cap-indicators-02
Abstract
This document registers with IANA SIP Feature-Capability indicators
in the "SIP Feature-Capability Indicator Registration Tree" of the
IANA "Proxy-Feature Feature-Capability Indicator Trees" registry for
use with the SIP Feature-Caps header field and defines their usage
and interpretation.
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 July 22, 2018.
Copyright Notice
Copyright (c) 2018 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
Allen & Jesske Expires July 22, 2018 [Page 1]
Internet-Draft SIP Capability Indicators January 2018
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SIP Feature-Capability indicators . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5.1. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Application . . . . . . . . . . . . . . . . . . . . . . . 8
5.4. Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.5. Control . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.6. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.7. Text . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.8. Message . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.9. Interactive Connectivity Establishment . . . . . . . . . . 12
5.10. Application Subtype . . . . . . . . . . . . . . . . . . . 12
5.11. Fax . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Allen & Jesske Expires July 22, 2018 [Page 2]
Internet-Draft SIP Capability Indicators January 2018
1. Introduction
RFC 6809 [1] specifies the SIP Feature-Caps header field that conveys
feature-capability indicators that are used to indicate support of
features and capabilities for SIP entities that are not represented
by the Uniform Resource Identifier (URI) of the Contact header field.
RFC 6809 [1] also creates a new IANA registry, "Proxy-Feature
Feature-Capability Indicator Trees", for registering feature-
capability indicators including a SIP feature-capability indicator
tree for registering SIP feature-capability indicators that is
similar to the media feature tag SIP tree defined in RFC 3840 [2].
To date only one feature-capability indicator, sip.607 (RFC 8197 [8])
has been included in the SIP feature-capability indicator tree.
This document populates this SIP tree with some additional feature-
capability indicators that are based upon those already defined in
RFC 3840 [2], RFC 4569 [3], RFC 5768 [4], RFC 5688 [5] and RFC 6913
[6] and also defines an additional SIP feature-capability indicator
"Contact-features" that allows an intermediary to indicate a contact
address and the capabilitie supported by that intermediary if SIP
Requests are sent to that contact address.
2. Motivation
SIP sessions often involve intermediaries (typically acting as
B2BUAs) that in addition to forwarding SIP requests and responses can
also act as UAs to perform more complex manipulations of the session.
Examples of such intermediaries include IP PBXs (Internet Protocol
Private Branch Exchanges), Telephony Call Feature Application Servers
and Session Transfer Anchor Points. Often the manipulations of the
session by the intermediary are initiated by one of the UAs in the
session sending a request (such as REFER request) to the intermediary
to for example transfer the session or create a conference.
Additionally UAs may also need to subscribe to events related to the
session with the intermediary accepting such subscriptions and
providing the notification of event state changes.
Typically such functionality has been achieved by sending such REFER
and SUBSCRIBE requests within the established dialog for the session,
with the intermediary then intercepting and processing the REFER or
SUBSCRIBE request rather than forwarding it to the remote UAS.
However such dialog reuse has been problematic and RFC 6665 [9] has
deprecated dialog reuse (except for legacy interoperability).
However, in order to avoid reusing the same dialog as the session and
achieve equivalent functionality when interacting with intermediaries
using for instance REFER request requires that the UA obtain the
Globally Routable User Agent URI (GRUU) of the intermediary and also
Allen & Jesske Expires July 22, 2018 [Page 3]
Internet-Draft SIP Capability Indicators January 2018
know that the intermediary supports the relevant capabilities such as
the required SIP methods (i.e. REFER) as well as the needed SIP
extensions, (such as target dialog extension specified in RFC 4538 in
[10]).
Typically B2BUAs have acted as two UAs back-to-back with the Contact
URI being the URI of the B2BUA. However this means that GRUU of the
UA is overwritten by the B2BUA and the meaning of the Contact header
field parameters becomes obscure. Do the Contact header field
parameters reflect the capabilities of the Contact address (i.e. the
B2BUA) or do they reflect the capabilities of the remote UA? If they
reflect the capabilities of the B2BUA then the identification of the
capabilities of the remote UA have been lost. If they reflect the
capabilities of the remote UA then they falsely identify that the
B2BUA contact address has the capabilities of the remote UA.
Another use case for B2BUAs is in control of Application Level
Gateways (ALGs). These ALGs are controlled by SIP intermediaries
that act as routing B2BUs and perform media functions such as IP
address translation, transcoding, and media policing. Such ALGs may
only support some media types while blocking others. It is useful if
the media types that are allowed can be communciated to other
entities in the SIP signaling so that fruitless attempts to establish
sessions with media types that will not be allowed are not
attempted.Such functionality is required by 3GPP IMS (IP Multimedia
Subsystem) to avoid unnecessary failed session establishment
attempts.
What is needed is a way for intermediaries to pass the remote UA's
contact address and capabilities transparently in the Contact header
field while being able to indicate their own contact address (i.e
GRUU) and associated capabilities to the UA.
RFC 6809 [1] provides that addresses of intermediaries can be
communicated as a value of an associated feature-capability
indicator. What is needed is a feature capability indicator to
communicate the contact address GRUU (Globally Routable User Agent
URI of the intermediary along with the associated media feature-
capability indicators tags representing the capabilities supported by
that of the intermediary if SIP Requests are sent to that contact
address. The feature-capability indicators for communicating SIP
related capabilities (e.g. supported SIP Methods and extensions) also
need to be registered in the SIP tree in order to allow an
intermediary to indicate the SIP features it supports when forwarding
SIP requests or the media capabilities it supports as an ALG.
Allen & Jesske Expires July 22, 2018 [Page 4]
Internet-Draft SIP Capability Indicators January 2018
3. SIP Feature-Capability indicators
This document defines a new Feature-Capability indicator in the SIP
tree:
sip.contact
The sip.contact Feature-Capability indicator provides a GRUU as the
contact address of the intermediary along with a list of all the
Fmedia feature tags representing the capabilities of the intermediary
supported by that intermediary if SIP Requests areent to that contact
address.
The following media feature tags from RFC 3840 [2]", RFC 4569 [3],
RFC 5768 [4], RFC 5688 [5] and RFC 6913 [6] are considered to be
useful to also be defined as Feature-Capability indicators:
sip.audio
sip.application
sip.data
sip.control
sip.video
sip.text
sip.message
sip.ice
sip.app-subtype
sip.fax
An intermediary that includes at least feature capability indicator
of one of the above media capabilities SHOULD include all the feature
capability indicators for the media it will allow. The absence of a
media capability from the list of feature capability indicators MAY
be interpreted by another entity as indicating that this media is not
allowed. The lack of indication of any of the above media
capabilities SHOULD be interpreted as inconclusive information about
what media is allowed or not allowed.
The following media feature tags from RFC 3840 [2], RFC 4235 [11] and
RFC 5626 [12] are currently NOT considered to be useful to be defined
as Feature-Capability indicators since they do not represent stream
types likely to be implemented by an intermediary:
sip.automata
sip.class
sip.mobility
sip.actor
sip.byeless
sip.rendering
sip.instance
Allen & Jesske Expires July 22, 2018 [Page 5]
Internet-Draft SIP Capability Indicators January 2018
sip.duplex
sip.description
sip.events
sip.priority
sip.methods
sip.extensions
sip.schemes
sip.isfocus
4. Security Considerations
The security considerations in RFC 3840 [2] and RFC 6809 [1] apply to
the use of Feature-capability indicators in the SIP tree.
5. IANA Considerations
This specification registers the following new feature-capability
indicators in the SIP tree per the procedures defined in RFC 6809
[12].
5.1. Contact
Feature-capability indicator name: sip.contact
Description:
This Feature-capability indicator indicator provides a GRUU as the
contact address of the intermediary along with a list of all the
media feature tags representing the capabilities of the
intermediary supported by that intermediary if SIP Requests are
sent to that contact address.
Feature-capability indicator specification reference: The present
document.
Additional information:
Values appropriate for use with this Feature-Capability
indicator:
String with an equality relationship. The Syntax for the
string is the same as the of the contents of the Contact header
field defined in RFC 3261 [7].
Allen & Jesske Expires July 22, 2018 [Page 6]
Internet-Draft SIP Capability Indicators January 2018
This Feature-Capability indicator is most useful in a
communications application, such as an IP-PBX or conference
bridge for providing a contact address and the capabilities of
a network intermediary at that contact address.
Examples of typical use: An conference server indicating that
it is capable of accepting SIP REFER requests for inviting 3rd
parties to a conference.
Security Considerations: Security considerations for this
Feature-capability indicator are discussed in RFC 6809 [1] and
RFC 3840 [2].
5.2. Audio
Feature-capability indicator name: sip.audio
Description:
This Feature-capability indicator indicates that the intermediary
supports audio as a streaming media type for sessions established
via it.
Feature-capability indicator specification reference: RFC 3840
[2].
Additional information:
Values appropriate for use with this Feature-Capability
indicator: Boolean.
This Feature-Capability indicator is most useful in a
communications application for describing the capabilities of a
network intermediary, such as an IP-PBX or conference bridge.
Examples of typical use: An IP PBX indicating that it is
capable of accepting and initiating sessions with audio as a
streaming media type.
Security Considerations: Security considerations for this
Feature-capability indicator are discussed in RFC 6809 [1] and
RFC 3840 [2].
Allen & Jesske Expires July 22, 2018 [Page 7]
Internet-Draft SIP Capability Indicators January 2018
5.3. Application
Feature-capability indicator name: sip.application
Description:
This Feature-capability indicator indicates that the intermediary
supports application as a streaming media type for sessions
established via it.
Feature-capability indicator specification reference: RFC 3840
[2].
Additional information:
Values appropriate for use with this Feature-Capability
indicator: Boolean.
This Feature-Capability indicator is most useful in a
communications application for describing the capabilities of a
network intermediary, such as an IP-PBX or conference bridge.
Examples of typical use: An IP PBX indicating that it is
capable of accepting and initiating sessions with a media
control application.
Security Considerations: Security considerations for this
Feature-capability indicator are discussed in RFC 6809 [1] and
RFC 3840 [2].
5.4. Data
Feature-capability indicator name: sip.data
Description:
This Feature-capability indicator indicates that the intermediary
supports data as a streaming media type for sessions established
via it.
Feature-capability indicator specification reference: RFC 3840
[2].
Allen & Jesske Expires July 22, 2018 [Page 8]
Internet-Draft SIP Capability Indicators January 2018
Additional information:
Values appropriate for use with this Feature-Capability
indicator: Boolean.
This Feature-Capability indicator is most useful in a
communications application for describing the capabilities of a
network intermediary, such as an IP-PBX or conference bridge.
Examples of typical use: An IP PBX indicating that it is
capable of accepting and initiating sessions with data as a
streaming media type.
Security Considerations: Security considerations for this
Feature-capability indicator are discussed in RFC 6809 [1] and
RFC 3840 [2].
5.5. Control
Feature-capability indicator name: sip.control
Description:
This Feature-capability indicator indicates that the intermediary
supports control as a streaming media type for sessions
established via it.
Feature-capability indicator specification reference: RFC 3840
[2].
Additional information:
Values appropriate for use with this Feature-Capability
indicator: Boolean.
This Feature-Capability indicator is most useful in a
communications application for describing the capabilities of a
network intermediary, such as an IP-PBX or conference bridge.
Examples of typical use: A conference bridge indicating that it
is capable of supporting a floor control application.
Security Considerations: Security considerations for this
Feature-capability indicator are discussed in RFC 6809 [1] and
RFC 3840 [2].
Allen & Jesske Expires July 22, 2018 [Page 9]
Internet-Draft SIP Capability Indicators January 2018
5.6. Video
Feature-capability indicator name: sip.video
Description:
This Feature-capability indicator indicates that the intermediary
supports video as a streaming media type for sessions established
via it.
Feature-capability indicator specification reference: RFC 3840
[2].
Additional information:
Values appropriate for use with this Feature-Capability
indicator: Boolean.
This Feature-Capability indicator is most useful in a
communications application for describing the capabilities of a
network intermediary, such as an IP-PBX or conference bridge.
Examples of typical use: An IP PBX indicating that it is
capable of accepting and initiating sessions with video as a
streaming media type.
Security Considerations: Security considerations for this
Feature-capability indicator are discussed in RFC 6809 [1] and
RFC 3840 [2].
5.7. Text
Feature-capability indicator name: sip.text
Description:
This Feature-capability indicator indicates that the intermediary
supports text as a streaming media type for sessions established
via it.
Feature-capability indicator specification reference: RFC 3840
[2].
Additional information:
Allen & Jesske Expires July 22, 2018 [Page 10]
Internet-Draft SIP Capability Indicators January 2018
Values appropriate for use with this Feature-Capability
indicator: Boolean.
This Feature-Capability indicator is most useful in a
communications application for describing the capabilities of a
network intermediary, such as an IP-PBX or conference bridge.
Examples of typical use: An IP PBX indicating that it is
capable of accepting and initiating sessions with text as a
streaming media type.
Security Considerations: Security considerations for this
Feature-capability indicator are discussed in RFC 6809 [1] and
RFC 3840 [2].
5.8. Message
Feature-capability indicator name: sip.message
Descrition:
This Feature-capability indicator indicates that the intermediary
supports message as a streaming media type for sessions
established via it.
Feature-capability indicator specification reference: RFC 4569
[3].
Additional information:
Values appropriate for use with this Feature-Capability
indicator: Boolean.
This Feature-Capability indicator is most useful in a
communications application for describing the capabilities of a
network intermediary, such as an IP-PBX or conference bridge.
Examples of typical use: An IP PBX indicating that it is
capable of accepting and initiating sessions with message as a
streaming media type.
Security Considerations: Security considerations for this
Feature-capability indicator are discussed in RFC 6809 [1], RFC
3840 [2] and RFC 4569 [3].
Allen & Jesske Expires July 22, 2018 [Page 11]
Internet-Draft SIP Capability Indicators January 2018
5.9. Interactive Connectivity Establishment
Feature-capability indicator name: sip.ice
Description:
This Feature-capability indicator indicates that the intermediary
supports Interactive Connectivity Establishment (ICE) for sessions
established via it.
Feature-capability indicator specification reference: RFC 5768
[4].
Additional information:
Values appropriate for use with this Feature-Capability
indicator: Boolean.
This Feature-Capability indicator is most useful in a
communications application for describing the capabilities of a
network intermediary, such as an IP-PBX or conference bridge.
Examples of typical use: An IP PBX indicating that it is
capable of using ICE to establish media connectivity for
sessions.
Security Considerations: Security considerations for this
Feature-capability indicator are discussed in RFC 6809 [1], RFC
3840 [2] and RFC 5768 [4].
5.10. Application Subtype
Feature-capability indicator name: sip.app-subtype
Description:
This Feature-capability indicator indicates the MIME application
subtypes supported by the intermediary for purposes of streaming
media for sessions established via it.
Feature-capability indicator specification reference: RFC 5688
[5].
Additional information:
Allen & Jesske Expires July 22, 2018 [Page 12]
Internet-Draft SIP Capability Indicators January 2018
Values appropriate for use with this Feature-Capability
indicator: Token (equality relationship).
This Feature-Capability indicator is most useful in a
communications application for describing the capabilities of a
network intermediary, such as an IP-PBX or conference bridge.
Examples of typical use: A conference server indicating that it
supports an application specific media burst control protocol
for Push to Talk sessions.
Security Considerations: Security considerations for this
Feature-capability indicator are discussed in RFC 6809 [1], RFC
3840 [2] and RFC 5688 [5].
5.11. Fax
Feature-capability indicator name: sip.fax
Description:
This Feature-capability indicator indicates whether an
intermediary accepts sessions using the ITU-T T.38 [13] fax
protocol ("t38") or the passthrough method of fax transmission
using the ITU-T G.711 [14] audio codec ("passthrough").
Feature-capability indicator specification reference: RFC 6913
[6].
Additional information:
Values appropriate for use with this Feature-Capability
indicator: Token with an equality relationship. Values are:
t38: The device supports the "image/t38" media type (RFC
3326) [15] and implements ITU-T T.38 [13] for transporting
the ITU-T T.30 [16] and ITU-T T.4 [17] fax data over IP.
passthrough: The device supports the "audio/pcmu" and
"audio/ pcma" media types (RFC4856) [18] for transporting
ITU-T T.30 [16] and ITU-T T.4 [17] fax data using the ITU-T
G.711 [14] audio codec.
This Feature-Capability indicator is most useful in a
communications application for describing the capabilities of a
network intermediary, such as an IP-PBX or conference bridge.
Allen & Jesske Expires July 22, 2018 [Page 13]
Internet-Draft SIP Capability Indicators January 2018
Examples of typical use: A conference bridge indicating that it
is capable of distributing T.38 fax media to the participants
in a conference.
Security Considerations: Security considerations for this
Feature-capability indicator are discussed in RFC 6809 [1], RFC
3840 [2] and RFC 6913 [6].
6. Acknowledgements
This document draws heavily on text from the earlier work on RFC 6809
[1], RFC 3840 [2], RFC 4569 [3], RFC 5768 [4], RFC 5688 [5] and RFC
6913 [6]. The author would like to thank the authors of these RFCs:
Christer Holmber, Ivo Sedlacek, Hadriel Kaplan, Jonathan Rosenberg
Henning Schulzrinne, Paul Kyzivat, Gonzalo Camarillo, D Hanes, G
Salgueiro and K Fleming for their earlier work.
7. References
7.1. Normative References
[1] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to
Indicate Support of Features and Capabilities in the Session
Initiation Protocol (SIP)", RFC 6809, DOI 10.17487/RFC6809,
November 2012, <https://www.rfc-editor.org/info/rfc6809>.
[2] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
User Agent Capabilities in the Session Initiation Protocol
(SIP)", RFC 3840, DOI 10.17487/RFC3840, August 2004,
<https://www.rfc-editor.org/info/rfc3840>.
[3] Camarillo, G., "Internet Assigned Number Authority (IANA)
Registration of the Message Media Feature Tag", RFC 4569,
DOI 10.17487/RFC4569, July 2006,
<https://www.rfc-editor.org/info/rfc4569>.
[4] Rosenberg, J., "Indicating Support for Interactive Connectivity
Establishment (ICE) in the Session Initiation Protocol (SIP)",
RFC 5768, DOI 10.17487/RFC5768, April 2010,
<https://www.rfc-editor.org/info/rfc5768>.
[5] Rosenberg, J., "A Session Initiation Protocol (SIP) Media
Feature Tag for MIME Application Subtypes", RFC 5688,
DOI 10.17487/RFC5688, January 2010,
<https://www.rfc-editor.org/info/rfc5688>.
Allen & Jesske Expires July 22, 2018 [Page 14]
Internet-Draft SIP Capability Indicators January 2018
[6] Hanes, D., Salgueiro, G., and K. Fleming, "Indicating Fax over
IP Capability in the Session Initiation Protocol (SIP)",
RFC 6913, DOI 10.17487/RFC6913, March 2013,
<https://www.rfc-editor.org/info/rfc6913>.
[7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261,
June 2002, <https://www.rfc-editor.org/info/rfc3261>.
7.2. Informative References
[8] Schulzrinne, H., "A SIP Response Code for Unwanted Calls",
RFC 8197, DOI 10.17487/RFC8197, July 2017,
<https://www.rfc-editor.org/info/rfc8197>.
[9] Roach, A., "SIP-Specific Event Notification", RFC 6665,
DOI 10.17487/RFC6665, July 2012,
<https://www.rfc-editor.org/info/rfc6665>.
[10] Rosenberg, J., "Request Authorization through Dialog
Identification in the Session Initiation Protocol (SIP)",
RFC 4538, DOI 10.17487/RFC4538, June 2006,
<https://www.rfc-editor.org/info/rfc4538>.
[11] Rosenberg, J., Schulzrinne, H., and R. Mahy, Ed., "An INVITE-
Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", RFC 4235, DOI 10.17487/RFC4235, November 2005,
<https://www.rfc-editor.org/info/rfc4235>.
[12] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., "Managing
Client-Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, DOI 10.17487/RFC5626, October 2009,
<https://www.rfc-editor.org/info/rfc5626>.
[13] International Telecommunication Union, "Procedures for real-
time Group 3 facsimile communication over IP Networks", ITU-
T Recommendation T.38, October 2010.
[14] International Telephone and Telegraph Consultative Committee,
"Pulse Code Modulation (PCM) of Voice Frequencies",
CCITT Recommendation G.711, 1972.
[15] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header
Field for the Session Initiation Protocol (SIP)", RFC 3326,
DOI 10.17487/RFC3326, December 2002,
<https://www.rfc-editor.org/info/rfc3326>.
Allen & Jesske Expires July 22, 2018 [Page 15]
Internet-Draft SIP Capability Indicators January 2018
[16] International Telecommunication Union, "Procedures for document
facsimile transmission in the general switched telephone
network", ITU-T Recommendation T.30, September 2005.
[17] International Telecommunication Union, "Standardization of
Group 3 facsimile terminals for document transmission", ITU-
T Recommendation T.4, July 2003.
[18] Casner, S., "Media Type Registration of Payload Formats in the
RTP Profile for Audio and Video Conferences", RFC 4856,
DOI 10.17487/RFC4856, February 2007,
<https://www.rfc-editor.org/info/rfc4856>.
Authors' Addresses
Andrew Allen (editor)
Blackberry
1560 Sawgrass Corporate Parkway
Sunrise, Florida 33323
USA
Email: aallen@blackberry.com
Roland Jesske
Deutsche Telekom
Heinrich-Hertz Str. 3-7
Darmstadt 64295
Germany
Email: r.jesske@telekom.de
Allen & Jesske Expires July 22, 2018 [Page 16]
