Subject: Re: [dispatch] VIPR - proposed charter version 3

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 10 Jul 2010 14:22:12 -0700

Jonathan said:

"Do you argue that we should stop using these forward email routing checks
in the web?"

[BA] I don't think that the security of return reachability is the issue, so
much as the scaling characteristics. 

In this case, more than one mapping between an E.164 number and an
email-style URI can be asserted. 

While invalid mappings will presumably fail the test, the average number of
tests that need to be performed is N/2.  

As N grows, the delay required to upgrade will grow linearly.

In contrast, the Facetime approach (as I understand it) utilizes in-band
communication that yields a delay that cannot be influenced by outside
parties.

---

From: "Mohammad Al-Taraireh (maltarai)" <[email-masked]>
Date: Sun, 11 Jul 2010 11:52:56 -0500

Bernard, 
 
I did not follow the scaling characteristics issue that you are bringing
up. In general only enterprises that advertised ownership of  the E.164
number will be validated against, not every E.164 number in the DHT. 
Since the validation is not a part of call processing, some delay is
acceptable. 
 
Mo A

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Bernard Aboba
Sent: Saturday, July 10, 2010 5:22 PM
To: [email-masked]
Subject: Re: [dispatch] VIPR - proposed charter version 3

Jonathan said:

"Do you argue that we should stop using these forward email routing
checks in the web?"

[BA] I don't think that the security of return reachability is the
issue, so much as the scaling characteristics. 

While invalid mappings will presumably fail the test, the average number
of tests that need to be performed is N/2.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 11 Jul 2010 10:08:07 -0700

Can't anyone advertise ownership of a given E.164 number, regardless of whether they actually own it or not?  What happens if there are a large number of bogus DHT entries?  While the call to the original E.164 number won't be delayed, won't there be additional processing required to figure out what the valid mapping is?  

Subject: RE: [dispatch] VIPR - proposed charter version 3
Date: Sun, 11 Jul 2010 11:52:56 -0500
From: [email-masked]
To: [email-masked]; [email-masked]

Bernard, 
 
I did not follow the scaling characteristics issue that you 
are bringing up. In general only enterprises that advertised ownership 
of  the E.164 number will be validated against, not every E.164 number in 
the DHT. 
Since the validation is not a part of call processing, some 
delay is acceptable. 
 
Mo A

From: [email-masked] 
[mailto:[email-masked]] On Behalf Of Bernard 
Aboba
Sent: Saturday, July 10, 2010 5:22 PM
To: 
[email-masked]
Subject: Re: [dispatch] VIPR - proposed charter 
version 3

Jonathan 
said:
 
"Do 
you argue that we should stop using these forward email routing checks in the 
web?"
 
[BA] I don't think that the 
security of return reachability is the issue, so much as the scaling 
characteristics. 
 
In 
this case, more than one mapping between an E.164 number and an email-style URI 
can be asserted. 
 
While invalid mappings will 
presumably fail the test, the average number of tests that need to be performed 
is N/2.  
 
As 
N grows, the delay required to upgrade will grow linearly.
 
In 
contrast, the Facetime approach (as I understand it) utilizes in-band 
communication that yields a delay that cannot be influenced by outside parties.

---

From: "Mohammad Al-Taraireh (maltarai)" <[email-masked]>
Date: Sun, 11 Jul 2010 16:49:26 -0500

That is correct, however, the protocol, or even the implementation needs
to be designed to handle such cases, no point of implementing a system
that spend all of its processing power trying to validate a number.
There are different ways to handle something like this, for example the
application could potentially stop the validation, and just mark that
E.164 as "Dirty" and not try to validate it again without an
administrator intervention. I am sure there are many ways to handle
something like this, of course at a cost of this E.164 won't be learned
as proposed in the protocol today, but I guess this is why we need this
to be something the IETF adopt, and carry forward.
 
Thanks,
 
Mo A

From: Bernard Aboba [mailto:[email-masked]] 
Sent: Sunday, July 11, 2010 1:08 PM
To: Mohammad Al-Taraireh (maltarai); [email-masked]
Subject: RE: [dispatch] VIPR - proposed charter version 3

Can't anyone advertise ownership of a given E.164 number, regardless of
whether they actually own it or not?  What happens if there are a large
number of bogus DHT entries?  While the call to the original E.164
number won't be delayed, won't there be additional processing required
to figure out what the valid mapping is?  

Bernard, 

Mo A

 

Jonathan said:

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 12 Jul 2010 09:34:44 -0400

Well again given these facts and several others the charter has to be
substantially rewritten for it to stand a reasonable chance of approval.
Though the exception cases will make for interesting reading in the security
considerations, should the discussion go that far.

Well I'll love to see how you will prevent someone from falsely asserting
"ownership" of +1 202 456 1414 or what would happen if some did.

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mohammad Al-Taraireh (maltarai)
Sent: Sunday, July 11, 2010 5:49 PM
To: Bernard Aboba; [email-masked]
Subject: Re: [dispatch] VIPR - proposed charter version 3

That is correct, however, the protocol, or even the implementation needs to
be designed to handle such cases, no point of implementing a system that
spend all of its processing power trying to validate a number. There are
different ways to handle something like this, for example the application
could potentially stop the validation, and just mark that E.164 as "Dirty"
and not try to validate it again without an administrator intervention. I am
sure there are many ways to handle something like this, of course at a cost
of this E.164 won't be learned as proposed in the protocol today, but I
guess this is why we need this to be something the IETF adopt, and carry
forward.

Thanks,

Mo A

  _____  

