RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers

Publisher

RFC Editor / IETF

URL

https://www.rfc-editor.org/rfc/rfc3263.html

Published

2002-06-01

Updated

unknown

Accessed

2026-09-24

HTTP status

200

License

IETF Trust Legal Provisions (BCP 78); IETF Trust permits reproduction of RFCs; corpus stores short excerpts and locators only

Source notes citing this source

• Under RFC 3263, when the target is a numeric IP address or the URI carries an explicit port but no transport parameter, the client uses UDP for a sip URI and TCP for a sips URI. in context
• Under RFC 3263 a client treats a 503 response, a transport failure, or expiry of timer B or timer F as failure and should send a new request to the next element in the resolved list. in context
• RFC 3263 requires that, for a SIPS NAPTR result, both the queried domain and the NAPTR replacement domain be valid according to the site certificate. in context
• Under RFC 3263 a client performs the NAPTR query only when no transport protocol and no port are specified and the target is not a numeric IP address. in context
• RFC 3263 defines the NAPTR service field values SIP+D2U for UDP, SIP+D2T for TCP, SIP+D2S for SCTP and SIPS+D2T for TLS over TCP. in context
• Under RFC 3263, if no NAPTR records are found the client constructs SRV queries for the transport protocols it supports. in context
• Under RFC 3263, if no SRV records are found the client performs an A or AAAA lookup of the domain name and contacts it at the default port for the selected transport. in context
• Under RFC 3263, if neither NAPTR nor SRV records are found the client should use UDP for a sip URI and TCP for a sips URI. in context
• Under RFC 3263, if the target is a domain name but the URI contains a port, the client performs an A or AAAA lookup and does not query SRV. in context
• RFC 3263 has a SIP client resolving a domain-name target try NAPTR records first, then SRV records if no NAPTR records exist, then an A or AAAA lookup if no SRV records exist. in context
• RFC 3263 requires that retransmissions of a SIP request and the ACK for a non-2xx response to INVITE be sent to the same host as the original request. in context
• Under RFC 3263 a client resolving a sips URI must discard any NAPTR services that do not contain SIPS. in context
• RFC 3263 uses the SRV service and protocol labels _sip._udp, _sip._tcp and _sips._tcp to locate SIP servers. in context
• For server location, RFC 3263 defines failure as a 503 response, a transport failure (such as fatal ICMP errors on UDP or TCP connection failures), or the transaction timing out with no response. in context
• On such a failure the client SHOULD send an otherwise identical request with a new Via branch (a new transaction) to the next element in the DNS SRV-ordered list. in context

Cite this source record

APA

WarmTransfer. (2002, June 1). RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers. WarmTransfer. https://warmtransfer.net/knowledge/sources/rfc-3263-locating-sip-servers

BibTeX

@misc{warmtransfer-rfc-3263-locating-sip-servers,
  title  = {RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers},
  author = {{WarmTransfer}},
  year   = {2002},
  url    = {https://warmtransfer.net/knowledge/sources/rfc-3263-locating-sip-servers},
  note   = {RFC Editor / IETF, accessed 2026-09-24}
}