Subject: [martini] Request for SSP perspective

From: "Tyler Parkin" <[email-masked]>
Date: Tue, 6 Apr 2010 11:17:02 -0400

Looking at the list, it seems there is a large (and vocal) group of PBX representatives and a smaller (and nearly inaudible) list of SSP's.  I guess what I'd like to see as an SSP is for other SSP's to speak up and constructively point out the issues they see with GIN, if not propose solutions.  

For a while it looked like there was one SSP saying "Looks good" and another saying "wait a sec...," but it seems that now there are a couple more voicing concerns about the proposal.

As an example, as an SSP my concerns are the following (and I've repeatedly argued these in the past):

1) Interoperability with PBX's that don't support implicit reg (I'm in favor of the options tag)

2) Not defining the behavior of middle boxes's and proxy's along with the registrars, even generically.  I've got a half dozen major players in my network; I don't care if your PBX supports implicit reg, if either my SBC (or yours) or my registrar don't interop in the same fashion your PBX will never be able to bulk reg with me.

3) Not indicating some sort of contact based registration status.  If you think you're implicitly registering 400 telnos and I think you're registering 395, we've got a mismatch.  I don't want a PBX sending me notify's and subscribe's every 15 seconds for a number I don't have on that account.  Alternatively, if you think you're registering 395 and I think you have 400, you don't want me sending you calls for numbers you don't have configured (and I sure as heck don't want to lol).  There's been griping about provisioning, and how it's not included in MARTINI, but I see provisioning and some agreement on registered contacts as different items.  Even if at minimum it's just an indicator of how MANY different contacts you think you're registering, that's better than the blind faith model.  If I 404 your bulk reg request, you could fall back to individual registrations.

A couple points ~ 

I own (and lease in some cases) the last mile, and I own the IP address space.  Because of that, I don't see moving to a DNS/domain based solution as a huge driver.  So the locator stuff isn't a huge concern for me.  I know that pisses off some people on this list (SIP purests/p2p fans =) ).  

Also, I see IMS as a good idea and something to drive my network towards as a future goal, but I don't have an imediate NEED for it because I don't have mobile subscribers or internet based subs.  If/when I get internet based subs or start a lot of wholesale peering, I might work towards it faster.  I guess I mention that because I don't see IMS as a scale/sizing issue (i.e ATT vs. the little CLEC), so much as I see it as a services and priority issue.

Thanks,

Tyler Parkin

---

From: <[email-masked]>
Date: Tue, 6 Apr 2010 17:25:07 +0200

________________________________

	De : [email-masked] [mailto:[email-masked]] De la part de Tyler Parkin
	Envoyé : mardi 6 avril 2010 17:17
	À : [email-masked]
	Objet : [martini] Request for SSP perspective

	 

	 

	A couple points ~ 

	Also, I see IMS as a good idea and something to drive my network towards as a future goal, but I don't have an imediate NEED for it because I don't have mobile subscribers or internet based subs.  If/when I get internet based subs or start a lot of wholesale peering, I might work towards it faster.  I guess I mention that because I don't see IMS as a scale/sizing issue (i.e ATT vs. the little CLEC), so much as I see it as a services and priority issue.
	[==>BC:] The so-called "IMS solution" documented in 3GPP/ETSI specifications would work with a different architecture than the IMS, all the more so if the option-tag was added on top of it (as initially proposed in the 'shaken' draft).  
	 
	Thanks,
	 
	Tyler Parkin

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 6 Apr 2010 12:31:38 -0400

Hi Tyler,
Comments inline...

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tyler Parkin
Sent: Tuesday, April 06, 2010 11:17 AM
To: [email-masked]
Subject: [martini] Request for SSP perspective

[hsk] Cool, we have agreement on at least one point. :)

Do you mean define what they should do at a policy layer? That's really hard to do in the IETF, because it's basically specific to every deployment.
If you mean at a protocol layer, then I think we have the proxy and Registrar behavior in the draft.  For B2BUA's, if what you're worried about is the contact-URI stuff we could put some helpful guidance in the draft.  What in particular are you concerned about?