Can't anyone advertise ownership of a given E.164 number, regardless of
whether they actually own it or not?  What happens if there are a large
number of bogus DHT entries?  While the call to the original E.164 number
won't be delayed, won't there be additional processing required to figure
out what the valid mapping is?  

  _____  

Bernard, 

I did not follow the scaling characteristics issue that you are bringing up.
In general only enterprises that advertised ownership of  the E.164 number
will be validated against, not every E.164 number in the DHT. 

Mo A

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bernard Aboba
Sent: Saturday, July 10, 2010 5:22 PM
To: [email-masked]
Subject: Re: [dispatch] VIPR - proposed charter version 3

Jonathan said:

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 12 Jul 2010 07:09:40 -0700

It strikes me that there are a number of closely related problems here:

a. One problem is the need to be able to "upgrade" an audio call in progress in order to provide for additional media, even if the call had been completed over the PSTN so that there was no SDP offer/answer negotiation between the end-points.  This is the problem that Facetime solves, for example. 

b. Another problem is the need for a public ENUM replacement.  

In the process of solving problem a, we might also need to solve problem b, but that depends on the approach that is taken;  not all potential solutions to problem a will also have to solve problem b. 

Currently the charter is focused on problem b.  If the real goal is to solve problem a, then this charter is not very helpful.

---

From: "Mohammad Al-Taraireh (maltarai)" <[email-masked]>
Date: Mon, 12 Jul 2010 09:18:53 -0500

In the current model you can not prevent anyone from falsely claiming
the "ownership" of a specific number, however, that does not mean the
validation will happen just because someone claim ownership, the
validation process to learn a specific route is dependant on the PSTN
call that must take place to that number before the validation even is
triggered. 
 
I can not remember why the protocol suggested to publish the +E.164
representation in the DHT before hand, versus publish in the DHT the VCR
record (hash value of the (E.164+startTime+StopTime with some delta of
time to allow of some error margin in timing sync) of the pstn call.
This way validation will only happen to the node in the DHT that claim
knowledge of the pstn call. 
 
Mo A

From: Richard Shockey [mailto:[email-masked]] 
Sent: Monday, July 12, 2010 9:35 AM
To: Mohammad Al-Taraireh (maltarai); 'Bernard Aboba'; [email-masked]
Subject: RE: [dispatch] VIPR - proposed charter version 3

Well again given these facts and several others the charter has to be
substantially rewritten for it to stand a reasonable chance of approval.
Though the exception cases will make for interesting reading in the
security considerations, should the discussion go that far.

Well I'll love to see how you will prevent someone from falsely
asserting "ownership" of +1 202 456 1414 or what would happen if some
did.

Behalf Of Mohammad Al-Taraireh (maltarai)

Thanks,

Mo A

Bernard, 

Mo A

Jonathan said:

---

From: "Mohammad Al-Taraireh (maltarai)" <[email-masked]>
Date: Mon, 12 Jul 2010 10:34:42 -0500

Please see inline:

From: Bernard Aboba [mailto:[email-masked]] 
Sent: Monday, July 12, 2010 10:10 AM
To: [email-masked]; Mohammad Al-Taraireh (maltarai);
[email-masked]
Subject: VIPR - proposed charter version 4

a. One problem is the need to be able to "upgrade" an audio call in
progress in order to provide for additional media, even if the call had
been completed over the PSTN so that there was no SDP offer/answer
negotiation between the end-points.  This is the problem that Facetime
solves, for example.  
 
Mo A>> The only way I see this issue related to ViPR, is to have a
capability in the validation protocol to allow learning the route to
happen fast enough during an active call, to allow the escalation to
other media types. I don't think the protocol as it is today preclude
this from working this way. It is up to the SIP UA to be able to use the
learn route during the active session to a specific DID to change the
media type, and the session. This is of course already supported in SIP,
and SDP. 
 
In fact we will need something standardized like "ViPR" to get Facetime
like functionality to work with for none vender specific
devices/implementation. 

In the process of solving problem a, we might also need to solve problem
b, but that depends on the approach that is taken;  not all potential
solutions to problem a will also have to solve problem b.  
 
Mo>> As the charter written today, ViPR is not intended to replace ENUM.
It surely can work without it, but can also work if ENUM is in use
(numbers that are not in ENUM, can use ViPR). 
 
MoA 

Currently the charter is focused on problem b.  If the real goal is to
solve problem a, then this charter is not very helpful.

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 12 Jul 2010 12:03:33 -0400

In line as well.

a. One problem is the need to be able to "upgrade" an audio call in progress
in order to provide for additional media, even if the call had been
completed over the PSTN so that there was no SDP offer/answer negotiation
between the end-points.  This is the problem that Facetime solves, for
example.  

Mo A>> The only way I see this issue related to ViPR, is to have a
capability in the validation protocol to allow learning the route to happen
fast enough during an active call, to allow the escalation to other media
types. I don't think the protocol as it is today preclude this from working
this way. It is up to the SIP UA to be able to use the learn route during
the active session to a specific DID to change the media type, and the
session. This is of course already supported in SIP, and SDP. 

In fact we will need something standardized like "ViPR" to get Facetime like
functionality to work with for none vender specific devices/implementation. 

In the process of solving problem a, we might also need to solve problem b,
but that depends on the approach that is taken;  not all potential solutions
to problem a will also have to solve problem b.  

Mo>> As the charter written today, ViPR is not intended to replace ENUM. It
surely can work without it, but can also work if ENUM is in use (numbers
that are not in ENUM, can use ViPR). 

RS> Lets just make it clear that if you are talking about "public" ENUM aka
the RFC 3761 in the e164.arpa tree you are not replacing anything since it
functionally does not exist except in a very few countries. However ENUM
does work quite well and has substantial deployments where the centralized
or distributed private DNS trees are controlled by the service providers who
ARE in a position to validate and authenticate the TN's under their control.

Of course it would be useful to admit the subtext of this entire discussion
is enabling PSTN service provider bypass.   A more useful WG name for this
activity would be "bypass" or 'X-TPC"  for "The Phone Company"  and have Mr.
Arlington Hewes as honorary co-chair.

---

From: "Mohammad Al-Taraireh (maltarai)" <[email-masked]>
Date: Mon, 12 Jul 2010 11:32:04 -0500

The genuine intent behind ViPR is not  to bypass the Service Providers,
In my opinion the Service Providers have vested interest in this as
well, and can leverage ViPR to work for them (front end numbers they own
with ViPR) to offer enhanced services. 
 
My .2 c :-). 
 
