Subject: [martini] Question on gin and variable number lengths

From: "Elwell, John" <[email-masked]>
Date: Fri, 9 Apr 2010 12:57:32 +0200

Suppose my SSP (or numbering authority) has my allocated to my PBX numbers beginning +4357008, meaning that I can use that number and any extension of that number (e.g., +43570080, +4357008555, +435700866666), as long as the maximum E.164 number length is not exceeded). This is common practice in a few countries (I am aware of Germany and Austria). As far as I know, the SSP does not need to be aware of the number lengths I choose to use.

For basic gin operation I don't see a problem with this, although clearly the SSP's implementation of the location service will need to reflect this possibility (i.e., it cannot have explicit mappings for every conceivable number). It may have impact on the reg-event package, however, requiring some sort of short-hand representation of registered contacts. This sounds like a similar problem to that raised by Hadriel with non-E.164 numbers.

John

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 9 Apr 2010 13:26:44 +0200

Hi John,

I thought this was covered by the last sentence in the gin recepy: "After
the PBX is authenticated, the registrar updates its location service so that
each of the phone numbers associated with the PBX creates a unique AOR to
Contact mapping. Semantically, each of these mappings will be treated as a
unique row in the location service. The actual implementation may, of
course, perform internal optimizations to reduce the amount of  memory used
to store such information."

In my mind having a wild-carded entry that matches such a number block, is
such an optimization. I do not see the relation with local numbers.

/Hans Erik van Elburg

On Fri, Apr 9, 2010 at 12:57 PM, Elwell, John <
[email-masked]> wrote:

> Suppose my SSP (or numbering authority) has my allocated to my PBX numbers
> beginning +4357008, meaning that I can use that number and any extension of
> that number (e.g., +43570080, +4357008555, +435700866666), as long as the
> maximum E.164 number length is not exceeded). This is common practice in a
> few countries (I am aware of Germany and Austria). As far as I know, the SSP
> does not need to be aware of the number lengths I choose to use.
>
> For basic gin operation I don't see a problem with this, although clearly
> the SSP's implementation of the location service will need to reflect this
> possibility (i.e., it cannot have explicit mappings for every conceivable
> number). It may have impact on the reg-event package, however, requiring
> some sort of short-hand representation of registered contacts. This sounds
> like a similar problem to that raised by Hadriel with non-E.164 numbers.
>
> John
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 9 Apr 2010 14:32:13 +0200

> -----Original Message-----
> From: Hans Erik van Elburg [mailto:[email-masked]] 
> Sent: 09 April 2010 12:27
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [martini] Question on gin and variable number lengths
> 
> Hi John,
> 
> I thought this was covered by the last sentence in the gin 
> recepy: "After the PBX is authenticated, the registrar 
> updates its location service so that each of the phone 
> numbers associated with the PBX creates a unique AOR to 
> Contact mapping. Semantically, each of these mappings will be 
> treated as a unique row in the location service. The actual 
> implementation may, of course, perform internal optimizations 
> to reduce the amount of  memory used to store such information."
[JRE] Yes, that was what I was trying to refer to, so I agree there should not be a problem for basic gin.

> 
> In my mind having a wild-carded entry that matches such a 
> number block, is such an optimization. I do not see the 
> relation with local numbers.
[JRE] The relationship with local numbers was only in the context of the reg-event package. Clearly, if the SSP does not know the precise set of numbers used (and if up to 5 extension digits are available, this gives a potential for 11,111 different numbers - 10,000 5 digit numbers plus 1000 4 digits numbers, etc.), how would the SSP populate notifications? Listing all potential numbers would result in very large notifications.

John

> 
> /Hans Erik van Elburg
> 
> 
> On Fri, Apr 9, 2010 at 12:57 PM, Elwell, John 
> <[email-masked]> wrote:
> 
> 
> 	Suppose my SSP (or numbering authority) has my 
> allocated to my PBX numbers beginning +4357008, meaning that 
> I can use that number and any extension of that number (e.g., 
> +43570080, +4357008555, +435700866666), as long as the 
> maximum E.164 number length is not exceeded). This is common 
> practice in a few countries (I am aware of Germany and 
> Austria). As far as I know, the SSP does not need to be aware 
> of the number lengths I choose to use.
> 	
> 	For basic gin operation I don't see a problem with 
> this, although clearly the SSP's implementation of the 
> location service will need to reflect this possibility (i.e., 
> it cannot have explicit mappings for every conceivable 
> number). It may have impact on the reg-event package, 
> however, requiring some sort of short-hand representation of 
> registered contacts. This sounds like a similar problem to 
> that raised by Hadriel with non-E.164 numbers.
> 	
> 	John

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 9 Apr 2010 14:48:56 +0200

