Subject: Re: [dispatch] To-URI in domain-registration

From: "Middleton, David (NSN - US/Boca Raton)" <[email-masked]>
Date: Wed, 11 Nov 2009 15:13:07 -0600

Paul,

Sorry for the delay in responding.

I think you are on target as far as describing many (perhaps most) SP / PBX interconnect arrangements.  However, the functionality of having the SP route calls per user is a real-world scenario which proves there is merit for having the capability.

Also see inline.

David

-----Original Message-----
From: ext Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, October 30, 2009 7:37 PM
To: Middleton, David (NSN - US/Boca Raton)
Cc: [email-masked]
Subject: Re: [dispatch] To-URI in domain-registration

David,

IIUC, you are proposing a case such as:

- a customer of sp.net has domain cust.sp.net
- the customer has two PBX systems, east and west.
- you propose that they register, respectively
   To: [email-masked], and
   To: [email-masked].
- then numbers assigned to the customer are routed
   something like:
   1-212-555-88xx -> contact from [email-masked]
   1-408-555-88xx -> contact from [email-masked]
- also, routing for names be something like:
   [email-masked]   -> contact from [email-masked]
   [email-masked] -> "
   [email-masked]   -> contact from [email-masked]
   [email-masked] -> "
   others...

Is that right?
<DM> Yes

You then can't describe that as setting up routing paths for 
cust.sp.net. You are instead describing some entirely different routing 
algorithm based on the user part.
<DM>  Yes, it requires a local policy to determine the location of the users.

Subdomains east.cust.sp.net and west.cust.sp.net solve this problem in 
large part - at least for the numbers.

You clearly don't find that acceptable for the names. If those names 
were exposed to end users I wouldn't find it acceptable either. (I want 
to be [email-masked], not [email-masked].)
<DM> Agreed

The question is whether this is the best way to solve that problem.

I think that solution won't be very acceptable to an SP, or to the 
customer of that SP. Having the SP provision every one of your users 
just isn't going to be popular with anyone. (Unless the SP gets a big 
enough per-user fee.)
<DM> I agree but if the parties involved reach an acceptable agreement, the technology should support it IMO.

Its not quite as much of a problem with numbers, because they are likely 
to be managed in blocks. And the numbers are really owned/managed by the 
SP anyway so they are forced to do something about them.

This is also a problem that is not unique to this SP interconnect 
mechanism. It is pretty much the same problem in any big company with a 
lot of sites, even if they have a private network connecting all the sites.

What you need in this case is a proxy at the company domain level 
(cust.sp.net in this case perhaps) that has the roster of all usernames 
and a mapping to a subdomain - mapping [email-masked] to 
[email-masked].
<DM> Yes but some enterprise customers do not want to do this and are able to convince the SP to do this.

Then, the company has one server registering To:cust.sp.net to provide 
this mapping, and other servers registering To:east.cust.sp.net, ...

	Thanks,
	Paul