Thanks,
 
Mo A

From: Richard Shockey [mailto:[email-masked]] 
Sent: Monday, July 12, 2010 12:04 PM
To: Mohammad Al-Taraireh (maltarai); 'Bernard Aboba'; [email-masked]
Subject: RE: VIPR - proposed charter version 4

In line as well.

 

RS> Lets just make it clear that if you are talking about "public" ENUM
aka the RFC 3761 in the e164.arpa tree you are not replacing anything
since it functionally does not exist except in a very few countries.
However ENUM does work quite well and has substantial deployments where
the centralized or distributed private DNS trees are controlled by the
service providers who ARE in a position to validate and authenticate the
TN's under their control.  

Of course it would be useful to admit the subtext of this entire
discussion is enabling PSTN service provider bypass.   A more useful WG
name for this activity would be "bypass" or 'X-TPC"  for "The Phone
Company"  and have Mr. Arlington Hewes as honorary co-chair.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 12 Jul 2010 09:57:58 -0700

>In fact we will need something standardized like "ViPR"
to get Facetime like functionality to work with for non-vendor
>specific devices/implementation. 

That's what I'm not clear about.  As I understand it, Facetime does not utilize an E.164 to email-style URI translation mechanism anything like VIPR -- and as a result, the scaling characteristics are quite different. 
>Of course it would be useful to admit the
subtext of this entire discussion is enabling PSTN service provider bypass.   A
more useful WG >name for this activity would be “bypass” or ‘X-TPC” 
for “The Phone Company”  and have Mr. Arlington Hewes as honorary
co-chair.I agree with you that there is a subtext here, and that it's important to understand what it is.  However, I'm not sure that this subtext is actually "toll bypass". 

My understanding is that VIPR was not created to solve the toll bypass problem, but rather in order enable the completion of a video call over IP when the endpoint identifier is an E.164 number.   That is not really the same as "toll bypass".

---

From: stephen botzko <[email-masked]>
Date: Mon, 12 Jul 2010 13:01:52 -0400

My understanding is that VIPR was not created to solve the toll bypass
problem, but rather in order enable the completion of a video call over IP
when the endpoint identifier is an E.164 number.
That would be a very useful thing!

Stephen Botzko

On Mon, Jul 12, 2010 at 12:57 PM, Bernard Aboba
<[email-masked]>wrote:

> like functionality to work with for non-vendor
> That's what I'm not clear about.  As I understand it, Facetime does not
> utilize an E.164 to email-style URI translation mechanism anything like VIPR
> -- and as a result, the scaling characteristics are quite different.
> >name for this activity would be “bypass” or ‘X-TPC”  for “The Phone
> Company”  and have Mr. Arlington Hewes as honorary co-chair.
> I agree with you that there is a subtext here, and that it's important to
> understand what it is.  However, I'm not sure that this subtext is actually
> "toll bypass".
>
> My understanding is that VIPR was not created to solve the toll bypass
> problem, but rather in order enable the completion of a video call over IP
> when the endpoint identifier is an E.164 number.   That is not really the
> same as "toll bypass".
>
>
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>
>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 12 Jul 2010 10:11:07 -0700

Indeed, that would be a very useful thing -- but unfortunately, that is not what this charter is focused on!

Date: Mon, 12 Jul 2010 13:01:52 -0400
Subject: Re: [dispatch] VIPR - proposed charter version 4
From: [email-masked]
To: [email-masked]
CC: [email-masked]; [email-masked]; [email-masked]

   My understanding is that VIPR was not created to solve the toll bypass 
problem, but rather in order enable the completion of a video call over 
IP when the endpoint identifier is an E.164 number.

Stephen Botzko

 

dispatch mailing list

[email-masked]

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 12 Jul 2010 13:19:00 -0400

You points are at the center of what is the problem with the existing
charter. Lack of clarity. Which is why it is still "challenging" in its
current form.

All proposed IETF charters need to state clearly,  "This is the problem we
(the proposed WG)  are trying to solve" and that problem needs to be
narrowly scoped.

VIPR IMHO, as the ID's currently read, looks like toll bypass pure and
simple. 

If, as you wisely point out the actual technical goal, is establishment of a
communication session where the endpoint is a E.164 number WITHOUT the
intervention of centralized carrier controlled/public databases (Carrier vs
Public ENUM) then it is clear its closer to a FaceTime interface. 

Either way still session establishment without the intervention of the
service provider controlling the underlying E.164 namespace.

From: Bernard Aboba [mailto:[email-masked]] 
Sent: Monday, July 12, 2010 12:58 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: VIPR - proposed charter version 4

