[SIPForum-techwg] Quetion about how registration mode works

[Elwell, John]

This does point to the fact that the spec is not clear. I think we
should at least consider giving some example message sequences, e.g.:
- registration
- incoming call / registration mode
- outgoing call / registration mode
- incoming call / static mode
- outgoing call / static mode
- subscribe and notify for MWI

John
 

> -----Original Message-----
> From: techwg-bounces at sipforum.org 
> [mailto:techwg-bounces at sipforum.org] On Behalf Of Francois Audet
> Sent: 10 February 2009 04:16
> 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
>