Section 10.3 of RFC 3261, talks about Registration Process flow. I have tried to summaries it into a flowchart.. Please comment on it..
Saturday, March 6, 2010
Monday, March 1, 2010
Registration Overview
Overview:
RFC 3261 talks about registration in chapter 10. Registration is one way to populate the location service database. Registration allows SIP to be mobile. Under registration, a person can register more than 1 phone. A person is identified by a unique address called as Address Of Record (AOR). His phones are identified as contacts. An AOR can have multiple contacts binded to it. Lets see what RFC 3261 has to tell about Registration point by point.
1. Registration will use AOR to search for contact and add them.
2. Register can happen through proxy server to a registrar server. Server which handles the REGISTER message and acts to update or query the location service is said to be Registrar.
3. REGISTER request can add, remove, update, query contacts.
4. REGISTER request does not establish a dialog.
5. Record-route header has no meaning with REGISTER message. UAC must ignore this header.
6. A REGISTER message should have the following:
a. Request-URI: Domain for which the registration is done. Difference between the regular SIP Request-URI and REGISTER request-URI is the absence of “userinfo@”.
b. TO: Binding AOR. This AOR is the one for which we query, add, delete, update contact.
c. FROM: AOR of person initiating the contact. SIP supports third party registration.
d. Call-ID: Random unique identified similar to Call-ID used in other methods with a difference. Call-ID should be same between a client to a server all the time. If its different, then registrar would not be able to detect a delayed REGISTER message which arrived out of order.
e. CSEQ: UA must increment CSEQ for subsequent REGISTER messages.
f. Contact (Optional): If no contact header is present its query else, action will be decided on various factor between add, query, refresh etc.
7. UAC must not send any new registration until they have received final response from the registrar for previous one or timed out. Retransmission may happen.
8. Special contact header parameters: expire – specifies how long the binding is valid. If it is not present Expire header will be used.
9. 2xx response from registrar will have all bindings listed in contact header.
10. If neither the Expire header or expire parameter of contact header is present then server is allowed to chose the value.
11. Priority of contact can be set by using the ‘q’ parameter of a contact header.
12. Value is ‘q’ should be less than 1.
13. Higher the ‘q’ value, higher the priority.
14. Binding removal can be done by specifying expire=0.
15. If Contact header field value is *, expire value can only be 0. This means, all bindings to AOR are removed.
16. A successful response for REGISTER message will have all binded contacts listed in the Contact header along with its parameters. In case the REGISTER message does not have Contact header it is a query.
17. Discovery of Registrar can be done in three ways.
a. By configuration
b. By using AOR (only host and domain part of AOR is used)
c. Using multicast (224.0.1.75 sip.mcast.net)
18. Too small expiry time results in 423 – Interval Too Brief response.
19. A registrar must not generate a 6xx response.
20. Accepts only REGISTER message
21. Registrar should know the set of domain for which it maintains binding.
22. REGISTER message should be processed completely and independently.
RFC 3261 talks about registration in chapter 10. Registration is one way to populate the location service database. Registration allows SIP to be mobile. Under registration, a person can register more than 1 phone. A person is identified by a unique address called as Address Of Record (AOR). His phones are identified as contacts. An AOR can have multiple contacts binded to it. Lets see what RFC 3261 has to tell about Registration point by point.
1. Registration will use AOR to search for contact and add them.
2. Register can happen through proxy server to a registrar server. Server which handles the REGISTER message and acts to update or query the location service is said to be Registrar.
3. REGISTER request can add, remove, update, query contacts.
4. REGISTER request does not establish a dialog.
5. Record-route header has no meaning with REGISTER message. UAC must ignore this header.
6. A REGISTER message should have the following:
a. Request-URI: Domain for which the registration is done. Difference between the regular SIP Request-URI and REGISTER request-URI is the absence of “userinfo@”.
b. TO: Binding AOR. This AOR is the one for which we query, add, delete, update contact.
c. FROM: AOR of person initiating the contact. SIP supports third party registration.
d. Call-ID: Random unique identified similar to Call-ID used in other methods with a difference. Call-ID should be same between a client to a server all the time. If its different, then registrar would not be able to detect a delayed REGISTER message which arrived out of order.
e. CSEQ: UA must increment CSEQ for subsequent REGISTER messages.
f. Contact (Optional): If no contact header is present its query else, action will be decided on various factor between add, query, refresh etc.
7. UAC must not send any new registration until they have received final response from the registrar for previous one or timed out. Retransmission may happen.
8. Special contact header parameters: expire – specifies how long the binding is valid. If it is not present Expire header will be used.
9. 2xx response from registrar will have all bindings listed in contact header.
10. If neither the Expire header or expire parameter of contact header is present then server is allowed to chose the value.
11. Priority of contact can be set by using the ‘q’ parameter of a contact header.
12. Value is ‘q’ should be less than 1.
13. Higher the ‘q’ value, higher the priority.
14. Binding removal can be done by specifying expire=0.
15. If Contact header field value is *, expire value can only be 0. This means, all bindings to AOR are removed.
16. A successful response for REGISTER message will have all binded contacts listed in the Contact header along with its parameters. In case the REGISTER message does not have Contact header it is a query.
17. Discovery of Registrar can be done in three ways.
a. By configuration
b. By using AOR (only host and domain part of AOR is used)
c. Using multicast (224.0.1.75 sip.mcast.net)
18. Too small expiry time results in 423 – Interval Too Brief response.
19. A registrar must not generate a 6xx response.
20. Accepts only REGISTER message
21. Registrar should know the set of domain for which it maintains binding.
22. REGISTER message should be processed completely and independently.
Subscribe to:
Posts (Atom)