That's not a bad idea (sending the number of contacts), but I'm worried it will cause more issues than it solves, by having false positives/negatives. And I definitely would not want a PBX automatically reverting to individual Registrations if it gets a mismatch.
As an aside on the rteg-event piece: I believe the idea with doing the reg-event subscription was it would be in bulk as well - i.e., one Subscription, which sends you one Notify with all the contacts in it.

-hadriel

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 6 Apr 2010 11:49:22 -0500

As an individual contributor...

I'm not any happier about the current "say nothing" behavior than Tyler is. The question is, how much can the endpoints actually say to each other about what's being registered.

My hangup on sending lists of AoRs back and forth has been completely on the basis of MTU size restrictions, and concerns about whether TCP could be successfully used, either as primary transport or as fallback. If these concerns are real, wishing that they could be overcome isn't helpful - we need to either overcome them or try something else.

I could be talked into sending a count of AoRs expected to be registered/actually registered in both directions. If other people share Hadriel's concerns about false positives (my 500 AoRs aren't your 500 AoRs), I could be talked into sending a hash of the AoRs in both directions - if these don't match, knowing about that mismatch could be helpful as well.

If we required TCP, we'd be having a different discussion, and SIPconnect strongly prefers TCP, but I've gotten no encouragement that this would be acceptable in the IETF, so haven't pursued it further.

Thoughts?

Spencer, as individual contributor
  ----- Original Message ----- 
  From: Hadriel Kaplan 
  To: Tyler Parkin ; [email-masked] 
  Sent: Tuesday, April 06, 2010 11:31 AM
  Subject: Re: [martini] Request for SSP perspective

  Hi Tyler,

  Comments inline.

------------------------------------------------------------------------------

  [hsk] Cool, we have agreement on at least one point. J

   

  -hadriel 

------------------------------------------------------------------------------

  _______________________________________________
  martini mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/martini

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 6 Apr 2010 12:55:58 -0400

Actually my concern was more that I think I'm registering 500 AoR's, but unbeknownst to me in the reg-DB it's (correctly) instantiated as 501 or 499 or a regex wildcard or who knows what, and I get back the number "501" or "499" or "1" - even though it's actually all correct/right.

-hadriel

________________________________
From: Spencer Dawkins [mailto:[email-masked]]
Sent: Tuesday, April 06, 2010 12:49 PM
To: Hadriel Kaplan; Tyler Parkin; [email-masked]
Subject: Re: [martini] Request for SSP perspective

Thoughts?

----- Original Message -----
From: Hadriel Kaplan<mailto:[email-masked]>
To: Tyler Parkin<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Sent: Tuesday, April 06, 2010 11:31 AM
Subject: Re: [martini] Request for SSP perspective

Hi Tyler,
Comments inline...

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Tyler Parkin
Sent: Tuesday, April 06, 2010 11:17 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [martini] Request for SSP perspective

-hadriel

---

From: "Tyler Parkin" <[email-masked]>
Date: Tue, 6 Apr 2010 12:57:09 -0400

Hi Hadriel,

My comments inline also.

Thanks,
Tyler
  ----- Original Message ----- 
  From: Hadriel Kaplan 
  To: Tyler Parkin ; [email-masked] 
  Sent: Tuesday, April 06, 2010 12:31 PM
  Subject: RE: [martini] Request for SSP perspective

  Hi Tyler,

  Comments inline.

  [TP] I don't mean to suggest that the draft say how the registrar/SBC should impliment this, but at the protocal layer it would be nice to have agreement on whether a GRUU should be appended, or a cookie, etc.  There have been different suggestions, but with respect to the suggestors, if we can get 3 diff proposals "off the top of the head" on this list, then that's at least three diff ways that the different SBC/Registrar vendors can impliment their support for GIN, which leads to interop issues.  Say, just for example, if we were to use a standard SIP-NAT with an Acme SBC, I'm sure you know the result is that all the different public addresses are NAT'd at the IP and Protocol layer so that they show up to the registrar as originating from a single Private IP on the SBC core side.  So if a PBX registers the BNC contact (i.e. bnc@privateip), I guess my concern is when the BNC is sent to the registrar that is the ONLY contact the SBC has for that PBX.  So if the registrar then sends a request to the SBC for an individual contact (i.e. user@privateip) how is the SBC going to know which PBX to send the request to.  Obviously, a cookie on the initial registration seems most likely, all I'm asking is that it be specified in the draft so that 4 different SBC vendors don't do a cookie, or a request-uri as the BNC and the contact URI as the user, or map to some PAU, etc.  My interest is that everybody play nice from the get go so we can get this in production more quickly.

  [TP] Agreed on the rteg-event piece, but my issue is that it's reactive and not required.  If my registrar thinks there are 400 numbers registered, and the PBX subcribes to receive the list of contacts, that doesn't prevent me from sending calls to the mismatched URI's and there's nothing to even require that the PBX subscribe to the event in the first place.  The point of this, I believe, is to reduce the amount of messaging required to register hundreds or thousands of contacts.  IMO, I'd rather receive registrations that I can throttle (using your nifty tools) and that have a hold down timer for 404'd reg's on the UA side, than have a PBX think a dozen or more telnos are registered when they aren't and send me a ton of ancillary messages for them at very short intervals.  On example would be where a customer calls in a MAC to disco a range of 100 DID's out of 500 and their vendor doesn't get there for two weeks to disable them in the PBX.

  -hadriel 

  Tyler

