A Walk Through a SIP Registration
SIP Registrations can look different on different systems. But when you're reading through the packet capture or logs, reading SIP messaging, it's important to may attention to the direction the packets are flowing. Some people assume they can easily read the SIP message itself to see which device sent it, but it's actually not that easy. You really need to look at the source and destination IP addresses of the packets.
Step 1: First SIP Register Message - from Phone (SIP Endpoint) to SBC
The phone will transmit a SIP "REGISTER" message to the SBC. It sends to the untrusted or customer-facing interface on the SBC. SBCs typically have at least one Untrusted interface, and one Trusted-network interface. (In a Zero-Trust SIP Environment, you may have only a single interface that uses different TLS certificates to identify itself with the rest of the network.)
The From and To headers in the SIP REGISTER have the SIP Address of Record. This is the user Identity.
The Contact header in a SIP REGISTER specifies where messages should be sent in order to reach that user. For eample, in this registration for Corey Lewis, user sip:9197400628@vwave.net, the Contact header indicates that Corey Lewis can be contacted by transmitting a SIP message to 192.168.200.89 port 5060/udp.
Step 2: REGISTER message from SBC to core Registrar
The SBC then sends a SIP REGISTER to the core regisrar. Because the SBC is the SIP path to reach the user, the SBC will modify the Contact header. The new Contact header causes the core SIP registrar to record the location of the user as being on the SBC.
After a successful registration, all of the SIP traffic from the core servers in the network will flow to the user through the SBC. So the user can, in effect, be reached by sending SIP to the SBC.
Step 3: Core Registrar sends a SIP 401 response to the SBC
The SBC sends a 401 response from the SBC. This 401 is a type of failure: it means, in essence, that the core registrar cannot trust the REGISTER. It hasn't determined yet that the SIP REGISTER was transmitted by a device that authentically represents the user.
The 401 response includes a WWW-Authenticate header, which includes enough a nonce. This can be used by a legitimate phone to REGISTER again and prove its identity.
Step 4: SBC sends 401 response to the phone
The SBC sends the 401 SIP response through to the phone. If the phone is behind a NAT device, then the SBC would use the nat-traversal methods.
Step 5: Phone sends a new SIP REGISTER to the SBC including an Authorization header
The Phone computes a response based on the nonce and the SIP authentication password and includes that in the Authorization header. If the phone has the proper password, then it will be able to compute a response that matches the one that the core server has computed.
This MD5 method for SIP authentication is not quantum-safe, so we expect to see other options in the future. There are some vulnerabilities in MD5, but they don't affect this particular use case.
Step 6: The SBC sends the REGISTER with Authorization to the Core Regstrar
The SBC makes only small changes in the REGISTER sent to the Core Registrar, such as modifying the Contact as above. This REGISTER has the Authorization header that was computed by the phone.
Step 7: The SIP Core Registrar checks the registration and returns SIP 200 OK
Once the SIP Core Registrar computes proper response value, it can check it against the value provided by the SIP REGISTER. If they match, then the Registrar has proven that the phone has the same password.
The expiration time provided by the SIP Core Registrar determines when the endpoint device must re-register. In the example shown, the registration must be refreshed within an hour -- or just shy of it, 3,599 seconds.
Step 8: The SBC sends the 200 OK to the phone
The SBC now knows that the user is successfully registered. It may modify the Registration expiration time to force the SIP phone to re-register frequently. This is commonly used as a keepalive mechanism for NAT devices or firewall pinholes.
Example Environment
This particular example was taken from a Cisco BroadWorks system, Oracle Communications Session Border Controller, and Polycom SoundPoint IP SIP phone.
Join us live in ECGT2010 to discuss and ask your questions about SIP calling. This live training with Q&A is perfect to get the key information you need to understand VoIP / UCaaS calling.