Internet DRAFT - draft-jesske-sipcore-sip-tree-cap-indicators
draft-jesske-sipcore-sip-tree-cap-indicators
Sipcore Working Group R. Jesske, Ed.
Internet-Draft Deutsche Telekom
Intended status: Informational June 18, 2018
Expires: December 20, 2018
Internet Assigned Numbers Authority (IANA) Registration of the Session
Initiation Protocol (SIP) Feature-Capability indicators
draft-jesske-sipcore-sip-tree-cap-indicators-00
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 https://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 December 20, 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
(https://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
Jesske Expires December 20, 2018 [Page 1]
Internet-Draft SIP Capability Indicators June 2018
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SIP Feature-Capability indicators . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5.1. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Application . . . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . 13
5.11. Fax . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
RFC 6809 [2] 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 [2] 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 [3].
To date only one feature-capability indicator, sip.607 (RFC 8197
[14]) 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 [3], RFC 4569 [4], RFC 5768 [5], RFC 5688 [6] and RFC 6913
[7] and also defines an additional SIP feature-capability indicator
"Contact-features" that allows an intermediary to indicate a contact
address and the capabilities supported by that intermediary if SIP
Requests are sent to that contact address.
Jesske Expires December 20, 2018 [Page 2]
Internet-Draft SIP Capability Indicators June 2018
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 [8] 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
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
[9]).
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 communicated to other
entities in the SIP signaling so that fruitless attempts to establish
Jesske Expires December 20, 2018 [Page 3]
Internet-Draft SIP Capability Indicators June 2018
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 [2] 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.
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
media 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 [3]", RFC 4569 [4],
RFC 5768 [5], RFC 5688 [6] and RFC 6913 [7] are considered to be
useful to also be defined as Feature-Capability indicators:
Jesske Expires December 20, 2018 [Page 4]
Internet-Draft SIP Capability Indicators June 2018
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 [3], RFC 4235 [10] and
RFC 5626 [11] 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
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 [3] and RFC 6809 [2] apply to
the use of Feature-capability indicators in the SIP tree.
Jesske Expires December 20, 2018 [Page 5]
Internet-Draft SIP Capability Indicators June 2018
5. IANA Considerations
This specification registers the following new feature-capability
indicators in the SIP tree per the procedures defined in RFC 6809
[11].
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 [1].
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.
Jesske Expires December 20, 2018 [Page 6]
Internet-Draft SIP Capability Indicators June 2018
Security Considerations: Security considerations for this Feature-
capability indicator are discussed in RFC 6809 [2] and RFC 3840 [3].
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 [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 audio as a streaming media
type.
Security Considerations: Security considerations for this Feature-
capability indicator are discussed in RFC 6809 [2] and RFC 3840 [3].
5.3. Application
Feature-capability indicator name: sip.application
Description:
Jesske Expires December 20, 2018 [Page 7]
Internet-Draft SIP Capability Indicators June 2018
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 [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 a media control application.
Security Considerations: Security considerations for this Feature-
capability indicator are discussed in RFC 6809 [2] and RFC 3840 [3].
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 [3].
Additional information:
Jesske Expires December 20, 2018 [Page 8]
Internet-Draft SIP Capability Indicators June 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 data as a streaming media
type.
Security Considerations: Security considerations for this Feature-
capability indicator are discussed in RFC 6809 [2] and RFC 3840 [3].
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 [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: A conference bridge indicating that it is
capable of supporting a floor control application.
Jesske Expires December 20, 2018 [Page 9]
Internet-Draft SIP Capability Indicators June 2018
Security Considerations: Security considerations for this Feature-
capability indicator are discussed in RFC 6809 [2] and RFC 3840 [3].
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 [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 video as a streaming media
type.
Security Considerations: Security considerations for this Feature-
capability indicator are discussed in RFC 6809 [2] and RFC 3840 [3].
5.7. Text
Feature-capability indicator name: sip.text
Description:
Jesske Expires December 20, 2018 [Page 10]
Internet-Draft SIP Capability Indicators June 2018
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 [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 text as a streaming media
type.
Security Considerations: Security considerations for this Feature-
capability indicator are discussed in RFC 6809 [2] and RFC 3840 [3].
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 [4].
Additional information:
Jesske Expires December 20, 2018 [Page 11]
Internet-Draft SIP Capability Indicators June 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 message as a streaming media
type.
Security Considerations: Security considerations for this Feature-
capability indicator are discussed in RFC 6809 [2], RFC 3840 [3] and
RFC 4569 [4].
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 [5].
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.
Jesske Expires December 20, 2018 [Page 12]
Internet-Draft SIP Capability Indicators June 2018
Security Considerations: Security considerations for this Feature-
capability indicator are discussed in RFC 6809 [2], RFC 3840 [3] and
RFC 5768 [5].
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 [6].
Additional information:
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 [2], RFC 3840 [3] and
RFC 5688 [6].
5.11. Fax
Feature-capability indicator name: sip.fax
Description:
Jesske Expires December 20, 2018 [Page 13]
Internet-Draft SIP Capability Indicators June 2018
This Feature-capability indicator indicates whether an intermediary
accepts sessions using the ITU-T T.38 [15] fax protocol ("t38") or
the passthrough method of fax transmission using the ITU-T G.711 [16]
audio codec ("passthrough").
Feature-capability indicator specification reference: RFC 6913 [7].
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) [12]
and implements ITU-T T.38 [15] for transporting the ITU-T T.30 [17]
and ITU-T T.4 [18] fax data over IP.
passthrough: The device supports the "audio/pcmu" and "audio/ pcma"
media types (RFC4856) [13] for transporting ITU-T T.30 [17] and ITU-T
T.4 [18] fax data using the ITU-T G.711 [16] 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.
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 [2], RFC 3840 [3] and
RFC 6913 [7].
6. Acknowledgements
This documet was generated out of draft-allen-sipcore-sip-tree-cap-
indicator which was not progressed. This document draws heavily on
text from the earlier work on RFC 6809 [2], RFC 3840 [3], RFC 4569
[4], RFC 5768 [5], RFC 5688 [6] and RFC 6913 [7]. The author would
like to thank the authors of these RFCs: Christer Holmber, Ivo
Jesske Expires December 20, 2018 [Page 14]
Internet-Draft SIP Capability Indicators June 2018
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] 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>.
[2] 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>.
[3] 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>.
[4] 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>.
[5] 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>.
[6] 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>.
[7] 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>.
Jesske Expires December 20, 2018 [Page 15]
Internet-Draft SIP Capability Indicators June 2018
7.2. Informative References
[8] Roach, A., "SIP-Specific Event Notification", RFC 6665,
DOI 10.17487/RFC6665, July 2012,
<https://www.rfc-editor.org/info/rfc6665>.
[9] 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>.
[10] 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>.
[11] 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>.
[12] 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>.
[13] 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>.
[14] Schulzrinne, H., "A SIP Response Code for Unwanted Calls",
RFC 8197, DOI 10.17487/RFC8197, July 2017,
<https://www.rfc-editor.org/info/rfc8197>.
[15] International Telecommunication Union, "Procedures for
real-time Group 3 facsimile communication over IP
Networks", ITU-T Recommendation T.38, October 2010.
[16] International Telephone and Telegraph Consultative
Committee, "Pulse Code Modulation (PCM) of Voice
Frequencies", CCITT Recommendation G.711, 1972.
Jesske Expires December 20, 2018 [Page 16]
Internet-Draft SIP Capability Indicators June 2018
[17] International Telecommunication Union, "Procedures for
document facsimile transmission in the general switched
telephone network", ITU-T Recommendation T.30, September
2005.
[18] International Telecommunication Union, "Standardization of
Group 3 facsimile terminals for document transmission",
ITU-T Recommendation T.4, July 2003.
Author's Address
Roland Jesske (editor)
Deutsche Telekom
Heinrich-Hertz Str. 3-7
Darmstadt 64295
Germany
Email: r.jesske@telekom.de
Jesske Expires December 20, 2018 [Page 17]