[SIPForum-techwg] Proposed Static vs. Registration Overview
john.elwell at siemens.com
Tue Feb 24 07:01:23 EST 2009
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.
> 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.
More information about the techwg