Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network
draft-johansson-sip-dual-stack-03
| Document | Type |
Replaced Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Olle E. Johansson , Gonzalo Salgueiro | ||
| Last updated | 2015-04-09 (Latest revision 2014-10-06) | ||
| Replaced by | draft-ietf-sipcore-dns-dual-stack | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Replaced by draft-ietf-sipcore-dns-dual-stack | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
RFC 3263 defines how a Session Initiation Protocol (SIP) implementation, given a SIP Uniform Resource Identifier (URI), should locate the next hop SIP server using Domain Name System (DNS) procedures. The specification repeatedly states that the implementation should look up IPv4 or IPv6 addresses. This is not a suitable solution and one that can cause severely degraded user experience dual-stack clients, as detailed in the Happy Eyeballs specification. This document specifies amended procedures for dual- stack SIP implementations so that they look up both IPv4 and IPv6 addresses. This way, the SIP implementation can find the preferred network path and protocol with an improved chance of successfully reaching the desired service. This document also clarifies DNS SRV usage for single-stack clients.
Authors
Olle E. Johansson
Gonzalo Salgueiro
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)