>In fact we will need something standardized like "ViPR" to get Facetime
like functionality to work with for non-vendor >specific
devices/implementation. 

>Of course it would be useful to admit the subtext of this entire discussion
is enabling PSTN service provider bypass.   A more useful WG >name for this
activity would be "bypass" or 'X-TPC"  for "The Phone Company"  and have Mr.
Arlington Hewes as honorary co-chair.

---

From: "Mohammad Al-Taraireh (maltarai)" <[email-masked]>
Date: Mon, 12 Jul 2010 12:18:35 -0500

At the end of the day ViPR will unlock all the features potential that
the communicating devices can support, and limited by the PSTN today,
Video, wideband codec support, VCard, Callback, ... the list goes on.
ViPR is really just a framework to get you the correct mapping between
the a number that you already dialed over the PSTN to a SIP route that
is globally reachable. 

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Bernard Aboba
Sent: Monday, July 12, 2010 1:11 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dispatch] VIPR - proposed charter version 4

Indeed, that would be a very useful thing -- but unfortunately, that is
not what this charter is focused on!

   My understanding is that VIPR was not created to solve the toll
bypass problem, but rather in order enable the completion of a video
call over IP when the endpoint identifier is an E.164 number.

Stephen Botzko

On Mon, Jul 12, 2010 at 12:57 PM, Bernard Aboba
<[email-masked]> wrote:

	>In fact we will need something standardized like "ViPR" to get
Facetime like functionality to work with for non-vendor >specific
devices/implementation. 
	
	That's what I'm not clear about.  As I understand it, Facetime
does not utilize an E.164 to email-style URI translation mechanism
anything like VIPR -- and as a result, the scaling characteristics are
quite different. 

	>Of course it would be useful to admit the subtext of this
entire discussion is enabling PSTN service provider bypass.   A more
useful WG >name for this activity would be "bypass" or 'X-TPC"  for "The
Phone Company"  and have Mr. Arlington Hewes as honorary co-chair.

	I agree with you that there is a subtext here, and that it's
important to understand what it is.  However, I'm not sure that this
subtext is actually "toll bypass". 
	
	My understanding is that VIPR was not created to solve the toll
bypass problem, but rather in order enable the completion of a video
call over IP when the endpoint identifier is an E.164 number.   That is
not really the same as "toll bypass".

---

From: "Mohammad Al-Taraireh (maltarai)" <[email-masked]>
Date: Mon, 12 Jul 2010 12:59:35 -0500

Point well taken, I am not sure who is responsible of updating the
charter, but may be we can help clarify some of the ambiguity, and
narrow the scope. 
 
Mo A

From: Richard Shockey [mailto:[email-masked]] 
Sent: Monday, July 12, 2010 1:19 PM
To: 'Bernard Aboba'; Mohammad Al-Taraireh (maltarai); [email-masked]
Subject: RE: VIPR - proposed charter version 4

All proposed IETF charters need to state clearly,  "This is the problem
we (the proposed WG)  are trying to solve" and that problem needs to be
narrowly scoped.

If, as you wisely point out the actual technical goal, is establishment
of a communication session where the endpoint is a E.164 number WITHOUT
the intervention of centralized carrier controlled/public databases
(Carrier vs Public ENUM) then it is clear its closer to a FaceTime
interface. 

 

That's what I'm not clear about.  As I understand it, Facetime does not
utilize an E.164 to email-style URI translation mechanism anything like
VIPR -- and as a result, the scaling characteristics are quite
different. 

I agree with you that there is a subtext here, and that it's important
to understand what it is.  However, I'm not sure that this subtext is
actually "toll bypass". 

My understanding is that VIPR was not created to solve the toll bypass
problem, but rather in order enable the completion of a video call over
IP when the endpoint identifier is an E.164 number.   That is not really
the same as "toll bypass".

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 12 Jul 2010 14:53:55 -0400

Well not to be too argumentative. J  but I suggest that SIP has a number of
things to overcome before nirvana is achieved. 

First you may be looking at this from a enterprise perspective but the SIP
CUA Configuration issues need to be solved first. You still cant go to Best
Buy or Dixons or any consumer electronics store and buy a SIP device that
can easily plugged in and configured to a service provider network or a PBX
or that matter. (below)  I submit that its consumers that have been driving
this round of technology adoption. 

That is what the SIP Forum was focusing on with the UA Config profile but
there is still no common data model to support the specification
irrespective of what domain is used to connect to the service provider.

The features you describe could easily be supported by private centralized
databases managed in carrier networks if, if and that is a very big if, the
service providers could finally agree on the business model and structure of
those databases. I doubt ViPR would work there either. Carrier CDB's  are
already in use for certain applications such as MMS and all IP SMS routing
in North America and could easily be extended to any URI or G-SPN identifier
for any defined application.  The GSM-A has already defined how that might
look for all GSM operators.

The problem is not technical its political.   Trust me on that.. J 

This draft proposes a modification to

draft-lawrence-dispatch-sipforum-provider-alias (PAN).  The PAN draft
proposes a mechanism for a phone to take a short numeric identifier that
identifies a phone service provider and look it up in DNS to find the
address of the configuration server for that service provider.

The problem with PAN is that it requires a specific organization,
sipforum.org, to become a registrar for the PAN.  This will add signifiant
cost to obtaining them as the expected quantity of PAN is low.  This draft
proposes a minor modification to the PAN draft.

Instead of using the sipforum as a new registrar, why not just use the
registrars that already exist for DNS names.  This ensure a long term stable
unique allocation of PAN with the advantages of not having the IETF
allocating a monopoly to one particular organization.

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-jennings-dispatch-npa-00.txt

