[SIPForum-techwg] Quetion about how registration mode works

[Richard Shockey]

Cullen ..etal one of the confusions here is specifically about the term
registration. François is totally correct. The difference in views is in
part about provisioning. Alan has made this point as well in earlier
messages.

How does a SSP acquire which TN's or TN blocks are authoritative for a given
PBX in order to provision service. This is TN specific. If you are a SSP
CLEC/Cable targeting relatively smaller markets, using the
"pseudo-registration" process via REGISTER works and works well. Field
tested deployed end of story. If you are a Large Enterprise it does not work
and in fact has serious problems associated with it that have been listed in
depth.

Typically SSP's serving smaller markets are using leased lines or are part
of a Coaxial-Cable plant and have essentially Layer 1 security across their
wires. Hense DIGEST vs TLS also makes sense. 

Let's not get into a debate about TLS here we have made that compromise in
1.0 to the satisfaction of all parties.

Telco land always gets tripped up on OSS issues ( because they are not sexy
like architecture) and this is a classic example of where the ball got
dropped. The ultimate solution is a simple clean HTTP-PUSH or TFTP like data
provisioning protocol that would send the SSP data about TN's, users and
capabilities from the PBX in order to properly provision but it does not
exist. Am I wrong here?

However it is manifestly self evident that the market opportunity is huge
for both market segments so the search is for a compromise that accepts the
reality of both SMB and Enterprise requirements while not burdening smaller
SSP's with Manual provisioning that cannot economically justified.

This is strictly business at this point ..not theory.

