1 / 8

DNS SRV and NAPTR Use for SPEERMINT - Tom Creighton, Gaurav Khandpur Comcast

DNS SRV and NAPTR Use for SPEERMINT - Tom Creighton, Gaurav Khandpur Comcast. SPEERMINT Intermin Meeting Philadelphia Sept 18 2006. Agenda. Scope of draft Key network element to locate peer Peer location procedure (RFC 3263) Feedback and next steps. Scope.

herman-stout
Download Presentation

DNS SRV and NAPTR Use for SPEERMINT - Tom Creighton, Gaurav Khandpur Comcast

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DNS SRV and NAPTR Use for SPEERMINT-Tom Creighton, Gaurav KhandpurComcast SPEERMINT Intermin Meeting Philadelphia Sept 18 2006

  2. Agenda • Scope of draft • Key network element to locate peer • Peer location procedure (RFC 3263) • Feedback and next steps

  3. Scope • Jan 2007 SPEERMINT Deliverable: Submit I-D on the use of DNS SRV and NAPTR records as specified by RFC 3263 (BCP). • What should BCP include ? • Least common implementation specifics/requirements • Must implement Vs must deploy • Use Case scenarios, target audience ? • Recommended configurations for peering network element?

  4. Direct Peering Reference Architecture

  5. Session Peering Proxy • Service location function performed by egress Session Peering Proxy (SPP) of originating service provider(SP1) to locate ingress Session Peering Proxy of peering network or terminating service provider (SP2) and vice versa to setup a SIP session between SP1 and SP2. • SPP1 may use ENUM to determine SIP URI of resource to route call. • SPP determines ip address, port, transport of peering SPP using DNS SRV and NAPTR (implement RFC 3263, RFC 2782). • UDP, TCP, TLS MUST be supported by SPP. TLS is preferred for peering. • SPP should be deployed as multiple instances with different prioritization and weight for capacity based load balancing. • All peering SIP signaling goes through SPP.

  6. Locating peering SPP 1. Target determination: Domain/Host value in the URI is the target to be contacted. URI is SIP or SIPS URI could be obtained from Route Header, if present, or request URI of a SIP message, or ENUM. 2. NAPTR Lookup: Determine the transport by NAPTR lookup of target domain. SIPS over TLS for indirect peering fails due to domain validation failure. 3. SRV Lookup: Determine list of available server instances for peering SPP. 4. SRV response interpreted using RFC 2782 and target entry for SRV RRs looked up by querying DNS, if A records not returned with SRV response. 5. SPP1 connects to SPP2 and sends SIP request.

  7. High Availability • High Availability ensured by detecting failure to connect to SPP. • Type of failures: SIP 503, TCP disconnect, ICMP error in UDP, SIP timeout, transport layer timeout. • If SPP (say SPP1) fails to connect to peer SPP (say SPP2), it tries new SIP request transaction to next available server instance of SPP2 as determined by SRV RRs entry. • If SPP2 fails to reply to SPP1 after receiving SIP request due to SPP1 failure, it uses DNS SRV to find next available SPP1 server instance using domain value from ‘sent-by’ parameter in top most Via header of received SIP request. • Cache/TTL: Recommended TTL for SRV < TTL for NAPTR

  8. Additions/Modifications/Questions • EDNS0 • DNSSEC • Terminology update based on draft-ietf-speermint-terminology. • Use Case scenarios ? • Failure Scenario call flows ? • Configuration recommendations ?

More Related