[SIPForum-techwg] Proposed Static vs. Registration Overview

[Elwell, John]

David,

On the whole I like this description. Some specific comments below. 

> -----Original Message-----
> From: techwg-bounces at sipforum.org 
> [mailto:techwg-bounces at sipforum.org] On Behalf Of David Hancock
> Sent: 24 February 2009 06:19
> To: techwg at sipforum.org
> Subject: [SIPForum-techwg] Proposed Static vs. Registration Overview
> 
> Since there has been so much reflector discussion around what 
> it means for a SIP-PBX to register, I thought it would be 
> good to document the outcome of the discussion within the 
> SIPconnect 1.1 spec itself, for the benefit of future readers 
> of the document. Below is some proposed text that (hopefully) 
> does that. Please let me know if you like the general 
> approach (or not), and if you have any suggestions for 
> improvement (e.g., it could probably use some more words 
> describing the benefits and place for the Static mode). 
> 
>  
> 
> I tried to describe the two modes in these terms - the Static 
> mode aligns with normal SIP procedures. It's the obvious way 
> one would expect this to work. The Registration mode is a 
> somewhat less obvious solution, but it has some compelling 
> advantages. And it still aligns with RFC 3261 if you can get 
> into the right frame of mind.
> 
>  
> 
> I think this text could become part of the introduction of 
> the two modes of operation, possibly replacing the existing 
> intro text under section-7. In addition to this overview 
> text, I assume we still want a detailed example flow 
> illustrating how registration works.
> 
> Thanks
> 
> David
> 
> This document describes two modes of operation for the 
> SIP-PBX; the Static mode and the Registration mode. These 
> modes differ primarily in the way the SP network discovers 
> the SIP signaling address of the SIP-PBX.
> 
> In the Static mode, the SP network views the SIP-PBX as a 
> peer SIP-based network that is responsible for the enterprise 
> users it serves. In this mode the SP network is either 
> configured with the SIP-PBX signaling address, or it 
> discovers the address using DNS. The SP network procedures 
> for routing out-of-dialog requests to the SIP-PBX align 
> closely with the SIP routing procedures defined in RFC 3261 
> (and RFC 3263 if DNS is used). 
[JRE] What about in-dialog requests? They need to be routed towards a
contact or route URI supplied by the SIP-PBX during dialog
establishment. But you can still do that by DNS look-up.

> 
> In the Registration mode, the SIP-PBX conveys its SIP 
> signaling address to the SP network using the SIP 
> registration procedure. In effect, the SIP-PBX registers with 
> the SP network, just like a directly hosted SIP endpoint 
> would register. The primary advantage of the Registration 
> mode is that it enables the SIP-PBX to be easily deployed in 
> a "plug-and-play" fashion; i.e., with only a minimum of 
> configuration data the SIP-PBX can initiate the registration 
> procedure to automatically establish connectivity with the SP 
> network. Additional value-adds of the Registration mode 
> include the following:
> 
> -          It enables the SP network to discover the 
> signaling address of the SIP-PBX that is assigned a dynamic 
> IP address,
> 
> -          It provides a mechanism for a SIP-PBX located 
> behind a NAT to automatically establish connectivity with the 
> SP network,
[JRE] Yes, but we should caution that it doesn't solve NAT traversal for
media. Other measures need to be taken for that.

> 
> -          It provides a mechanism for a failed SIP-PBX to 
> automatically inform the network when it is back online,
[JRE] Not just a failed SIP-PBX, but also a working SIP-PBX that has
lost connection with the SP-SSE. I am not sure we have all the
procedures for this sufficiently tied down yet.

> 
> -          It enables the Service Provider to tap into 
> streamlined and scalable subscriber provisioning and 
> management processes (e.g., an SP network that is designed to 
> support the heavy registration traffic generated by millions 
> of users is well suited to support registration traffic 
> generated by large numbers of SIP-PBXs operating in the 
> Registration mode). 
> 
> Although SIPconnect 1.1 doesn't define the internal 
> architecture of a SIP-PBX, one could assume that it is 
> comprised of the same architectural components typical of any 
> SIP-based network; SIP Proxies for message routing, a SIP 
> Registrar to maintain AOR-to-location bindings for the 
> enterprise endpoints, and Application and Media Servers to 
> provide services to the enterprise users. Given that RFC 3261 
> doesn't explicitly define procedures for registering a 
> complex entity like a SIP-PBX, some definition of how the 
> standard SIP registration procedures apply to a SIP-PBX is required.
> 
> First, SIPconnect 1.1 assumes that a SIP-PBX operating in the 
> Registration mode implements a SIP User Agent that registers 
> the SIP signaling address of the SIP-PBX (for example, if the 
> SIP-PBX interconnection point to the SIPconnect interface is 
> a SIP proxy, then this SIP UA could be collocated with that 
> proxy). This SIP UA is assigned the single "main" Public 
> Identity of the SIP-PBX, and it performs the normal 
> registration procedure as defined in RFC 3261 to create a 
> binding in the SP network between the "main" Public Identity 
> and the SIP signaling address of the SIP-PBX. 
> 
> The SP network is configured with a table that maps all the 
> other Public Identities assigned to this SIP-PBX (referred to 
> as the "alternate" enterprise Public Identities) to the main 
> enterprise Public Identity.  Therefore, when the SIP-PBX 
> registers, the SP network creates a binding between each of 
> these alternate Public Identities and the SIP-PBX contact 
> address registered by the main Public Identity.
> 
> The SP network uses the loose-routing procedure defined in 
> RFC 3261 to route out-of-dialog SIP requests to the SIP-PBX. 
> This means that when the SP network receives an out-of-dialog 
> request with a Request-URI containing the main or one of the 
> alternate enterprise Public Identities, it does not replace 
> the Request-URI with the registered contact address of the 
> SIP-PBX, but instead adds the registered contact URI to the 
> Route header. 
[JRE] We need to consider in-dialog requests too. These will be directed
at contact or route URIs supplied by the SIP-PBX at dialog
establishment. As such they are different from out-of-dialog requests,
but they still need to reach the SIP-PBX and may need to use the
connection that has been established for registration purposes.

John