Middleton, David (NSN - US/Boca Raton) wrote:
> Some colleagues have pointed out an aspect that I had not considered concerning the domain registration To: user part.  There are cases where an Enterprise has multiple PBXs that register and calls should be routed to one of the PBXs based on which user is called.  In other words, instead of the Enterprise with multiple PBXs appearing as one logical PBX, the Enterprise customer wants the service provider to take responsibility for distributing the calls to the specific PBX that hosts the called user.
> 
> While this problem could be solved with a local policy to choose one of several contacts it is not as clean an approach as being able to treat each registration as a separate entity with it's own contact(s).  While one could propose that these be treated separately by making different sub-domains, the Enterprise most assuredly will not want to publish this sub-domain on business cards, etc. when using e-mail style addresses.  Besides, it would cause the address to change if the user moves from one PBX to another as might happen with a physical move.
> 
> Another aspect to consider is that the Enterprise user, in this scenario, is only reachable via one registered "To: user@host".  So not having separate registrations would result in a more complex definition and implementation of things like (a.) is there an unexpired binding and (b.) picking appropriate contacts by q-value.
> 
> I think this makes a strong case for having a user part in the To: header and treating each unique user@host as a separate registration à la RFC 3264.
> 
> In summary, I support Option 1) as well.
> 
> - David
> 
>  
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Richard Shockey
> Sent: Wednesday, October 21, 2009 4:42 PM
> To: [email-masked]
> Subject: Re: [dispatch] To-URI in domain-registration
> 
> +1 to Option 1) as well
> 
>>  -----Original Message-----
>>  From: [email-masked] [mailto:[email-masked]] On
>>  Behalf Of David Hancock
>>  Sent: Wednesday, October 21, 2009 4:05 PM
>>  To: Brian Lindsay; Hadriel Kaplan; [email-masked]
>>  Subject: Re: [dispatch] To-URI in domain-registration
>>  
>>  
>>  Hadriel - I'd prefer option 1) as well.
>>  
>>  David
>>  
>>  > -----Original Message-----
>>  > From: [email-masked] [mailto:[email-masked]]
>>  On
>>  > Behalf Of Brian Lindsay
>>  > Sent: Wednesday, October 21, 2009 1:53 PM
>>  > To: Hadriel Kaplan; [email-masked]
>>  > Subject: Re: [dispatch] To-URI in domain-registration
>>  >
>>  >  Hi Hadriel,
>>  >
>>  >     Per my comment yesterday, I'd prefer (1).
>>  >
>>  >     Thanks.
>>  >
>>  > -----Original Message-----
>>  > From: [email-masked] [mailto:[email-masked]]
>>  On
>>  > Behalf Of Hadriel Kaplan
>>  > Sent: Wednesday, October 21, 2009 3:43 PM
>>  > To: [email-masked]
>>  > Subject: [dispatch] To-URI in domain-registration
>>  >
>>  > Howdy,
>>  > I'd like to get a consensus call on the question of what the To-URI
>>  > should be for the REGISTER request of a domain registration, before
>>  > finishing the next rev of the draft.  This will affect quite a bit
>>  of
>>  > text in the draft (e.g., examples), and I think that the decision
>>  about
>>  > that will also affect whether we need more than a Require:option-tag
>>  as
>>  > well.
>>  >
>>  > The choices right now are:
>>  > 1) Mandate the To-URI be in the syntactical form of an AoR,
>>  including
>>  > the user@ portion, the same as the From-URI.
>>  > 	Pros: closer to what current proprietary and other-SDO
>>  > mechanisms do, on the wire.  Therefore, presumably less of a change
>>  and
>>  > less barrier to adoption.
>>  > 2) Mandate the To-URI be a domain only (no user@), while the From-
>>  URI
>>  > remains the "AoR" of the PBX registering.
>>  > 	Pros: semantically accurate (you're registering a domain, not an
>>  > AoR), and may obviate the need for a new header or param to indicate
>>  > this new mechanism is being used.
>>  >
>>  > Can people please indicate which they'd prefer?
>>  >
>>  > Thanks!
>>  > -hadriel
>>  > _______________________________________________
>>  > dispatch mailing list
>>  > [email-masked]
>>  > https://www.ietf.org/mailman/listinfo/dispatch
>>  > _______________________________________________
>>  > dispatch mailing list
>>  > [email-masked]
>>  > https://www.ietf.org/mailman/listinfo/dispatch
>>  _______________________________________________
>>  dispatch mailing list
>>  [email-masked]
>>  https://www.ietf.org/mailman/listinfo/dispatch
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Nov 2009 17:34:55 -0500

> I think you are on target as far as describing many (perhaps most) SP / PBX interconnect arrangements.  However, the functionality of having the SP route calls per user is a real-world scenario whi…

This could still be dealt with by having the pbxes register to separate 
sub-domains and the SP knowing (via provisioning) which things to route 
to each.

So instead of having:

foo-east-pbx register to [email-masked]
foo-west-pbx register to [email-masked]

you could simply have

foo-east-pbx register to east.foo.sp.com
foo-west-pbx register to west.foo.sp.com

Then the question of how requests addressed to [email-masked] are mapped 
to [email-masked] or [email-masked] is simply out 
of scope of this document.

	Thanks,
	Paul

---

From: "Middleton, David (NSN - US/Boca Raton)" <[email-masked]>
Date: Thu, 12 Nov 2009 06:12:07 -0600

I agree this is possible but having the SP cross-reference domains is not in the spirit of domain registration from my perspective.

-----Original Message-----
From: ext Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, November 11, 2009 5:35 PM
To: Middleton, David (NSN - US/Boca Raton)
Cc: [email-masked]
Subject: Re: [dispatch] To-URI in domain-registration

So instead of having:

you could simply have

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 12 Nov 2009 08:46:34 -0500

> I agree this is possible but having the SP cross-reference domains is not in the spirit of domain registration from my perspective.

But having the SP partition traffic for one domain based on the user 
part of the request *is* in the spirit? IMO it is exactly the same 
thing, or cleaner.

Its a matter of who is responsible for a particular domain, the sp or 
the pbx. IMO you should only take *other* information (such as the 
username) into account if you are responsible for the domain of the 
request. In my example, the sp is responsible for foo.sp.com, but the 
pbxes are responsible for east.foo.sp.com and west.foo.sp.com. The other 
way, both the sp and the pbxes are responsible for foo.sp.com, which is 
problematic to me.

I see from the notes of the ad hoc, that there is some desire to 
restrict the scope to phone numbers. In that case it again is possible 
to give each pbx its own domain name.

	Thanks,
	Paul

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 12 Nov 2009 15:50:21 -0500

To clarify .. in the discussions within the SIPforum there was no question
that the scope was restricted to phone numbers. 

here were only 2-3 participants that did not usually attend IETF meetings
and those represented small CLEC's. As a practical matter the overlap
between IETF and the SIPforum discussions was nearly total. 