---

From: Adam Roach <[email-masked]>
Date: Tue, 06 Apr 2010 12:01:07 -0500

If I may be so bold as to extrapolate from what Spencer said -- I read 
his suggestion to mean you would include a count and/or hash of the 
E.164 numbers in the range. If the SSP is doing other database magic for 
operational or efficiency reasons, that's just fine -- but it doesn't 
need to be visible on the wire.

I think the hash approach is actually quite clever, as it completely 
solves the half of the problem dealing with provisioning mismatches.

/a

On 4/6/10 11:55, Apr 6, Hadriel Kaplan wrote:
>
> Actually my concern was more that I think I'm registering 500 AoR's, 
> but unbeknownst to me in the reg-DB it's (correctly) instantiated as 
> 501 or 499 or a regex wildcard or who knows what, and I get back the 
> number "501" or "499" or "1" -- even though it's actually all 
> correct/right.
>
> -hadriel
>
> ------------------------------------------------------------------------
>
> *From:* Spencer Dawkins [mailto:[email-masked]]
> *Sent:* Tuesday, April 06, 2010 12:49 PM
> *To:* Hadriel Kaplan; Tyler Parkin; [email-masked]
> *Subject:* Re: [martini] Request for SSP perspective
>
> I'm not any happier about the current "say nothing" behavior than 
> Tyler is. The question is, how much can the endpoints actually say to 
> each other about what's being registered.
>
> My hangup on sending lists of AoRs back and forth has been completely 
> on the basis of MTU size restrictions, and concerns about whether TCP 
> could be successfully used, either as primary transport or as 
> fallback. If these concerns are real, wishing that they could be 
> overcome isn't helpful - we need to either overcome them or try 
> something else.
>
> I could be talked into sending a count of AoRs expected to be 
> registered/actually registered in both directions. If other people 
> share Hadriel's concerns about false positives (my 500 AoRs aren't 
> your 500 AoRs), I could be talked into sending a hash of the AoRs in 
> both directions - if these don't match, knowing about that mismatch 
> could be helpful as well.
>
> If we required TCP, we'd be having a different discussion, and 
> SIPconnect strongly prefers TCP, but I've gotten no encouragement that 
> this would be acceptable in the IETF, so haven't pursued it further.
>
> Thoughts?
>
>     *From:* Hadriel Kaplan <mailto:[email-masked]>
>
>     *To:* Tyler Parkin <mailto:[email-masked]> ; [email-masked]
>     <mailto:[email-masked]>
>
>     *Sent:* Tuesday, April 06, 2010 11:31 AM
>
>     *Subject:* Re: [martini] Request for SSP perspective
>
>     Hi Tyler,
>
>     Comments inline...
>
>     ------------------------------------------------------------------------
>
>     *From:* [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked]] *On Behalf Of *Tyler Parkin
>     *Sent:* Tuesday, April 06, 2010 11:17 AM
>     *To:* [email-masked] <mailto:[email-masked]>
>     *Subject:* [martini] Request for SSP perspective
>
>     Looking at the list, it seems there is a large (and vocal) group
>     of PBX representatives and a smaller (and nearly inaudible) list
>     of SSP's.  I guess what I'd like to see as an SSP is for other
>     SSP's to speak up and constructively point out the issues they see
>     with GIN, if not propose solutions.
>
>     For a while it looked like there was one SSP saying "Looks good"
>     and another saying "wait a sec...," but it seems that now there
>     are a couple more voicing concerns about the proposal.
>
>     2) Not defining the behavior of middle boxes's and proxy's along
>     with the registrars, even generically.  I've got a half dozen
>     major players in my network; I don't care if your PBX supports
>     implicit reg, if either my SBC (or yours) or my registrar don't
>     interop in the same fashion your PBX will never be able to bulk
>     reg with me.
>
>     Do you mean define what they should do at a policy layer? That's
>     really hard to do in the IETF, because it's basically specific to
>     every deployment.
>
>     If you mean at a protocol layer, then I /think/ we have the proxy
>     and Registrar behavior in the draft.  For B2BUA's, if what you're
>     worried about is the contact-URI stuff we could put some helpful
>     guidance in the draft.  What in particular are you concerned about?
>
>     3) Not indicating some sort of contact based registration status. 
>     If you think you're implicitly registering 400 telnos and I think
>     you're registering 395, we've got a mismatch.  I don't want a PBX
>     sending me notify's and subscribe's every 15 seconds for a
>     number I don't have on that account.  Alternatively, if you think
>     you're registering 395 and I think you have 400, you don't want me
>     sending you calls for numbers you don't have configured (and I
>     sure as heck don't want to lol).  There's been griping about
>     provisioning, and how it's not included in MARTINI, but I see
>     provisioning and some agreement on registered contacts as
>     different items.  Even if at minimum it's just an indicator of how
>     MANY different contacts you think you're registering, that's
>     better than the blind faith model.  If I 404 your bulk reg
>     request, you could fall back to individual registrations.
>
>     That's not a bad idea (sending the number of contacts), but I'm
>     worried it will cause more issues than it solves, by having false
>     positives/negatives. And I definitely would not want a PBX
>     automatically reverting to individual Registrations if it gets a
>     mismatch.
>
>     As an aside on the rteg-event piece: I believe the idea with doing
>     the reg-event subscription was it would be in bulk as well --
>     i.e., one Subscription, which sends you one Notify with all the
>     contacts in it.
>
>     -hadriel
>
>     ------------------------------------------------------------------------
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 6 Apr 2010 12:45:34 -0500

