Purpose of registration

User B registers in order to establish their current device and location

Only the user’s location server need know

The location server need not disclose this location to "just anyone", but can apply various polices to decide who can learn of it, i.e., their location server can decide who can ask for B’s location and when they can ask (perhaps even limiting it to where they can ask from).
This has significant privacy implications.

This scales well - as B only has to update their location server, rather than having to inform all possible callers.

To learn about proxies between the user agent and the Registrar - see RFC 3327 (updated by RFC 5626)

Slide Notes

[RFC 3327] D. Willis and B. Höneisen, “Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts”, IETF, Network Working Group, RFC 3327, December 2002, Updated by RFC 5626, http://datatracker.ietf.org/doc/rfc3327/ Links to an external site.

[RFC 5626] C. Jennings, R. Mahy, and F. Audet, ‘Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)’, Internet Request for Comments, vol. RFC 5626 (Proposed Standard), Oct. 2009 [Online]. Available: http://www.rfc-editor.org/rfc/rfc5626.txt Links to an external site.

Transcript

[slide146] Well, now it can send me a notification that B is now available, now I send my INVITE again, and I set up the call. But the cool thing about the registration is the fact that only the user's location register knows where they are. This is a huge privacy advantage. Only my location register knows where I am. I don't have to update things all over the world. I have no global database of this. And, it scales really well. It's just the number of users, and how often they update their registrar that determines how many transactions are going to be done doing updates. Interestingly enough, I had a student who studied a company that operates in nearly 180 some countries around the world. And he looked at what happened if you wanted to give each of the employees in that company a mobile terminal that could provide both voice and data services. It would use SIP for VoIP. It would use VPNs to protect the data. And he basically said, which order should you put the gateways? Right? Should I tunnel my SIP traffic inside my VPN or outside my VPN? Should I put the registrars out publicly visible or should I put them inside the firewall of the company? And how many registrars do I need and how many SIP proxies do I need? And the surprising result of his thesis, Raul Garcia, who was the student, was that the big problem was registrars. Which wasn't what he thought when he first began the problem. He thought the problem would be the IPsec gateways or the secure tunneling or it would be the SIP proxies. But it turned out the problem was the registrars. And the reason is that, of course, here we have the world. What happens? Well, we have these time zones. It is 8:00 in Stockholm, suddenly large people are going to school or whatever. and re-registering their new IP address. What happens starting at 3 or 4 or 5 o'clock? People are moving to another place and, yes, they're all re-registering new addresses. So you have this very, very sharp burst of traffic to the registrars. But what happens to the pattern of calls? The calls are distributed all over the time Once I've registered my location with the registrar, do I need another update of the registrar? No. Not until I move to some new address. Therefore, I can get away with a much smaller number of the SIP proxies, but I have a big bottleneck if I don't have enough registrar capacity. But what can you think about doing? Well, when it's 8 o'clock in this time zone what time is it in this time zone? It is an hour before. And over here, 5 time zones away, yes, it's 5 hours before, or 6 hours before, I can put my registrars elsewhere. And because the timing of that SIP signaling is not so critical, the fact that I physically locate the registrars distributed around the world, smooths out the load on the registrars, and effectively ups my capacity. And so a set of students actually demonstrated this inside one of the telecom systems where they actually ran the 3GPP equivalent of the registrar, first between Kista and Älvsjö and then between Kista and Montreal. And they showed that despite the fact that the traffic had to go all the way across the Atlantic and back it could met all the timing requirements. And suddenly they no longer had to dimension the system in Stockholm to meet the spike in demand that would occur in Stockholm because there was a 6 hour time shift between the one in Montreal. It's very, very cool when you can exploit these differences.