[SIPForum-techwg] SIPConnect 1.1: REGISTER supportMUSTat SIP-PBX
Francois Audet
audet at nortel.com
Mon Feb 16 12:22:34 EST 2009
Well, sure, but with this logic, the examples are always going to
be counter-intuitive.
> -----Original Message-----
> From: Elwell, John [mailto:john.elwell at siemens.com]
> Sent: Monday, February 16, 2009 06:39
> To: Michael Procter; Audet, Francois (SC100:3055)
> Cc: Bernard Aboba; techwg at sipforum.org; David Hancock
> Subject: RE: [SIPForum-techwg] SIPConnect 1.1: REGISTER
> supportMUSTat SIP-PBX
>
>
>
> > -----Original Message-----
> > From: techwg-bounces at sipforum.org
> > [mailto:techwg-bounces at sipforum.org] On Behalf Of Michael Procter
> > Sent: 16 February 2009 08:31
> > To: Francois Audet
> > Cc: Bernard Aboba; techwg at sipforum.org; David Hancock
> > Subject: Re: [SIPForum-techwg] SIPConnect 1.1: REGISTER
> supportMUSTat
> > SIP-PBX
> >
> > Francois Audet wrote:
> > > That is a good starting point.
> > > Do we think that we need a different Contact user name and
> > AOR user name?
> >
> > Yes.
> >
> > > You've got respectively pbx-99 and joe-butcher in there. I would
> > > expect that normally, they would be the same.
> >
> > For some implementations today, maybe. But there are good
> reasons to
> > allow them to differ. Unless there is a good reason to
> require them to
> > be the same, I think it would be clearest to show them as being
> > different.
> [JRE] I agree with Michael. Showing them as being the same in
> examples has the dangerous habit of making people think they
> should always be the same, resulting in implementations that
> can't cope with them being different.
>
> John
>
>
>
> >
> > Michael
> >
> > > For example,
> > > Contact: sip:joe-butcher99 at 10.1.1.1
> > > To: sip:joe-butcher99 at sp.com
> > > Not a big deal, but my expectation would be that most
> PBXs would use
> > > the same name and not provision those separately.
> > >
> > >
> > --------------------------------------------------------------
> > ----------
> > > *From:* David Hancock [mailto:D.Hancock at CableLabs.com]
> > > *Sent:* Friday, February 13, 2009 11:39
> > > *To:* David Hancock; Audet, Francois (SC100:3055);
> > Bernard Aboba;
> > > fluffy at cisco.com
> > > *Cc:* techwg at sipforum.org
> > > *Subject:* RE: [SIPForum-techwg] SIPConnect 1.1: REGISTER
> > > supportMUSTat SIP-PBX
> > >
> > > I updated the registration procedure to address
> > comments received.
> > > Primary changes were...
> > >
> > > - changed the "main" identity from E.164-based to
> > email-style SIP
> > > URI, to show the more general case.
> > >
> > > - added "user=phone" to the E.164 URIs
> > >
> > > - added a user-name to the SIP-PBX contact URI
> > >
> > > - removed E.164 separators.
> > >
> > > I used pseudo track-changes to highlight most of the changes.
> > >
> > > Please let me know if this doesn't align with your
> understanding
> > > of pbx-registration.
> > >
> > > Thanks
> > >
> > > David
> > >
> > >
> > --------------------------------------------------------------
> > ----------
> > >
> > > *From:* techwg-bounces at sipforum.org
> > > [mailto:techwg-bounces at sipforum.org] *On Behalf Of
> > *David Hancock
> > > *Sent:* Thursday, February 12, 2009 2:04 PM
> > > *To:* Francois Audet; Bernard Aboba; fluffy at cisco.com
> > > *Cc:* techwg at sipforum.org
> > > *Subject:* Re: [SIPForum-techwg] SIPConnect 1.1: REGISTER
> > > supportMUSTat SIP-PBX
> > >
> > > The following is a summary of the example _PBX-_registration
> > > use-cases that we discussed at length on the reflector last
> > > Nov/Dec. It's probably good that we review this again,
> > in case we
> > > missed something important, and to make sure we're still in
> > > agreement over how this works. I also support the
> > suggestion that
> > > we add some informative examples that make it clear what the
> > > normative requirements really mean.
> > >
> > > Consider the case where Service Provider with domain
> "sp.com" is
> > > providing connectivity to a SIP-PBX operating in the
> > registration
> > > mode. The SIP-PBX signaling address is 10.1.1.1. The
> > enterprise is
> > > allocated the following 100 E.164 numbers:
> > >
> > > 1-303-661-1200 thru 1-303-661-1299
> > >
> > > The enterprise Public Identities assigned to the
> > SIP-PBX can have
> > > the a) the domain of the service provider, b) a
> subdomain of the
> > > service provider's domain, or c) the domain of the enterprise,
> > > like this...
> > >
> > > a) SIP:[user]@sp.com
> > >
> > > b) SIP:[user]@pbx1.sp.com
> > >
> > > c) SIP:[user]@enterprise.com
> > >
> > > Each of the above cases operates in more-or-less the same way.
> > > I'll describe case a), where Public Identities contain service
> > > provider's domain. In this case, the Public Identities
> > would look
> > > like this:
> > >
> > > SIP:+13036611200 at sp.com;user=phone
> > >
> > > SIP:+13036611201 at sp.com;user=phone
> > >
> > > ...
> > >
> > > SIP:+13036611299 at sp.com;user=phone
> > >
> > > Using the definitions in SIPconnect 1.1, we'll designate
> > > SIP:+1-303-661-1200_joe-butcher_ at sp.com as the "main"
> enterprise
> > > Public Identity, and the other 99 _100 "E.164" _SIP URIs as
> > > "alternate" enterprise Public Identities. _(Note, as an
> > > alternative, the Service Provider could designate one
> > of the E.164
> > > SIP URIs as the "main" public identity.) _The Service Provider
> > > network is configured with a Table-1 that
> > maps/associates all the
> > > alternate identities to the main identity.
> > >
> > > When the SIP-PBX boots up, it sends a single REGISTER
> > request that
> > > looks like this...
> > >
> > > REGISTER SIP:sp.com
> > >
> > > To: sip:_joe-butcher_ at sp.com
> > >
> > > From: sip:+13036611200 at sp.com
> > >
> > > Contact: sip:_pbx-99 at _10.1.1.1
> > >
> > > Supported: path
> > >
> > > This creates a binding in the Service Provider network between
> > > sip:_joe-butcher_ at sp.com and the contact address of
> the SIP-PBX,
> > > sip:_pbx-99 at _10.1.1.1. As a result of Table-1 above, the 100
> > > alternate identities are bound to this same contact address.
> > >
> > > If a user somewhere in the global network calls one of these
> > > enterprise users, the resulting dialog-initiating INVITE looks
> > > like this...
> > >
> > > ... when it is received at the Service Provider
> network ingress
> > > point from some other network,
> > >
> > > INVITE sip:+13036611255 at sp.com_;user=phone_
> > >
> > > To: sip: +13036611255 at sp.com_;user=phone_
> > >
> > > From: sip:something at somewhere
> > >
> > > Contact: sip:foo at bar
> > >
> > > ... and when it is sent by the SP network toward the
> > SIP-PBX on the
> > > SIPconnect interface
> > >
> > > INVITE sip:+13036611255 at sp.com_;user=phone_
> > >
> > > To: sip: +13036611255 at sp.com_;user=phone_
> > >
> > > From: sip:something at somewhere
> > >
> > > Route: sip:_pbx-99 at _10.1.1.1
> > >
> > > Contact: sip:foo at bar
> > >
> > > How the SP network does this is out-of-scope of
> SIPconnect 1.1,
> > > but the way we support this in PacketCable is to treat
> > the SIP-PBX
> > > registration like a real (not pseudo) registration that
> > implicitly
> > > registers the alternate identities. Therefore, in the
> > PacketCable
> > > case, the SP network routes requests to the SIP-PBX
> > using the same
> > > procedure as directly hosted users, with the
> exception that the
> > > Request-URI is not overwritten with the registered contact
> > > address, but is left intact_ (this behavior is based on
> > > provisioned data associated with the SIP-PBX in the SP
> > network)_.
> > >
> > > The Route header in the request is optional. If there
> > are multiple
> > > SIP proxies between the SP home proxy and the PBX, then the SP
> > > home proxy will discover this "path" using the Path
> > extension when
> > > the SIP-PBX registers. In this case, when the request
> leaves the
> > > SP network on the SIPconnect interface, the request
> > will contain a
> > > Route header identifying the registered contact of the
> > SIP-PBX, as
> > > shown in the above example.
> > >
> > > That's how we support this in PacketCable; other SP
> networks are
> > > free to do something different, as long as the messages on the
> > > SIPconnect interface meet the SIPconnect 1.1 requirements.
> > >
> > > During our initial discussion on this, it was pointed out that
> > > this case (where enterprise public identities use domain of SP
> > > network) creates some ambiguity over who is responsible
> > for the SP
> > > domain name. When the SIP-PBX is routing a request
> addressed to
> > > the SP domain, it can't simply forward the request to the SP
> > > network, but must look at the user part to see if it
> > (the SIP-PBX
> > > itself) is responsible for the target user. The SIP-PBX should
> > > have sufficient information to do this; i.e., it needs
> > to have its
> > > own _provisioned _Table that identifies all the Public
> > Identities
> > > within the SP domain that it, the SIP-PBX, owns.
> > >
> > > I hope this clears up (and doesn't add to) questions around
> > > SIP-PBX registration.
> > >
> > > Thanks
> > >
> > > David
> > >
> > >
> > --------------------------------------------------------------
> > ----------
> > >
> > > *From:* techwg-bounces at sipforum.org
> > > [mailto:techwg-bounces at sipforum.org] *On Behalf Of
> > *Francois Audet
> > > *Sent:* Thursday, February 12, 2009 9:59 AM
> > > *To:* Bernard Aboba; fluffy at cisco.com
> > > *Cc:* techwg at sipforum.org
> > > *Subject:* Re: [SIPForum-techwg] SIPConnect 1.1: REGISTER
> > > supportMUSTat SIP-PBX
> > >
> > > You are correct: it is out-of-band.
> > >
> > > I think we should spell it out. You are right, people read the
> > > spec and "read" into it some sort of implied mechanism.
> > >
> > >
> > --------------------------------------------------------------
> > ----------
> > >
> > > *From:* techwg-bounces at sipforum.org
> > > [mailto:techwg-bounces at sipforum.org] *On Behalf Of
> > *Bernard Aboba
> > > *Sent:* Wednesday, February 11, 2009 23:33
> > > *To:* fluffy at cisco.com
> > > *Cc:* techwg at sipforum.org
> > > *Subject:* Re: [SIPForum-techwg] SIPConnect 1.1: REGISTER
> > > support MUSTat SIP-PBX
> > >
> > > > Bernard, I'm trying to get up to speed. Even
> for a single
> > > block of
> > > > numbers, are you talking about a scheme where
> the register
> > > from the
> > > > PBX tells the SP what block of numbers go to that PBX. I
> > > thought that
> > > > was what Richard was talking about but it does
> > not seem to be
> > > what
> > > > Francois is talking about. I'm confused - can
> you explain?
> > >
> > > My understanding is that the block of numbers is
> > set up out of
> > > band, not
> > > communicated in the register. But in previous
> versions, the
> > > spec seemed to
> > > have implied in-band communication. However, I never quite
> > > understood
> > > how that was supposed to work (and what cases it
> > could cover).
> > >
> > >
> > --------------------------------------------------------------
> > ----------
> > >
> > > _______________________________________________
> > > techwg mailing list
> > > Send mail to: techwg at sipforum.org
> > > Unsubscribe or edit options at:
> > http://sipforum.org/mailman/listinfo/techwg
> > >
> >
> > _______________________________________________
> > techwg mailing list
> > Send mail to: techwg at sipforum.org
> > Unsubscribe or edit options at:
> > http://sipforum.org/mailman/listinfo/techwg
> >
>
More information about the techwg
mailing list