On Fri, Apr 9, 2010 at 2:32 PM, Elwell, John <
[email-masked]> wrote:

> [JRE] The relationship with local numbers was only in the context of the
> reg-event package. Clearly, if the SSP does not know the precise set of
> numbers used (and if up to 5 extension digits are available, this gives a
> potential for 11,111 different numbers - 10,000 5 digit numbers plus 1000 4
> digits numbers, etc.), how would the SSP populate notifications? Listing all
> potential numbers would result in very large notifications.
>
> In that case having a wildcard representation also  in regevent packages
sounds like a good idea.

/Hans Erik van Elburg

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 9 Apr 2010 08:20:35 -0500

Speaking as individual, my impression was that we didn't have a lot of 
objection to support for wildcarding - the concern (focused around the 
PUBLISH-based UP proposal, if that helps locate threads), most consistently 
stated by Rich Shockey, was that we couldn't count on wildcarding to 
guarantee that the size of the wildcarded expression would fit in 
request/response size limitations for UDP operation, whether due to number 
range fragmentation or simply because a bunch of unrelated numbers were 
involved.

Again, speaking as individual, if it's helpful for us to define a 
wildcarding syntax, it would be more helpful if we do that soon, so that we 
don't have deployed implementations that don't understand that syntax when 
we DO define it...

Thanks,

Spencer

----- Original Message ----- 
From: Hans Erik van Elburg

/Hans Erik van Elburg

---

From: Adam Roach <[email-masked]>
Date: Fri, 09 Apr 2010 09:05:07 -0500

On 4/9/10 7:48 AM, Hans Erik van Elburg wrote:
> On Fri, Apr 9, 2010 at 2:32 PM, Elwell, John 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     >
>     [JRE] The relationship with local numbers was only in the context
>     of the reg-event package. Clearly, if the SSP does not know the
>     precise set of numbers used (and if up to 5 extension digits are
>     available, this gives a potential for 11,111 different numbers -
>     10,000 5 digit numbers plus 1000 4 digits numbers, etc.), how
>     would the SSP populate notifications? Listing all potential
>     numbers would result in very large notifications.
>
> In that case having a wildcard representation also  in regevent 
> packages sounds like a good idea.

The problem is that the entity receiving the reg event bodies isn't a 
party to the initial REGISTER transaction. This means that it isn't part 
of the negotiation of the use of the bulk-number-registration feature.

As a consequence, when he attempts to subscribe to the reg event for the 
PBX, he'll get back a modified syntax. A syntax based on a protocol 
extension. A protocol extension he did not indicate support for, and he 
does not understand.

And that's an interop problem.

As we discussed in Anaheim, I plan to put together a draft that talks 
about an _optional_ explicit indication of extensions at registration 
time. Use of such an indication completely solves the "variable length 
extensions" problem.

/a

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 9 Apr 2010 16:20:46 +0200

Spencer,

The point is, it would only need to apply to the reg-event package, and that need not be part of the initial MARTINI deliverables.

John 

> From: Spencer Dawkins [mailto:[email-masked]] 
> Sent: 09 April 2010 14:21
> To: Hans Erik van Elburg; Elwell, John
> Cc: [email-masked]

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 9 Apr 2010 09:22:37 -0500

Hi, John,

That is a lovely answer.

Spencer, speaking as co-chair

----- Original Message ----- 
From: "Elwell, John" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>; "Hans Erik van Elburg" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Friday, April 09, 2010 9:20 AM
Subject: RE: [martini] Question on gin and variable number lengths

Spencer,

The point is, it would only need to apply to the reg-event package, and that 
need not be part of the initial MARTINI deliverables.

John

> =

---

From: Adam Roach <[email-masked]>
Date: Fri, 09 Apr 2010 10:28:47 -0500

I also think it's highly flawed, as an answer. See my earlier mail about 
foisting a protocol extension syntax on a reg event subscriber who does 
not understand the protocol extension.

/a

On 4/9/10 9:22 AM, Spencer Dawkins wrote:
> ----- Original Message ----- From: "Elwell, John" 
> <[email-masked]>
> To: "Spencer Dawkins" <[email-masked]>; "Hans Erik van 
> Elburg" <[email-masked]>
> Cc: <[email-masked]>
> The point is, it would only need to apply to the reg-event package, 
> and that need not be part of the initial MARTINI deliverables.
>
> John
>
>> ----- Original Message ----- From: Hans Erik van Elburg
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Apr 2010 12:37:25 -0400