>  -----Original Message-----
>  From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org]
>  On Behalf Of Francois Audet
>  Sent: Monday, February 09, 2009 11:16 PM
>  To: Cullen JENNINGS; techwg at sipforum.org
>  Subject: Re: [SIPForum-techwg] Quetion about how registration mode
>  works
>  
>  No, it's not as you describe. This means we really need to clarify
>  this
>  stuff. If we don't all have the same understanding in this group, I
>  can just
>  imagine in the wild.
>  
>  See below for explanation.
>  
>  
>  On Feb09 2009 19:32 , "Cullen JENNINGS" <fluffy at cisco.com> wrote:
>  
>  >
>  > The registration mode is somewhat under specified so I'm pretty sure
>  I
>  > don't understand some parts of it. Or perhaps I jsut read the
>  document
>  > too quickly without enough coffee but either way, I'm sure I don't
>  > fully understand yet.
>  >
>  > Let me explain what I am getting out of the spec and tell me if I am
>  > interpreting this correctly. Let's use an example where the service
>  > provider, say ATT, is providing service of Fluffy' Hair Salon
>  > (fhs.net). FHS has a main number (main at fhs.net) and some users like
>  > cullen at fhs.net
>  >   and has DSL line with dynamic ip address connected to it's PBX and
>  > wants to use registration mode with TLS for this example. And I
>  guess
>  > there the SP has provided a password of "secret" to the FHS. So
>  > roughly I understand that the sequence goes like this ...
>  >
>  > The FHS enterprise PBX boots and does DHCP to find it's IP is
>  1.2.3.4.
>  > It is configured to use att.com as the SP so it does usual SRV DNS
>  to
>  > resolve att.com and forms a TLS connection to proxy1.att.com. The
>  ATT
>  > sides presents a certificate that says sip:att.com in the SAN and
>  the
>  > PBX does not have a cert. The PBX sends a register for main at fhs.net
>  to
>  > att.com with a contact of it's current public dynamic IP which lets
>  > says happens to be 1.2.3.4. This gets digest challenged with
>  "secret"
>  > and registration succeeded. The SP has configuration to know that
>  > cullen at fhs.net
>  >   and alice at fhs.net also goes to this same PBX as main at fhs.net so
>  > anytime the SP gets a SIP invite with a request uri of
>  cullen at fhs.net,
>  > it sends it down the TLS connection to 1.2.3.4.
>  
>  There is no concept of a "main number". Att.com has assigned a PBX
>  identity
>  of, say, fhs.att.net (or fhs.net if Fluffy has it's own domain) to
>  FHS. This
>  is just an arbitrary identifier chosen by att.com. It could also be
>  fhs at att.net: it doesn't matter: it's a unique character string
>  assigned by
>  att.net.
>  
>  FHZ does pseudo-registration by establishing connection with
>  proxy1.att.com
>  and sends a REGISTER with From/To set to fhs.att.net with ATT. NOTE: I
>  really think we should call this everywhere in the document
>  "pseudo-registration" to avoid confusion with normal SIP registration
>  procedures. The Contact will be 1.2.3.4.
>  
>  Att.com has manually configured the assigned "phone numbers" for FHS.
>  I.e.,
>  cullen at fhs.net, etc. We should limit the identities to Phone numbers
>  only,
>  not arbitrary URIs. So cullen at fhs.net would not be valid. It would be
>  things
>  like sip:=+1-403-555-1212 at att.net;user=phone. In a larger enterprise,
>  att.com would probably use prefixes (like, all +1-403-555-XXXX) and
>  blocks
>  of assigned phone numbers.
>  
>  Both Alice and Cullen will use the same TLS (or UDP or TCP) connection
>  for
>  making and receiving calls.
>  
>  > Later when a call comes to ATT that is for cullen at fhs.com, it
>  forwards
>  > the INVITE to the PBX with a RURI of 1.2.3.4, and a route header of
>  > cullen at fhs.com
>  > . Did I get this right?  Could you show me a bit of example of what
>  > the RURI, To, From, and Route headers look like in the Register and
>  > both inbound and outbound INVTEs?
>  
>  No: this is wrong.
>  
>  The Request-URI would be set to sip:+1-403-555-1212;user=phone (and so
>  will
>  the To). From would be the Calling Line ID of the orginator (or SIP
>  URI).
>  
>  This is why I'm insisting we call it pseudo-Registration. It is not a
>  normal
>  registration where we expect the Request-URI to be replaced by the
>  Contact.
>  
>  > Now if there was a SP voicemail, the enterprise PBX, would also send
>  a
>  > register for each users, so a register for cullen at fhs.net, and
>  another
>  > for alice at fhs.net and then would send a subscribe for MWI for each
>  > user. So the subscribe for culler's MWI would have a RURI of
>  cullen at fhs.net
>  >   and the contact would be, uh, what would it be? And the NOTIFY
>  would
>  > be send to ?
>  
>  No, there would not be individual registration for voicemail. The SP
>  voicemail would be based on phone number legacy PSTN stuff (i.e., if
>  no
>  response, send to voicemail).
>  
>  NOTIFY for voicemail would be linked to the PBX identity (the one in
>  the
>  registration), which effectively represent the whole range of phone
>  number
>  block associated to that PBX.
>  
>  > When Cullen makes a call, the INVITE from the PBX uses the
>  cullen at fhs
>  > as the user for the credentials for the digest but with the same
>  > secret as main? or is it when cullen makes a call, it uses the
>  > username and credentials for main to digest auth the INVITE to the
>  > ATT. Say Cullen & Alice are making a call at roughly the same time -
>  > say the two INVITEs are overlapping - I'm a bit unsure what the
>  nonces
>  > look like.
>  
>  No, it would be the credential of the PBX.
>  
>  > If FHS wanted to switch from ATT to Comcast, it would go set up an
>  > account with Comcast and configure a new secret for the digest and
>  > Comcast would setup the cullen at fhs.net was associated with
>  > main at fhs.net and FHS would change the config to point at comcast
>  > instead of ATT and rough the same thing would happen.
>  
>  It would switch it's fhs.att.net account with an fhs.comcast.net
>  account.
>  
>  > Do I have this about right - can you correct me where I got it
>  wrong?
>  
>  
>  _______________________________________________
>  techwg mailing list
>  Send mail to: techwg at sipforum.org
>  Unsubscribe or edit options at:
>  http://sipforum.org/mailman/listinfo/techwg