To: Bernard Aboba; [email-masked]

At the end of the day ViPR will unlock all the features potential that the
communicating devices can support, and limited by the PSTN today, Video,
wideband codec support, VCard, Callback, ... the list goes on. ViPR is
really just a framework to get you the correct mapping between the a number
that you already dialed over the PSTN to a SIP route that is globally
reachable. 

  _____  

Indeed, that would be a very useful thing -- but unfortunately, that is not
what this charter is focused on!

  _____  

Stephen Botzko

---

From: "Mohammad Al-Taraireh (maltarai)" <[email-masked]>
Date: Mon, 12 Jul 2010 18:18:05 -0500

Please see  inline:

From: Richard Shockey [mailto:[email-masked]] 
Sent: Monday, July 12, 2010 2:54 PM
To: Mohammad Al-Taraireh (maltarai); 'Bernard Aboba';
[email-masked]
Cc: [email-masked]
Subject: RE: [dispatch] VIPR - proposed charter version 4

Well not to be too argumentative. J  but I suggest that SIP has a number
of things to overcome before nirvana is achieved.  

Mo>> No argument there :-) 

First you may be looking at this from a enterprise perspective but the
SIP CUA Configuration issues need to be solved first. You still cant go
to Best Buy or Dixons or any consumer electronics store and buy a SIP
device that can easily plugged in and configured to a service provider
network or a PBX or that matter. (below)  I submit that its consumers
that have been driving this round of technology adoption.  

Mo>> Vonage (may be not the best example)  has something that you can
pick up from Wal-Mart, connect to your internet, and you have service.
So I can see devices that support ViPR fall in that category at some
point.  

That is what the SIP Forum was focusing on with the UA Config profile
but there is still no common data model to support the specification
irrespective of what domain is used to connect to the service provider. 

Mo>> That is one of the advantages of ViPR model, you only need to care
on how to configure your system nothing else. It is dynamic, no one need
to know how the other devices are configured.  

The features you describe could easily be supported by private
centralized databases managed in carrier networks if, if and that is a
very big if, the service providers could finally agree on the business
model and structure of those databases. I doubt ViPR would work there
either. Carrier CDB's  are already in use for certain applications such
as MMS and all IP SMS routing in North America and could easily be
extended to any URI or G-SPN identifier for any defined application.
The GSM-A has already defined how that might look for all GSM operators.

Mo>> And that is another problem that ViPR solves, if the SP don't want
to play, the end users (enterprises, small pbx, or end devices) can
still use it, without the need to manage a centralized DB. 

Mo>> :-) no comment on the above.  

The problem with PAN is that it requires a specific organization,
sipforum.org, to become a registrar for the PAN.  This will add
signifiant cost to obtaining them as the expected quantity of PAN is
low.  This draft proposes a minor modification to the PAN draft.

Instead of using the sipforum as a new registrar, why not just use the
registrars that already exist for DNS names.  This ensure a long term
stable unique allocation of PAN with the advantages of not having the
IETF allocating a monopoly to one particular organization.

Mo>> I am yet to read this above, but again this seems to involve yet
another managed DB with some specific mapping. 

Thanks,

Mo A 

 

Stephen Botzko

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 18 Jul 2010 08:50:18 -0700

Bernard, obviously a large percentage of the work done in RAI is to allow rich communications over the internet and for the most part the existing work today from AVT, MMUSIC, SIP and so on already solves your point (a) below. However one of the hard problems is how to go from an phone number to an internet address. This WG is focused on that problem. 

Yes, one of the benefits of this is that when combined with other large parts of RAI work, it would help solve (a) but it's also useful for thing other than adding video to a PSTN call.  Superficially, the final information delivered by VIPR  is very similar to the information public  ENUM provides. They both go from a phone number to internet address. They both can be used by many protocols including SIP but there's nothing about just doing upgrade from voice to video - that is basically an consequence of SIP running over the internet, not something that VIPR does. However EBUM and VIPR are very different with regards to the the source of information provided, the implementation complexity, and the incentives for deployment. I can easily imagine a PBX that first did a dip in some private ENUM, then public ENUM presuming it called a country with some support for public ENUM, then if nothing had be found, to VIPR before falling back to route a call over the PSTN. So in this regards it is hardly a replacement for ENUM. 

> a. One problem is the need to be able to "upgrade" an audio call in progress in order to provide for additional media, even if the call had been completed over the PSTN so that there was no SDP off…

Irrelevant side point but, Really? I was under the impression that if Facetime started a call over the PSTN it would not upgrade it to video. 

> Currently the charter is focused on problem b.  If the real goal is to solve problem a, then this charter is not very helpful.

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Adam Roach <[email-masked]>
Date: Sun, 18 Jul 2010 11:07:13 -0500

On 7/18/10 10:50, Jul 18, Cullen Jennings wrote:
>> One problem is the need to be able to "upgrade" an audio call in progress in order to provide for additional media, even if the call had been completed over the PSTN so that there was no SDP offer/answer negotiation between the end-points.  This is the problem that Facetime solves, for example.
> Irrelevant side point but, Really?

Yes, really.

/a

---

From: "Richard Shockey" <[email-masked]>
Date: Sun, 18 Jul 2010 14:11:32 -0400

Yes, absolutely positively unquestionably. 

The FaceTime mechanism is rather clever and is certainly one way to solve
the real problem of the E.164 trust binding in session (re)establishment. If
you can make a PSTN call .. its works. From the user experience perspective
(Apples obsession) its nearly flawless. Apple did a very nice job.  If Steve
and company finally decide to publish what they have done they will have a
lot of friends.