Hi, Adam,

Yes, that's what I was thinking exactly - thanks for translating!

Spencer
  ----- Original Message ----- 
  From: Adam Roach 
  To: Hadriel Kaplan 
  Cc: Spencer Dawkins ; Tyler Parkin ; [email-masked] 
  Sent: Tuesday, April 06, 2010 12:01 PM
  Subject: Re: [martini] Request for SSP perspective

  If I may be so bold as to extrapolate from what Spencer said -- I read his suggestion to mean you would include a count and/or hash of the E.164 numbers in the range. If the SSP is doing other database magic for operational or efficiency reasons, that's just fine -- but it doesn't need to be visible on the wire.

  I think the hash approach is actually quite clever, as it completely solves the half of the problem dealing with provisioning mismatches.

  /a

    -hadriel

----------------------------------------------------------------------------

    Thoughts?

      ----- Original Message ----- 

      From: Hadriel Kaplan 

      Hi Tyler,

      Comments inline.

--------------------------------------------------------------------------

      -hadriel 

--------------------------------------------------------------------------

---

From: "Brian Lindsay" <[email-masked]>
Date: Tue, 6 Apr 2010 13:54:14 -0400

Hi Spencer/all,
 
    Regarding detection of provisioning mismatches, my thought is this
should be out of scope since the provisioning mechanism itself is out of
scope of MARTINI. (It seems hard to argue that we need a way to detect
mismatches in the MARTINI mechanism when the provisioning mechanism
itself could be robust and prevent/preclude/minimize mismatches).
 
    Thanks
       Brian

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Spencer Dawkins
Sent: Tuesday, April 06, 2010 1:46 PM
To: Adam Roach; Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [martini] Request for SSP perspective

