IETF RFC 5626 PDF

Introduction

There are many environments for SIP [RFC3261] deployments in which the User Agent (UA) can form a connection to a registrar or proxy but in which connections in the reverse direction to the UA are not possible. This can happen for several reasons, but the most likely is a NAT or a firewall in between the SIP UA and the proxy. Many such devices will only allow outgoing connections. This specification allows a SIP User Agent behind such a firewall or NAT to receive inbound traffic associated with registrations or dialogs that it initiates.

Most IP phones and personal computers get their network configurations dynamically via a protocol such as the Dynamic Host Configuration Protocol (DHCP) [RFC2131]. These systems typically do not have a useful name in the Domain Name System (DNS) [RFC1035], and they almost never have a long-term, stable DNS name that is appropriate for use in the subjectAltName of a certificate, as required by [RFC3261]. However, these systems can still act as a Transport Layer Security (TLS) [RFC5246] client and form outbound connections to a proxy or registrar that authenticates with a server certificate. The server can authenticate the UA using a shared secret in a digest challenge (as defined in Section 22 of RFC 3261) over that TLS connection. This specification allows a SIP User Agent who has to initiate the TLS connection to receive inbound traffic associated with registrations or dialogs that it initiates.

The key idea of this specification is that when a UA sends a REGISTER request or a dialog-forming request, the proxy can later use this same network "flow" -- whether this is a bidirectional stream of UDP datagrams, a TCP connection, or an analogous concept in another transport protocol -- to forward any incoming requests that need to go to this UA in the context of the registration or dialog.

For a UA to receive incoming requests, the UA has to connect to a server. Since the server can't connect to the UA, the UA has to make sure that a flow is always active. This requires the UA to detect when a flow fails. Since such detection takes time and leaves a window of opportunity for missed incoming requests, this mechanism allows the UA to register over multiple flows at the same time. This specification also defines two keep-alive schemes. The keep-alive mechanism is used to keep NAT bindings fresh, and to allow the UA to detect when a flow has failed.