For my 547th rant. People want to use phone numbers. 

SIP addressing, for better or worse, is now and forever will be bound in
large measure to phone numbers and phone numbers and the PSTN are controlled
by service providers.  I wish RAI would take a longer look at E164
integration both from the prospective of the end user as ViPR does but also
the needs of the service providers. The common goal here is accelerating the
deployment of SIP.

Both are logical approaches, but it doesn't help when a simple proposal such
as E2MD to extend ENUM databases in public and private networks for simple
metadata runs into a stone wall of resistance. Its why there is a strong
political odor here. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adam Roach
Sent: Sunday, July 18, 2010 12:07 PM
To: Cullen Jennings
Cc: Bernard Aboba; [email-masked]
Subject: Re: [dispatch] VIPR - proposed charter version 4

  On 7/18/10 10:50, Jul 18, Cullen Jennings wrote:
>> One problem is the need to be able to "upgrade" an audio call in progress

Yes, really.

/a

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 18 Jul 2010 13:23:52 -0700

> a. One problem is the need to be able to "upgrade" an audio call in progress in order to provide for additional media, even if the call had been completed 
> over the PSTN so that there was no SDP offer/answer negotiation between the end-points.  This is the problem that Facetime solves, for example. 
 
Cullen Jennings said:

"Bernard, obviously a large percentage of the work done in RAI is to allow rich communications over the internet and for the most part the existing work today from AVT, MMUSIC, SIP and so on already solves your point (a)"

[BA] Problem a)  was about upgrading of calls made over the PSTN, not the Internet.  Are you suggesting that SIP, SDP, etc. already provides a standardized way to do *that*?

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 18 Jul 2010 13:35:47 -0700

Richard Shockey said:
"For my 547th rant. People want to use phone numbers."

[BA] There are devices out there for which input of an email-style URI is
difficult or impossible.  Is the goal to:

c. Enable individuals with those devices to reach someone with an email-style
URI, while only inputting only numbers?  

d. Enable individuals with those devices to reach someone who has an E.164
number? 

Problems c) and d) are not the same.  For example, while problem d) may
require translation of an E.164 number to an email-style URI, in problem
c) we don't assume that the target endpoint is described with an E.164
number, just some set of numbers, so that a wider array of solutions 
may be available, some of which do not require translation.

---

From: Adam Roach <[email-masked]>
Date: Sun, 18 Jul 2010 16:28:03 -0500

> and company finally decide to publish what they have done they will have a

Well, details are a bit sketchy, but preliminary analysis is that the 
whole system holds together only because Apple has things set up so that 
they retain an iron-gripped control over everything.

Effectively, it would be like saying "the SIP E.164 number mapping 
problem has been solved! Just slap "@apple.com" after any E.164 number 
in the world, and you can be sure you're reaching the right person!"

As far as I can tell, the binding from a phone number to a client cert 
(yes, they use mTLS for auth) is performed via some kind of SMS exchange 
(as users must have SMS service the first time they use FaceTime, but 
not for subsequent calls). My guess is that the phone sends a client 
cert fingerprint to Apple, and then Apple trusts that the cert indicated 
is 100% certain to correspond to the phone number that the SMS appears 
to have come from.

I agree that it's clever, but it doesn't work unless it's all under the 
tight control of a single entity. It also is completely dependent on 
being able to send an SMS from the associated E.164 number (which limits 
it to mobile phones).

/a

---

From: Adam Roach <[email-masked]>
Date: Sun, 18 Jul 2010 17:06:59 -0500

> For my 547th rant. People want to use phone numbers.

I forgot to mention -- if you're insisting on this as a maxim, then 
FaceTime might not be your best poster boy.

http://www.boygeniusreport.com/2010/07/15/exclusive-apples-facetime-coming-to-ipod-touch-ipad-we-detail-how/

Phone numbers are useful to get to & from the PSTN.

But, aside from that, they're a disposable relic in today's gadgets. I 
mean, really -- when is the last time you mashed 10 (or more) digits 
into your phone instead of selecting someone's name out of an address 
book? Why would you care what the identifier behind that address book 
entry looks like?

There came a time where calling the operator and asking for "Dallas, 
Diamond Exchange, 3-6-5-5-2" became a bit quaint. And then it stopped 
working. You really think we'll never bridge the gap away from phone 
numbers?

/a

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 18 Jul 2010 15:23:05 -0700

Adam Roach said:

" As far as I can tell, the binding from a phone number to a client cert
(yes, 
they use mTLS for auth) is performed via some kind of SMS exchange (as users

must have SMS service the first time they use FaceTime, but not for
subsequent 
calls).   My guess is that the phone sends a client cert fingerprint to
Apple, 
and then Apple trusts that the cert indicated is 100% certain to correspond 
to the phone number that the SMS appears to have come from."

[BA] If we can assume the existence of an in-band channel for initial
communication between the endpoints (whether that in-band channel is
the PSTN, SMS, etc.) as well as a public/private key pair used to 
identify the end-point, then a number of mechanisms may be available 
to bind the endpoint identifiers to the public/private key pair.  For
example, the IETF has already developed techniques for demonstration
of ownership of parameter resources (e.g. RFC 3971).

---

From: Marc Linsner <[email-masked]>
Date: Mon, 19 Jul 2010 08:37:49 -0400

Richard,

> For my 547th rant. People want to use phone numbers.

[ML] My observation is this is a generational issue, it'll solve itself in
due time.  :^)