Hi, Adam,

Spencer

	----- Original Message ----- 
	From: Adam Roach <mailto:[email-masked]>  
	To: Hadriel Kaplan <mailto:[email-masked]>  
	Cc: Spencer Dawkins <mailto:[email-masked]>  ; Tyler
Parkin <mailto:[email-masked]>  ; [email-masked] 
	Sent: Tuesday, April 06, 2010 12:01 PM
	Subject: Re: [martini] Request for SSP perspective

	If I may be so bold as to extrapolate from what Spencer said --
I read his suggestion to mean you would include a count and/or hash of
the E.164 numbers in the range. If the SSP is doing other database magic
for operational or efficiency reasons, that's just fine -- but it
doesn't need to be visible on the wire.
	
	I think the hash approach is actually quite clever, as it
completely solves the half of the problem dealing with provisioning
mismatches.
	
	/a

		Actually my concern was more that I think I'm
registering 500 AoR's, but unbeknownst to me in the reg-DB it's
(correctly) instantiated as 501 or 499 or a regex wildcard or who knows
what, and I get back the number "501" or "499" or "1" - even though it's
actually all correct/right.

		-hadriel

		I'm not any happier about the current "say nothing"
behavior than Tyler is. The question is, how much can the endpoints
actually say to each other about what's being registered.

		My hangup on sending lists of AoRs back and forth has
been completely on the basis of MTU size restrictions, and concerns
about whether TCP could be successfully used, either as primary
transport or as fallback. If these concerns are real, wishing that they
could be overcome isn't helpful - we need to either overcome them or try
something else.

		I could be talked into sending a count of AoRs expected
to be registered/actually registered in both directions. If other people
share Hadriel's concerns about false positives (my 500 AoRs aren't your
500 AoRs), I could be talked into sending a hash of the AoRs in both
directions - if these don't match, knowing about that mismatch could be
helpful as well.

		If we required TCP, we'd be having a different
discussion, and SIPconnect strongly prefers TCP, but I've gotten no
encouragement that this would be acceptable in the IETF, so haven't
pursued it further.

		Thoughts?

			----- Original Message ----- 

			From: Hadriel Kaplan
<mailto:[email-masked]>  

			To: Tyler Parkin <mailto:[email-masked]>  ;
[email-masked] 

			Subject: Re: [martini] Request for SSP
perspective

			Hi Tyler,

			Comments inline...

			From: [email-masked]
[mailto:[email-masked]] On Behalf Of Tyler Parkin
			Sent: Tuesday, April 06, 2010 11:17 AM
			To: [email-masked]
			Subject: [martini] Request for SSP perspective

			Looking at the list, it seems there is a large
(and vocal) group of PBX representatives and a smaller (and nearly
inaudible) list of SSP's.  I guess what I'd like to see as an SSP is for
other SSP's to speak up and constructively point out the issues they see
with GIN, if not propose solutions.  

			For a while it looked like there was one SSP
saying "Looks good" and another saying "wait a sec...," but it seems
that now there are a couple more voicing concerns about the proposal.

			As an example, as an SSP my concerns are the
following (and I've repeatedly argued these in the past):

			1) Interoperability with PBX's that don't
support implicit reg (I'm in favor of the options tag)

			[hsk] Cool, we have agreement on at least one
point. :-)

			2) Not defining the behavior of middle boxes's
and proxy's along with the registrars, even generically.  I've got a
half dozen major players in my network; I don't care if your PBX
supports implicit reg, if either my SBC (or yours) or my registrar don't
interop in the same fashion your PBX will never be able to bulk reg with
me.

			Do you mean define what they should do at a
policy layer? That's really hard to do in the IETF, because it's
basically specific to every deployment.

			If you mean at a protocol layer, then I think we
have the proxy and Registrar behavior in the draft.  For B2BUA's, if
what you're worried about is the contact-URI stuff we could put some
helpful guidance in the draft.  What in particular are you concerned
about?

			3) Not indicating some sort of contact based