Adam,

We could consider making the wildcarded data an extension to the 
application/reginfo+xml syntax from rfc 3680, just as rfc 5628 extended 
it. E.g., another element within <contact> to describe the wildcard.

There is already provision for extension elements, so this would be 
backward compatible.

To make this work it would only be necessary to specify how the basic 
syntax of the contact would be denoted. I think we could simply use the 
uri without user part for this.

	Thanks,
	Paul

---

From: Hans Erik van Elburg <[email-masked]>
Date: Sat, 10 Apr 2010 06:42:36 +0200

Yes, without having checked the details of reginfo this seems to be the way
to go.

It is perfectly OK to expect that nodes that are interested in this
information understand the extension.

/Hans Erik van Elburg

On Fri, Apr 9, 2010 at 6:37 PM, Paul Kyzivat <[email-masked]> wrote:

> application/reginfo+xml syntax from rfc 3680, just as rfc 5628 extended it.
> E.g., another element within <contact> to describe the wildcard.
>
> syntax of the contact would be denoted. I think we could simply use the uri
> without user part for this.
>
>        Thanks,
>        Paul
>
>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 10 Apr 2010 10:14:00 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: Friday, April 09, 2010 12:37 PM
> 

Yeah I don't see a _general_ issue with backwards-compatibility - an rfc3680 UA subscribing and getting an unknown namespace extension XML element is supposed to ignore it.  But see below for what I think is the specific issue.

> uri without user part for this.

Just to be clear, it's not a contact URI we're talking about, right?  This is a variable-length AoR.  So the rub is: can you use a "registration" XML element for it, in a backwards-compatible way? 

It also raises a corner-case issue: imagine if the SSP allocates a variable length number of prefix 12345, but also does know and handle the specific AoR number 12345678.  This can happen in a private numbering plan for example, where the SSP may have centrex service for some specific numbers in a block, but the rest of the block is handled by the PBX at the Enterprise.  So we'd have to handle that somehow, and handle it in a way that lets the specific number 12345678 be registered from multiple contacts, including possibly the PBX itself.

-hadriel

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 12 Apr 2010 10:18:34 +0200

On Sat, Apr 10, 2010 at 4:14 PM, Hadriel Kaplan <[email-masked]>wrote:

>
> It also raises a corner-case issue: imagine if the SSP allocates a variable
> length number of prefix 12345, but also does know and handle the specific
> AoR number 12345678.  This can happen in a private numbering plan for
> example, where the SSP may have centrex service for some specific numbers in
> a block, but the rest of the block is handled by the PBX at the Enterprise.
>  So we'd have to handle that somehow, and handle it in a way that lets the
> specific number 12345678 be registered from multiple contacts, including
> possibly the PBX itself.
>
> It is not totally clear where you see the problem, but if it is the
matching bit then specifying that the best match wins will resolve this. In
the sense that 12345 matches better with the record with name 12345 then
with the record with wildcarded id 12345*.

/Hans Erik van Elburg

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Apr 2010 09:06:28 -0400

> Just to be clear, it's not a contact URI we're talking about, right?  This is a variable-length AoR.  So the rub is: can you use a "registration" XML element for it, in a backwards-compatible way? 

Duh, that's true.

It can still be done compatibly with the existing schema, but using a 
different extensibility hook. The top level <reginfo> contains a 
sequence of <registration> followed by an optional sequence of other 
stuff. To do this entirely cleanly we might have to define a new variant 
on <registration> where the aor= is replaced by something else that 
allows for wildcards or ranges or ....

(My knowledge of xml is insufficient to specify in detail the best way 
to accomplish this.)

There is some serious work to do here.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 12 Apr 2010 22:56:09 -0400

I think we'd just need to agree on what the "rule" is, basically.  And consider/document what it means when a more-specific match exists.

For example, if it's a longest-prefix-match rule as you describe, then does that mean the shorter prefix one does or does not also include the longer AoR? (i.e., is the longer AoR registered twice, or is the longer entry's range effectively removed from the shorter prefix one)

And if try to subscribe for the prefix, am I also subscribing for the longer one?  How would I know if a longer one exists if it's not auto-included? Etc.

-hadriel

________________________________________
From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Monday, April 12, 2010 4:19 AM
To: Hadriel Kaplan

It is not totally clear where you see the problem, but if it is the matching bit then specifying that the best match wins will resolve this. In the sense that 12345 matches better with the record with name 12345 then with the record with wildcarded id 12345*.

/Hans Erik van Elburg