[SIPForum-techwg] Quetion about how registration mode works
john.elwell at siemens.com
Tue Feb 10 15:52:00 EST 2009
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.:
- incoming call / registration mode
- outgoing call / registration mode
- incoming call / static mode
- outgoing call / static mode
- subscribe and notify for MWI
> -----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 22.214.171.124.
> > 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 126.96.36.199. 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 188.8.131.52.
> 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
> FHZ does pseudo-registration by establishing connection with
> 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 184.108.40.206.
> 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 220.127.116.11, 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:
More information about the techwg