registration status.  If you think you're implicitly registering 400
telnos and I think you're registering 395, we've got a mismatch.  I
don't want a PBX sending me notify's and subscribe's every 15 seconds
for a number I don't have on that account.  Alternatively, if you think
you're registering 395 and I think you have 400, you don't want me
sending you calls for numbers you don't have configured (and I sure as
heck don't want to lol).  There's been griping about provisioning, and
how it's not included in MARTINI, but I see provisioning and some
agreement on registered contacts as different items.  Even if at minimum
it's just an indicator of how MANY different contacts you think you're
registering, that's better than the blind faith model.  If I 404 your
bulk reg request, you could fall back to individual registrations.

			That's not a bad idea (sending the number of
contacts), but I'm worried it will cause more issues than it solves, by
having false positives/negatives. And I definitely would not want a PBX
automatically reverting to individual Registrations if it gets a
mismatch.

			As an aside on the rteg-event piece: I believe
the idea with doing the reg-event subscription was it would be in bulk
as well - i.e., one Subscription, which sends you one Notify with all
the contacts in it.

			-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 6 Apr 2010 21:31:45 -0400

[converting to plain text 'cause some folks have problems with the html formatting]

> -----Original Message-----
> From: Tyler Parkin [mailto:[email-masked]] 
> Sent: Tuesday, April 06, 2010 12:57 PM
>
> I don't mean to suggest that the draft say how the registrar/SBC should
> impliment this, but at the protocal layer it would be nice to have
> agreement on whether a GRUU should be appended, or a cookie, etc. There
> have been different suggestions, but with respect to the suggestors, if we
> can get 3 diff proposals "off the top of the head" on this list, then 
> that's at least three diff ways that the different SBC/Registrar vendors 
> can impliment their support for GIN, which leads to interop issues.  
>
> Say, just for example, if we were to use a standard SIP-NAT with an Acme
> SBC, I'm sure you know the result is that all the different public 
> addresses are NAT'd at the IP and Protocol layer so that they show up to 
> the registrar as originating from a single Private IP on the SBC core 
> side.  So if a PBX registers the BNC contact (i.e. bnc@privateip), I guess 
> my concern is when the BNC is sent to the registrar that is the ONLY 
> contact the SBC has for that PBX.  So if the registrar then sends a 
> request to the SBC for an individual contact (i.e. user@privateip) how is 
> the SBC going to know which PBX to send the request to.  

If the new option-tag is in the Register and Path is supported, we'd insert cookies in a Path header URI of the Register, which would be reflected in requests coming back to us in a Route header.  

> Obviously, a 
> cookie on the initial registration seems most likely, all I'm asking is 
> that it be specified in the draft so that 4 different SBC vendors don't do 
> a cookie, or a request-uri as the BNC and the contact URI as the user, or 
> map to some PAU, etc.  

OK, I'll suggest some wording that may be palatable.  One thing we need to warn Registrars about too is that they could get multiple IP-PBX's Registering all with the same contact URI, since there is no user portion to disambiguate them as there is today.  This *shouldn't* matter to Registrars, but since we seem to have needed to put cookies in a dozen different places and flavors to accommodate different Registrars in the past, it can't hurt to warn 'em. :)

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Apr 2010 09:22:49 -0400

Hadriel Kaplan wrote:

> One thing we need to warn Registrars about too is that they could get multiple IP-PBX's Registering all with the same contact URI, since there is no user portion to disambiguate them as there is today.  This *shouldn't* matter to Registrars, but since we seem to have needed to put cookies in a dozen different places and flavors to accommodate different Registrars in the past, it can't hurt to warn 'em. :)

Umm - can you explain further about that?

Are you saying that two devices are using the same contact URI 
(containing a NATed address) and those identify distinct devices because 
of a Path header in the register?

As long as the two don't (implicitly) register any numbers in common 
there won't be a problem, since its the supplied contact plus the number 
that ends up in the location service.

But if perchance they have numbers in common, then there is indeed an 
issue. In that case they had better use outbound, which would take care 
of any ambiguity. Otherwise, 3261 registration rules will require only 
the most recent of conflicting registrations, based on the contact 
address, to be kept.

Or else additional procedures for the registrar need to be defined.

	Thanks,
	Paul