One document matched: draft-ietf-speermint-srv-naptr-use-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- References are listed here so that they can be called via Entity attributes later -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2434 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2434.xml">
<!ENTITY RFC2782 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml">
<!ENTITY RFC2915 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2915.xml">
<!ENTITY RFC3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY RFC3263 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3263.xml">
<!ENTITY RFC3404 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3404.xml">
<!ENTITY RFC3667 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3667.xml">
<!ENTITY RFC3761 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3761.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- PROCESSING INSTRUCTIONS - GENERAL -->
<!-- EACH ONE STARTS WITH '?' BELOW -->
<!-- give errors on I-D nits and perform DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc strict='yes' ?>
<?rfc toc='yes'?>
<!-- generate a ToC -->
<!-- the number of levels of subsections in ToC. default: 3 -->
<?rfc tocdepth='4'?>
<!-- END GENERAL PROCESSING -->
<!-- PROCESSING INSTRUCTIONS - CONTROL OF REFERENCES -->
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc symrefs='yes'?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space -->
<?rfc sortrefs='yes' ?>
<!-- do not start each main section on a new page -->
<?rfc compact='yes' ?>
<!-- keep one blank line between list items -->
<?rfc subcompact='no' ?>
<!-- END REFERENCE PROCESSING -->
<rfc ipr='pre5378Trust200902' docName='draft-ietf-speermint-srv-naptr-use-05' category='bcp'>
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3978, noModification3978, noDerivatives3978
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- FRONT SECTION -->
<front>
<title abbrev='DNS SRV and NAPTR Records for SPEERMINT'>
Use of DNS SRV and NAPTR Records for SPEERMINT
</title>
<!-- add role='editor' attribute to author tag below for the editors if appropriate -->
<author initials='T.' surname='Creighton' fullname='Tom Creighton'>
<organization abbrev='Comcast'>
Comcast Cable Communications
</organization>
<address>
<postal>
<street>One Comcast Center</street>
<street>1701 John F. Kennedy Boulevard</street>
<city>Philadelphia</city>
<region>PA</region>
<code>19103</code>
<country>US</country>
</postal>
<email>tom_creighton@cable.comcast.com</email>
<uri>http://www.comcast.com</uri>
</address>
<!-- author role='editor' is an optional value here -->
</author>
<author initials='J.' surname='Livingood' fullname='Jason Livingood'>
<organization abbrev='Comcast'>
Comcast Cable Communications
</organization>
<address>
<postal>
<street>One Comcast Center</street>
<street>1701 John F. Kennedy Boulevard</street>
<city>Philadelphia</city>
<region>PA</region>
<code>19103</code>
<country>US</country>
</postal>
<email>jason_livingood@cable.comcast.com</email>
<uri>http://www.comcast.com</uri>
</address>
<!-- author role='editor' is an optional value here -->
</author>
<date day='4' month='March' year='2009' />
<!-- META-DATA DECLARATIONS -->
<area>RAI</area>
<!-- WG name at the upperleft corner of the doc; 'Internet Engineering Task Force' is fine for individual submissions. -->
<workgroup>SPEERMINT</workgroup>
<!-- Keywords will be incorporated into HTML output files in a meta tag but they have no effect on text or nroff output. If you submit your draft to the RFC Editor, the keywords will be used for the search engine. -->
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>The objective of this document is to specify the Best Current Practice (BCP) adopted by a service provider or other organization providing multimedia communication services such as Voice over Internet Protocol(VoIP) in order to locate another service provider to peer with in the context of Session PEERing for Multimedia INTerconnect. This document attempts to fill the gaps in information from RFC 3261, RFC 3263, and other documents, in order to more assist service providers in more easily performing SIP peering.</t>
<t>[EDITORIAL NOTE: XREF ERROR GENERATED IN ABSTRACT, XREFS REMOVED]</t>
</abstract>
<!-- END META-DATA DECLARATIONS -->
</front>
<!-- END FRONT SECTION -->
<!-- MIDDLE SECTION -->
<middle>
<section anchor='ReqLang' title='Requirements Language' toc='include'>
<t>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 <xref target="RFC2119">RFC 2119</xref>.</t>
</section>
<section anchor='intro' title='Introduction' toc='include'>
<t>A service provider needs to identify the ingress Session Initiation Protocol (SIP) (<xref target="RFC3261">RFC 3261</xref>) server of a peering network before it can signal and route SIP-based real-time communications sessions. This function of locating the ingress SIP server of a peering network is typically performed by the egress SIP server of the service provider originating the SIP session. Also, the ingress server in the peering network needs to locate the originating service provider's egress server in situations where the peering connection is terminated after receiving a SIP request or if the egress SIP server of originating service provider fails. The SIP servers at the originating and peering sides use DNS procedures, using both SRV <xref target="RFC3261"/> and <xref target="RFC3404">NAPTR</xref> records, in order to locate each other. It should be noted that </t>
</section>
<section anchor='setup' title='Session Peering Setup' toc='include'>
<t>
SIP systems are represented by user agents (UA). The diagram below shows the case of Direct Peering where a user agent (UA1), hosted by a service provider (SP1), initiates a SIP session to a User Agent (UA2), hosted by another service provider (SP2). The egress SIP server of SP1 is a SIP Signaling Path Border Element (SBE) as defined in Section 3 of <xref target="SPEERMINT-Terminology"/>, called SBE1, that interfaces with session peering service provider SP2. The SIP session initiated by UA1 is received by this network element, SBE1. The resource to which the SIP request needs to be routed by SBE1 is identified by a SIP or SIPS URI. For example, this could be the SIP URI of UA2 found in the Request-URI of the SIP request received by SBE1. Alternatively, for example, this could also be the next hop from SBE1 found in the topmost Route header of SIP request. In order to determine the resource to route the request to, SP1 MAY make use of ENUM <xref target="RFC3761"/> lookup services or some other internal lookup to determine the SIP URI of the resource. Such an ENUM lookup service may use e164.arpa or one or more other private ENUM zones. This lookup MAY be performed by SBE1 or another network element of SP1.
</t>
<figure anchor='direct-peering'>
<!-- <preamble>Figure 1: Logical Peering Scenario (Direct Peering)</preamble>-->
<artwork><![CDATA[
............................ .............................
. +------+ . . +------+ .
. | | . . | | .
. | SBE 1|--------------| SBE 2| .
. / | | . . | | \ .
. / +------+ . . +------+ \ .
. +------+ / || . . || \ +------+ .
. | | / || . . || \ | | .
. | UA 1 | || . . || | UA 2 | .
. | | || . . || | | .
. +------+ || . . || +------+ .
. +-------+ . . +-------+ .
. | | . . | | .
. | DNS 1 | . . | DNS 2 | .
. | | . . | | .
. +-------+ . . +-------+ .
. . . .
. SP 1 . . SP 2 .
............................ .............................
]]></artwork>
</figure>
<t>In order to route the SIP request to this resource in SP2, SBE1 needs to determine the ingress SIP signaling path border element for SP2, called SBE2, by resolving the SIP or SIPS URI using DNS. SBE1 makes use of the NAPTR and DNS SRV mechanism defined in <xref target="RFC3263"/> to determine the IP address, port, and transport protocol for peering with the SP2 ingress SIP proxy server (i.e. SBE2). SBE1 and SBE2 which are involved in the session peering, support a set of protocols and have list of preferences for these protocols. UDP, TCP and TLS MUST be supported by these proxies [EDITORIAL NOTE: QUESTION FOR WORKING GROUP ON WHAT SHOULD BE A MUST HERE - JUST TLS OR ALL?]. </t>
<t>[EDITORIAL NOTE: ALEX SUGGESTS ADDING A REFERENCE TO TLS IN FIRST USE ABOVE]</t>
<t>As a best current practice, SBE1 and SBE2 SHOULD be deployed in a highly scalable and highly available manner, such as a cluster of servers. These servers are of different prioritization and weight, to ensure capacity-based load balancing. [EDITORIAL NOTE: CONSIDER REWORDING THIS LAST SENTENCE]</t>
<t>The figure below shows the case of Indirect Peering where SBE2 is the ingress SIP server of a transit service provider. The mechanism to locate SBE2 is the same as described for Direct Peering scenario. </t>
<figure anchor='indirect-peering'>
<!-- <preamble>Figure 2: Logical Peering Scenario (Indirect Peering) </preamble>-->
<artwork><![CDATA[
............................ .............. . .
. +------+ . . +------+ . . .
. | | . . | | . . .
. | SBE 1|---------| SBE 2| . . .
. / | | . . | | . . .
. / +------+ . . +------+ . . .
. +------+ / || . . || . . +------+ .
. | | / || . . || . . | | .
. | UA 1 | || . . || . . | UA 2 | .
. | | || . . || . . | | .
. +------+ || . . || . . +------+ .
. +-------+ . . +-------+ . . .
. | | . . | | . . .
. | DNS 1 | . . | DNS 2 | . . .
. | | . . | | . . .
. +-------+ . . +-------+ . . .
. . . . . .
. SP 1 . . Transit SP . . SP 2 .
............................ .............. ...............
]]></artwork>
</figure>
<t>The figure below shows a high level SIP call flow setting up a Direct Peering session between SP1 and SP2. In this call flow a VoIP session is established between a caller, Bob (sip:bob@example1.com), in SP1 and callee, Alice(sip:alice@example2.com), in SP2 using SIP INVITE request. All SIP signaling MUST go through both SBE1 and SBE2, as these are the ingress and egress points in SP1 and SP2 networks, respectively. </t>
<figure anchor='call-flow'>
<!-- <preamble>Figure 3: Example Call Flow (Direct Peering)</preamble>-->
<artwork><![CDATA[
Bob(UA 1) SBE 1 DNS 1 DNS 2 SBE 2 Alice(UA 2)
| | | | | |
|INVITE| | | | |
|----->| | | | |
| NAPTR Query | | |
| |----->| | | |
| NAPTR Response | | |
| |<-----| | | |
| SRV Query | | |
| |----->| | | |
| SRV Response | | |
| |<-----| | | |
| A Query | | |
| |----->| | | |
| A Response | | |
| |<-----| | | |
| | INVITE | |
| |------------------->| |
| | | | |INVITE|
| | | | |----->|
| | | | |200 OK|
| | | | |<-----|
| | 200 OK | |
| |<-------------------| |
|200 OK| | | | |
|<-----| | | | |
| ACK | | | | |
|----->| | | | |
| | ACK | |
| |------------------->| |
| | | | | ACK |
| | | | |----->|
| 2-Way Media |
|<================================>|
| | | | | |
| | | | | |
]]></artwork>
</figure>
<t>[EDITORIAL NOTE: WG Q - DO WE NEED A CALL FLOW FOR Indirect Peering?]</t>
<t>[EDITORIAL NOTE: DO WE NEED A SUB-SECTION NUMBER PRIOR TO NEXT SENTENCE? ALSO, DO WE NEED TO EXPAND IT WITH MORE TEXT?]</t>
<t>The target, to which the request is sent, is determined by SBE1 as follows: </t>
<section anchor='target_determination' title='Target Determination' toc='include'>
<t>The target resource is identified with a SIP or SIPS URI. This is the URI in the Route header, if present, or the URI from the request URI of the SIP request received by SBE1. The host value of the hostport component of the URI is the TARGET [EDITORIAL NOTE: VERIFY / CLARIFY AS NEEDED]. This TARGET is the domain to be contacted. The NAPTR/SRV/A resource record lookup as described in the following section should be skipped if the transport/port/IP address is already specified for the target URI. </t>
</section>
<section anchor='naptr_lookup' title='NAPTR Lookup' toc='include'>
<t>Next, SBE1 determines the transport protocol of the TARGET, SBE2, by performing a NAPTR query for the TARGET. NAPTR processing as described in <xref target="RFC2915"/> will result in the discovery of the most preferred transport protocol [EDITORIAL NOTE: CONSIDER REWORDING / VALIDATE PREVIOUS 3 WORDS] of a server instance of SBE2 and SRV records. </t>
<t>Considering our example call flow above [EDITORIAL NOTE: INCL LOCAL REFERENCE HERE], SBE1 wishes to resolve sip:alice@example.com and performs a NAPTR query for that TARGET domain example.com, and the following NAPTR records are returned: </t>
<figure anchor='naptr-lookup-data'>
<artwork><![CDATA[
; order pref flags service regexp replacement
IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.example.com
IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.example.com
IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.com
]]></artwork>
</figure>
<t>DNS MUST return at least three records - one with "SIP+D2T", one with "SIP+D2U" and one with "SIPS+D2T" service type for the case of Direct and Indirect Peering (section 4.3 in <xref target="SPEERMINT-Terminology"/>). For Indirect Peering (section 4.4 in <xref target="SPEERMINT-Terminology"/>) since domain validation as specified in Section 26.3.2.2 of <xref target="RFC3261"/> for TLS at layer 5 will not work, SIPS over TLS cannot be used. [EDITORIAL NOTE: J.ELWELL CONCERN RAISED - IF THIS IS CASE, FEELS WE DO NOT HAVE A SECURE SOLUTION. WG FEEDBACK?]</t>
</section>
<section anchor='srv_lookup' title='SRV Lookup' toc='include'>
<t>Depending on what transport protocols SBE1 supports, SBE1 selects one from the preference list of NAPTR results and performs the SRV lookup to obtain a list of available server instances for SBE2. TLS SHOULD be the preferred transport protocol for peering between SBE1 and SBE2. </t>
<t> In our example, SBE1 uses TCP, the SRV lookup for _sip._tcp.example.com would return this list of available servers : </t>
<figure anchor='srv-lookup-data'>
<artwork><![CDATA[
;; Priority Weight Port Target
IN SRV 0 1 5060 server1.example.com
IN SRV 0 2 5060 server2.example.com
]]></artwork>
</figure>
<t>Alternatively, if no NAPTR records are found, then SBE1 uses the preferred transport protocol and issues an SRV query for that specific transport using "sips" for SIPS URI and SIP URI with TLS and "sip" for SIP URI as the SRV domain prefix. </t>
<t> In our example, SBE1 prefers to use TCP and target SIP URI of SP2 is sip:alice@example2.com, it sends a SRV query for _sip._tcp.example2.com. </t>
<t>The SRV responses MAY also include A and/or AAAA records with it.</t>
</section>
<section anchor='using_srv' title='Using SRV Results' toc='include'>
<t>If A records or AAAA records are not returned with the SRV responses, procedures from <xref target="RFC2782"/> describes how to use and interpret the results obtained from the SRV query. The target entry of the SRV RRs is looked up by querying the DNS for address records. If the SRV response from DNS includes A or AAAA records with it, it will cut down on round trips and lookup of DNS again for target entry. On determining the transport protocol, service, port and address record from the SRV RRs as described above, the SBE1 will try to connect to the (protocol, address, service). Once the connection is established to an available instance of SBE2, SBE1 sends the SIP request to SBE2. SBE1 MUST act in a stateful manner and any retransmission of SIP requests for a specific SIP transaction, including ACKS for non-2xx response or CANCEL for that SIP transaction MUST go to the same server instance of SBE2. </t>
<t>When SBE1 sends the SIP request to SBE2, it SHOULD set the sent-by parameter of the topmost Via header in the SIP request to a domain that identifies SBE1. It MUST NOT specify the port. </t>
<t>[EDITORIAL NOTE: SHOULD THE ABOVE SENTENCE SAY MUST NOT OR SOMETHING ELSE?]</t>
<t>[EDITORIAL NOTE: ALEX SUGGESTS HAVING A SIP EXPERT REVIEW 4.2 ON SENT-BY]</t>
<t>[EDITORIAL NOTE: ALEX SUGGESTS A CALL FLOW FOR 4.2 - DOES WG AGREE?]</t>
</section>
</section>
<section anchor='ha' title='High Availability' toc='include'>
<t>High Availability is ensured by detecting failures in the ability to connect to SBE1 and SBE2 server instances. In the event of a failure, when SBE1 tries to send SIP INVITE to SBE2, the following failures could occur: </t>
<section anchor='failure1' title='SBE1 Fails to Reach SBE2' toc='include'>
<t>A 503 error response is reported by the transaction layer, or failure can occur at the transport layer due to TCP disconnect in connection, ICMP error in UDP or time out at transport layer or SIP layer timeout when its not receiving any SIP response. In such situations, SBE1 tries a new SIP request transaction to the next available server instance of SBE2 as determined by SRV RRs entry. The SIP T1 timer on SBE1 SHOULD be configurable with a upper limit value of 500ms. A shorter value of T1, say 100ms, reflects a faster fail-over support. </t>
<t>[EDITORIAL NOTE: ALEX FINDS FIRST SENTENCE ABOVE CONFUSING - CONSIDER REWORDING IT]</t>
<t>[EDITORIAL NOTE: ALEX SUGGESTS ADDING A REF TO PROPER SECTION OF SRV DOC, AS WELL AS REF FOR SIP TIMERS]</t>
</section>
<section anchor='failure2' title='Using SRV Results' toc='include'>
<t>Failure may also occur after the request is received by SBE2 from SBE1 due to closure of the transport connection the request came in on at SBE2, before the response can be sent back to SBE1. In this situation, SBE2 uses the domain value present in the 'sent-by' parameter in the top most Via header of the received SIP INVITE, and queries for SRV records at this domain name using the service identifier "_sips" if the Via transport is "TLS", "_sip" otherwise. The sorted list of SRV RRs are obtained and used as described in <xref target="RFC2782"/> to send the response back to SBE1. If the topmost element in the list of server instances of SBE1 fails, the next available one is tried. </t>
<t>[EDITORIAL NOTE: FOR NEXT REV - SHOULD WE ADD CALL FLOW FOR FAILURE SCENARIOS DESCRIBED IN 4.1 AND 4.2?] </t>
<t>[EDITORIAL NOTE: ALEX RECOMMENDS WE CLARIFY WHETHER THE DESCRIBED FUNCTIONALITY HERE IS 'ON TOP' OF STANDARD SIP OR NEW FUNCTIONALITY, AND THAT A REF TO THE PROPER SECTION OF RFC3261 IS CONSIDERED]</t>
</section>
</section>
<section anchor='caching_ttl' title='Caching/TTL' toc='include'>
<section anchor='caching' title='Caching' toc='include'>
<t>SBE SHOULD use caching of DNS results to eliminate unnecessary DNS queries. </t>
</section>
<section anchor='ttl' title='TTL' toc='include'>
<t>SRV RRs have a TTL value based on which the SBE1 caches the entry for that duration, if it supports caching, and any further requests to the same TARGET domain are delivered to the cached server instance. The TTL recommended for SRV is about 1 hr. The TTL for NAPTR is much higher, about 1 day (24hrs) since the NAPTR records do not vary that often as compared to SRV. </t>
</section>
</section>
<section title='Security Considerations'>
<t>This document introduces no new security considerations.</t>
</section>
<section title='IANA Considerations'>
<t>There are no IANA considerations in this document.</t>
</section>
<section title='Acknowledgements'>
<t>Special thanks go to Yiu Lee for his valuable input to this document, as well as John Elwell, Alexander Mayrhofer, and Chris Griffiths for their detailed reviews of this document.</t>
</section>
<!-- appendix -->
</middle>
<!-- END MIDDLE SECTION -->
<!-- BACK SECTION -->
<back>
<references title='Normative References'>
&RFC2119;
&RFC2782;
&RFC2915;
&RFC3261;
&RFC3263;
&RFC3404;
&RFC3667;
<reference anchor='SPEERMINT-Terminology'>
<front>
<title>SPEERMINT Terminology</title>
<author initials='D.' surname='Malas' fullname='Daryl Malas'>
<organization>CableLabs</organization>
</author>
<author initials='D.' surname='Meyer' fullname='David Meyer'>
<organization>Cisco</organization>
</author>
<date month='November' day='7' year='2008' />
</front>
<format type='TXT' target='http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-17.txt' />
</reference>
</references>
<references title='Informative References'>
&RFC2434;
&RFC3761;
</references>
<section title='Document Change Log'>
<t>[RFC Editor: This section is to be removed before publication]</t>
<t>draft-ietf-speermint-srv-naptr-use-05:
<list style='symbols'>
<t>jason: addressed some of John and Alex's questions and issues</t>
<t>jason: moved ref to rfc3761 from normative to informative</t>
<t>jason: highlighted open editorial questions and issues that need to be closed before WGLC</t>
</list>
</t>
<t>draft-ietf-speermint-srv-naptr-use-04:
<list style='symbols'>
<t>jason: addressed feedback from several people received on -02 version of draft</t>
<t>jason: still have about 15 discrete pieces of feedback to include</t>
<t>jason: also highlighted in [BRACKETS] several areas that need minor work</t>
</list>
</t>
<t>draft-ietf-speermint-srv-naptr-use-03:
<list style='symbols'>
<t>jason: converted from MS Word template to XML</t>
</list>
</t>
</section>
<section title='Open Issues'>
<t>Decide what we want to do in Using SRV Results section</t>
<t>Benny Rodrig suggests adding some more description of how this works in the indirect case</t>
<t>Several open issues with John Elwell</t>
<t>Several open issues with Alex Mayrhofer</t>
<t>Several editorial notes to close out</t>
</section>
</back>
<!-- END BACK SECTION -->
</rfc>
<!-- FOR REFERENCE -->
<!-- less than is < -->
<!-- ampersand is & -->
<!-- apostrophe is &apos -->
<!-- quotation is " -->| PAFTECH AB 2003-2026 | 2026-04-24 01:35:46 |