Overview
SIP Registration is a crucial process where a SIP Endpoint sends a SIP REGISTER request to a registrar server, such as a central Unified Communication Platform (e.g., FreePBX, CUCM, 3CX). The registrar server accepts this request and stores the information in the location service of the domain it manages. Essentially, the registrar acts as the front end to the location service for a SIP Domain, maintaining the bindings between endpoints and a particular user.
A SIP Registrar server utilizes the contents of the TO: header in the Register request to populate the Address Of Record(AOR).
SIP Registration is used for discovery, if a user wants to make a phone call to another SIP user, then SIP must discover the IP address at which the destination user is reachable. It does this by looking up the binding information in the location cache that contains information about its current registered devices.
Product
Programmable Voice
What You Need To Know
SIP REGISTER
SIP REGISTER is the request of the UAC (User Agent Client. E.g. Bria, Zoiper or a Physical SIP phone) has to send to the Registrar to add, remove or query bindings.
Once the Registrar gets to know the location of an SIP Client, it can deliver calls and other messages to it from other SIP endpoints connected to the same Server.
The Registrar usually requires Authentication and the Client provides it in a following REGISTER message, followed by a confirmation OK that the registration has been saved successfully.
The following header fields are the most common in a REGISTER request:
- Request-URI: The Request-URI names the domain of the location service for which the registration is meant (for example,"sip:twilio.com"). The "userinfo" and "@" components of the SIP URI MUST NOT be present.
- Via: The Via header field indicates the transport used for the transaction and identifies the location where the response is to be sent.
- To: The To header field contains the AOR whose registration is to be created, queried, or modified. The To header field and the Request-URI field typically differ, as the former contains a username. This AOR MUST be a SIP URI or SIPS URI.
- From: The From header field contains the AOR of the person responsible for the registration (most of the time From and To will be the same).
- Call-ID: All registrations from a UAC SHOULD use the same Call-ID header field value for registrations sent to a particular registrar. If the same client were to use different Call-ID values, a registrar could not detect whether a delayed REGISTER request might have arrived out of order.
- CSeq: The CSeq value guarantees proper ordering of REGISTER requests. A UA MUST increment the CSeq value by one for each REGISTER request with the same Call-ID.
- Contact: REGISTER requests MAY contain a Contact header field with zero or more values containing address bindings and provides a SIP URI that can be used to contact that specific instance of the UA.
- User-Agent: It indicates the SIP Client connecting; most devices will indicate here the manufacturer – product name – software version and other information, such as the MAC address
-
Allow: The Allow header field lists the set of methods supported by the User Agent(UA)
generating the message. - Expires: The desired registration duration in seconds.
- Max-Forwards: This header limits the number of hops a request can make on the way to its destination. It consists of an integer that is decremented by one at each hop. If the Max-Forwards value reaches 0 before the request reaches its destination, it is rejected with a 483 (Too Many Hops) error response.
- Proxy-Authorization: The Proxy-Authorization header consists of credentials containing the authentication information of the user agent for the proxy and/or realm of the resource being requested.
-
Allow-Events: If present, includes a list of tokens which indicates the event packages supported by the client (if sent in a request) or server (if sent in a response). In other words, a
node sending an "Allow-Events" header is advertising that it can process SUBSCRIBE requests and generate NOTIFY requests for all the event packages listed in that header.
Example of a SIP REGISTER
1. Endpoint sending the registration attempt to Twilio SIP domain keylor.sip.twilio.com:
REGISTER sip:keylor.sip.twilio.com;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 10.104.128.28:59153;branch=z9hG4bK-524287-1---b2ddeea143ab4aeb;rport
Max-Forwards: 70
Contact: <sip:200@10.104.128.28:59153;rinstance=2ce4f086b822dfd8;transport=UDP>
To: <sip:200@keylor.sip.twilio.com;transport=UDP>
From: <sip:200@keylor.sip.twilio.com;transport=UDP>;tag=440bfb6c
Call-ID: dPwyix59JoGRX7HmG-FWsw..
CSeq: 1 REGISTER
Expires: 60
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
User-Agent: Z 5.5.13 v2.10.18.3
Allow-Events: presence, kpml, talk
Content-Length: 0
2. Twilio challenge the endpoint back to authenticate using the Credential Lists that have been mapped to this SIP Domain:
SIP/2.0 407 Proxy Authentication required
Via: SIP/2.0/UDP 10.104.128.28:59153;received=107.22.192.239;branch=z9hG4bK-524287-1---b2ddeea143ab4aeb;rport=55698
Proxy-Authenticate: Digest realm="sip.twilio.com",qop="auth",nonce="P41c3_2Vg9yAY7CJ6KUoWvP3ZJms6ngfyGI3BHbuJGHGDVpZ",opaque="e97090ac0c23e1f2c733b73582d07277"
To: <sip:200@keylor.sip.twilio.com;transport=UDP>;tag=09993334_c3356d0b_b08eee28-6d60-4085-a735-0babfbdcb806
From: <sip:200@keylor.sip.twilio.com;transport=UDP>;tag=440bfb6c
Call-ID: dPwyix59JoGRX7HmG-FWsw..
CSeq: 1 REGISTER
Server: Twilio
Content-Length: 0
3. Endpoint re-sends the request, this time including the authentication credentials:
REGISTER sip:keylor.sip.twilio.com;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 10.104.128.28:63145;branch=z9hG4bK-524287-1---c1934fbc9af41357;rport
Max-Forwards: 70
Contact: <sip:200@10.104.128.28:63145;rinstance=5d3e4d9d75ee0c5a;transport=UDP>
To: <sip:200@keylor.sip.twilio.com;transport=UDP>
From: <sip:200@keylor.sip.twilio.com;transport=UDP>;tag=4131536b
Call-ID: oy6TQCAxleNJamzNt8WKag..
CSeq: 2 REGISTER
Expires: 600
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Proxy-Authorization: Digest username="200",realm="sip.twilio.com",nonce="irNcE1_KZX96AP9quDKM_xZX5nEaYC3pZMlPzRFKzwGPh0Cn",uri="sip:keylor.sip.twilio.com;transport=UDP",response="842c3b8dcf00cc8d74e4871a86ad8068",cnonce="b9136dcb5b1f7245b833a3928e78454e",nc=00000002,qop=auth,algorithm=MD5,opaque="351d8839e341df73ece83a89f6d89c00"
User-Agent: Z 5.5.13 v2.10.18.3
Allow-Events: presence, kpml, talk
Content-Length: 0
4. Server (Twilio) accepts the registration:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.104.128.28:63145;received=107.22.192.239;branch=z9hG4bK-524287-1---c1934fbc9af41357;rport=3962
Contact: <sip:200@10.104.128.28:63145;rinstance=5d3e4d9d75ee0c5a;transport=UDP>;expires=600
To: <sip:200@keylor.sip.twilio.com;transport=UDP>;tag=08213150_c3356d0b_2051a9c7-c7b2-4dd1-a021-f22a0562262e
From: <sip:200@keylor.sip.twilio.com;transport=UDP>;tag=4131536b
Call-ID: oy6TQCAxleNJamzNt8WKag..
CSeq: 2 REGISTER
Server: Twilio
Content-Length: 0
Common Issues
1. Endpoint loosing registration:
Some customers might report that the endpoint is not receiving calls and the device is getting unregistered. This could happen in company of error "32007 SIP: Too many endpoints/bindings for the Address-of-record (AOR)". This normally happens since the customer reached the limit of 10 bindings (SIP Endpoints) per AOR. If they do not have that amount of distinct devices registered in that domain, then check the amount of active bindings for the same device in the Twilio console under Voice > Manage > SIP domains and select the SIP domain having the issue and then search for the username in the sip domain tab called "Registered SIP Endpoints" and if you see multiple instances for the same device it might be that the device is sending registration requests too often and not honoring what it is asking to last in Expires header, so have the customer to configure the device to sent registration attempt longer when the current binding is about to expire or reduce the amount of time configured in the Expires header.
2. Unable to call endpoint from another account resulting in error 32214:
Unfortunately, Twilio's current framework does not support direct dialing to SIP domains owned by other Twilio customers without additional configuration. The architecture requires that SIP endpoints be registered within the same account hierarchy to facilitate direct dialing. This means that calls to a SIP domain must be initiated from within the account that owns the SIP domain.