>  Behalf Of Paul Kyzivat
>  Sent: Thursday, November 12, 2009 8:47 AM
>  > I agree this is possible but having the SP cross-reference domains
>  is not in the spirit of domain registration from my perspective.
>  
>  >> I think you are on target as far as describing many (perhaps most)
>  SP / PBX interconnect arrangements.  However, the functionality of
>  having the SP route calls per user is a real-world scenario which
>  proves there is merit for having the capability.
>  >
>  >> <DM> I agree but if the parties involved reach an acceptable
>  agreement, the technology should support it IMO.
>  >>
>  >>> Some colleagues have pointed out an aspect that I had not
>  considered concerning the domain registration To: user part.  There
>  are cases where an Enterprise has multiple PBXs that register and
>  calls should be routed to one of the PBXs based on which user is
>  called.  In other words, instead of the Enterprise with multiple PBXs
>  appearing as one logical PBX, the Enterprise customer wants the
>  service provider to take responsibility for distributing the calls to
>  the specific PBX that hosts the called user.
>  >>>
>  >>> While this problem could be solved with a local policy to choose
>  one of several contacts it is not as clean an approach as being able
>  to treat each registration as a separate entity with it's own
>  contact(s).  While one could propose that these be treated separately
>  by making different sub-domains, the Enterprise most assuredly will
>  not want to publish this sub-domain on business cards, etc. when using
>  e-mail style addresses.  Besides, it would cause the address to change
>  if the user moves from one PBX to another as might happen with a
>  physical move.
>  >>>
>  >>> Another aspect to consider is that the Enterprise user, in this
>  scenario, is only reachable via one registered "To: user@host".  So
>  not having separate registrations would result in a more complex
>  definition and implementation of things like (a.) is there an
>  unexpired binding and (b.) picking appropriate contacts by q-value.
>  >>>
>  >>> I think this makes a strong case for having a user part in the To:
>  header and treating each unique user@host as a separate registration à
>  la RFC 3264.
>  >>>
>  On Behalf Of ext Richard Shockey

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 12 Nov 2009 22:50:11 +0100

During the DISPATCH ad hoc session there was indeed a suggestion to limit the mechanism to domains employing E.164-based SIP URIs. However, this would leave an issue with contact URIs, which would presumably not be constrained to being based on telephone numbers. It must be possible to route an out-of-dialog request to a contact URI issued by the SIP-PBX.

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Richard Shockey
> Sent: 12 November 2009 20:50
> To: 'Paul Kyzivat'; 'Middleton, David (NSN - US/Boca Raton)'
> Cc: [email-masked]
> >  way, both the sp and the pbxes are responsible for 
> foo.sp.com, which
> >  is
> >  problematic to me.
> >  
> >  > to [email-masked] or 
> [email-masked] is simply
> >  out
> >  >> <DM>  Yes, it requires a local policy to determine the 
> location of
> >  the users.
> >  >>
> >  >> Subdomains east.cust.sp.net and west.cust.sp.net solve 
> this problem
> >  in
> >  >> were exposed to end users I wouldn't find it acceptable 
> either. (I
> >  want
> >  >> just isn't going to be popular with anyone. (Unless the 
> SP gets a
> >  big
> >  >> enough per-user fee.)
> >  >> Its not quite as much of a problem with numbers, 
> because they are
> >  likely
> >  >> to be managed in blocks. And the numbers are really 
> owned/managed
> >  by the
> >  >> <DM> Yes but some enterprise customers do not want to 
> do this and
> >  are able to convince the SP to do this.
> >  >>
> >  >>>>  > I'd like to get a consensus call on the question 
> of what the
> >  To-URI
> >  >>>>  > should be for the REGISTER request of a domain 
> registration,
> >  before
> >  >>>>  > finishing the next rev of the draft.  This will 
> affect quite a
> >  bit
> >  >>>>  of
> >  >>>>  > mechanisms do, on the wire.  Therefore, presumably 
> less of a
> >  change
> >  >>>>  and
> >  >>>>  > 2) Mandate the To-URI be a domain only (no user@), 
> while the
> >  From-
> >  >>>>  URI
> >  >>>>  > 	Pros: semantically accurate (you're registering 
> a domain,
> >  not an

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 12 Nov 2009 17:30:10 -0500

> During the DISPATCH ad hoc session there was indeed a suggestion to limit the mechanism to domains employing E.164-based SIP URIs. However, this would leave an issue with contact URIs, which would…

Hmm, that's true. And it sheds a different light on the question about 
whether the To: of the register can have a username as well as domain name.

The argument for that has been that then the SP can steer requests to 
different pbxes in the same domain.

I can see how that could work for phone numbers - static configuration 
of those to different "usernames@domain".

I can *possibly* imagine that working for email style URIs too, though 
it would require the SP to provision all the usernames in the domain 
that the PBXes share.

But I really *can't* imagine how that can work for contact addresses 
using the shared domain and some arbitrary username part.

	Thanks,
	Paul

>> [mailto:[email-masked]] On
>>>  Behalf Of Paul Kyzivat
>> [mailto:[email-masked]]