> by service providers.

[ML] From an end-user perspective, I believe that as long as I pay *any* SP
a monthly fee, the E.164 address belongs to me, in the US I can move it
amongst SPs as I see fit.  For this fee, I am allowed to assert that I own
such address and I can advertise that I own it in any medium I want
including yellow pages, business cards, newsprint, Internet, etc.

It appears to me that Vipr is simply another medium where I advertise that I
own such E.164 address.

-Marc-

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Mon, 19 Jul 2010 08:50:42 -0400

Marc:
I don't think the concern is about the number assignee advertising the
number, but about being sure that *only* the number assignee, carrier of
record, or other authorized party is advertising the number.

Penn Pfautz
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Marc Linsner
Sent: Monday, July 19, 2010 8:38 AM
To: Richard Shockey
Cc: [email-masked]
Subject: Re: [dispatch] VIPR - proposed charter version 4

Richard,

> For my 547th rant. People want to use phone numbers.

[ML] My observation is this is a generational issue, it'll solve itself
in
due time.  :^)

> large measure to phone numbers and phone numbers and the PSTN are
controlled

[ML] From an end-user perspective, I believe that as long as I pay *any*
SP
a monthly fee, the E.164 address belongs to me, in the US I can move it
amongst SPs as I see fit.  For this fee, I am allowed to assert that I
own
such address and I can advertise that I own it in any medium I want
including yellow pages, business cards, newsprint, Internet, etc.

It appears to me that Vipr is simply another medium where I advertise
that I
own such E.164 address.

-Marc-

---

From: Marc Linsner <[email-masked]>
Date: Mon, 19 Jul 2010 09:27:31 -0400

Penn,

My interpretation (which stands a good chance of being wrong) of Vipr is
that it's designed as an 'end-user' (lessee of the E.164) assertion
mechanism, not designed for 'carrier of record' (PSTN SP) assertion.

The vulnerabilities of the authentication mechanism will obviously need
vetted in a work group setting.

-Marc-

---

From: "Mohammad Al-Taraireh (maltarai)" <[email-masked]>
Date: Mon, 19 Jul 2010 08:42:24 -0500

ViPR already suggests at least one method of making that assertion,
again this is not written in stone, and can be changed if there are
better alternatives. 

Putting all motivations aside for a moment, businesses, and people will
continue to use E.164 number for a long time to come, and we will need
something to bride the feature disparity between these to islands of
communications. 

The current drafts are the first cut at something that is huge, and I am
sure there will be many enhancements to make things like switching from
an active PSTN call to an Internet SIP call is a matter of SIP route
availability and reachability, after the route is learned. 

Mo A

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Marc Linsner (mlinsner)
Sent: Monday, July 19, 2010 9:28 AM
To: PFAUTZ, PENN L (ATTCORP)
Cc: [email-masked]
Subject: Re: [dispatch] VIPR - proposed charter version 4

Penn,

-Marc-

> number, but about being sure that *only* the number assignee, carrier 
> of record, or other authorized party is advertising the number.
> 
> Penn Pfautz
> [ML] My observation is this is a generational issue, it'll solve 
> itself in due time.  :^)
> 
>> 
> [ML] From an end-user perspective, I believe that as long as I pay 
> *any* SP a monthly fee, the E.164 address belongs to me, in the US I 
> can move it amongst SPs as I see fit.  For this fee, I am allowed to 
> assert that I own such address and I can advertise that I own it in 
> any medium I want including yellow pages, business cards, newsprint, 
> Internet, etc.
> 
> that I own such E.164 address.
> 
> -Marc-
> 
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 19 Jul 2010 13:57:56 -0400

Adam,

The issue isn't that people type in phone numbers in a dialpad to make 
calls. No one does that anymore. The issue is that phone numbers are now 
embedded into the millions (billions?) of address book entries in phones 
of various sorts. They appear on business cards, and in email 
signatures, and so on.

As such, enabling voip to drive off of phone numbers can substantially 
reduce the friction for getting to voip. Facetime is just another 
example of that same concept.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   SkypeID: jdrosen
Chief Technology Strategist                    Mobile: +1 (732) 766-2496
Skype                                          SkypeIn: +1 (408) 465-0361
[email-masked]                              http://www.skype.com
[email-masked]                            http://www.jdrosen.net

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 19 Jul 2010 14:01:11 -0400

Adam touches on a couple of points that are important about how vipr 
differs from Facetime. Both of them seek to drive voip off of phone 
numbers, however:

1. ViPR assumes a fully distributed solution, where there is no central 
authority for mapping numbers to domains

2. ViPR works with any endpoints that can make and receive PSTN calls, 
not just devices which can send and receive SMS

If you remove both of these constraints, much simpler solutions are 
possible.

-Jonathan R.

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 19 Jul 2010 16:27:28 -0400

<RS> Yea right. I've heard this argument for the last 10 years around the
IETF and I'm sure I'll hear it for at least another 10. 

<RS> well no actually ..first E.164 numbers are not property and never have
been and by international treaty they cannot be "owned" as such. Plus if you
move out of a designated rate center in the US and in most jurisdictions
your rights to a number vanish in the case of land lines and in mobile if
you move and then change a carrier. In the US 7% of the population moves out
of a designated rate center every year. 

<RS> You "own" nothing and if you don't like it there is a little building
in DC called the Portals that you can send a petition to.  :-) 

-Marc-

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 19 Jul 2010 16:44:11 -0400

book? 

<RS> Yesterday as a matter of fact when I wanted to try a new pizza delivery
shop and the day before yesterday when I wanted to schedule an appointment
for a bid on some house painting. 

Why would you care what the identifier behind that address book 
entry looks like?

<RS> If empirical evidence is any guide, not in my lifetime. :-) Phone
numbers are useful, easy to remember, linguistically neutral ( a big plus )
and have a internationally sanctioned trust system surrounding them that has
worked for almost a century. And the growth in mobile phones numbers is
pretty explosive in developing countries.  We all hate fax too but that is
not going away anytime soon either, contrary to the desire of most of the
RAI community.

Sure I don't manually dial a pad every time but certainly the first time
when I enter the number. And since there are studies that most of us never
call more than 25 people regularly that would support your thesis somewhat.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Jul 2010 16:50:55 -0400

> IETF and I'm sure I'll hear it for at least another 10. 

You will hear it until *your* generation retires. :-)

	Paul

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 19 Jul 2010 16:59:35 -0400

I'll grant that E.164 numbering has a widely-accepted trust system  
(although, if you didn't trust it, what alternative do you have?), but  
seems kind of irrelevant to the question at hand, namely, how to route  
SIP calls to the proper destination for an E.164 number.  Clearly, the  
entities comprising that system haven't taken up the idea directly, as  
witnessed, e.g., by the failure of ENUM.

Since those entities aren't collectively solving the problem (AFAIK),  
there's a need for an "out-of-band" solution.  Which would seem to be  
the point of VIPR -- to use this thing that is already trusted to  
discover destinations for PSTN calls to also discover destinations for  
IP calls?  (Without relying on support from the internals of the  
system itself.)

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 19 Jul 2010 19:21:19 -0400

Well since you want to keep the thread alive. :-) 

ENUM in e164.arpa has had its "challenges" for sure but to say RFC 3761 is a
failure is simply not correct. As a number translation mechanism to replace
SS7/TCAP in closed carrier IP SIP networks it works extremely well and is
globally deployed. You just can't directly access those databases. That is
your problem.

You say ENUM is a failure, well email style SIP addressing for consumers or
businesses is a total failure and no one in RAI will admit to that. SIP
addressing is only relevant to internal SSP operations or PBX systems. The
consumer doesn't know or care they phone numbers are still on 100% of
business cards.  

Carriers, for some strange reason, do not like being bit pushers and are
justifiably concerned about their major cash cow, voice/SMS using e164
addressing. So the problem here is everyone hates the PSTN and E.164
addressing but you propose to use exactly those mechanisms to facilitate
toll bypass. Fine. I just want that understood. I'm a firm believer is
"truth in WG charters". 

The economics of toll bypass is a business model issue which is not our
collective concern but it needs to be clearly stated that this is the
central proposition of this proposed WG as you propose it. 

I certainly agree that our global service provider friends have not been as
responsive as they could be to new service delivery using E.164 addressing
and I'm not going to even attempt to justify their behavior, though I will
certainly grant they have had issues with CAPEX in recent years that has
made it difficult to justify replacement of the outdated signaling
mechanisms in their networks.

I have never doubted for a moment that this WG will probably get chartered
in some form or another. In fact I hope it does if for no other reason that
perhaps our carrier friends will finally get off their collective posteriors
and finally confront the reality that if they want to avoid being bit
pushers they need to finally confront the underlying need for both new
service delivery using E.164 addressing (FaceTime ?) and a reliable and
truly trusted global number translation mechanism internal to their networks
..and that BTW won't be VIPR.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 19 Jul 2010 20:02:17 -0700

> [BA] Problem a)  was about upgrading of calls made over the PSTN, not the Internet.  Are you suggesting that SIP, SDP, etc. already provides a standardized way to do *that*? 

sorry - I did not mean to claim that - I imagine we both agree there is not a standardized way to upgrade a PSTN call to an internet call

Cullen Jennings

---

From: Adam Roach <[email-masked]>
Date: Tue, 20 Jul 2010 09:54:23 -0500

On 7/19/10 12:57, Jul 19, Jonathan Rosenberg wrote:
> calls. No one does that anymore. The issue is that phone numbers are 
> now embedded into the millions (billions?) of address book entries in 
> phones of various sorts. They appear on business cards, and in email 
> signatures, and so on.
>
> reduce the friction for getting to voip.

These arguments can be applied just as easily to email: if we could 
simply bind your phone number to your email address, then there's no 
need to put an email address on your business card, in your address 
book, etc.

Email appears to have done just fine without that binding.

The same goes for web sites. Think back to 1996. Wouldn't it have been 
cool to just type the phone number for Pizza Hut into your URL bar to 
get to their web site, instead of trying to figure out whether it's 
"www.pizzahut.com" or "www.pizza-hut.com" or "www.yum.com"?

Ah, yes. Thanks for reminding me. The other point I wanted to make is 
that most of these examples -- like signature blocks and phone book 
entries -- can be changed easily and for free.

/a

---

From: "Mohammad Al-Taraireh (maltarai)" <[email-masked]>
Date: Tue, 20 Jul 2010 10:05:24 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adam Roach
Sent: Tuesday, July 20, 2010 10:54 AM
To: Jonathan Rosenberg
Cc: 'Bernard Aboba'; [email-masked]
Subject: Re: [dispatch] VIPR - proposed charter version 4

Mo>> Not exactly, I think you are missing the intent. When I dial a
number most likely I want to talk to someone or leave a message, when I
send an email or go to webpage my intent is not to talk to anyone. The
intent behind SIP URIs, and phone numbers is in a high number of cases
is to get connected.

Mo

/a