Subject: Re: [Sip] IETF solution for pairing cellular hosts

From: "Pars Mutaf" <[email-masked]>
Date: Fri, 5 Oct 2007 14:43:14 +0200

On 9/28/07, Pars Mutaf <[email-masked]> wrote:
>
> Hello,
>
> Thanx for the message, I hope you and (other SIP experts)
> subscribe to the ML:
>
> https://www1.ietf.org/mailman/listinfo/humanresolvers
>
> Personally, I'm not sure if we need a store/forward
> solution. We probably don't want to store a pairing
> request message while the user is off-line. Because
> the request message itself can be used for SPAM.
>
> Maybe a real-time solution is preferable. I.e., if
> the target user is off-line we don't care. The querier
> needs to try later to get the user's consent.
>
> Personally, I'm also against a SIP-based solution.
> This is my personal opinion and of course open to
> discussion.

Hello,
I'll feel more comfortable if I explain the above statement
to SIP folks. I'm not defending any particular design, I'm trying
to start some discussion and get more people to the list,
and hoping to find the right choices together.

For example there is also a serverless design possibility
(for local use only) which also deserves attention IMHO,
because of the obvious advantages of a serverless design:

-I have a new phone, I want to pair it with that of a friend.
-I type his name.
-My phone issues a local multicast DNS query to his name
over WiFi or WiMax.
-Using multicast DNS my phone scans his name.
-His phone returns an IP address (possibly a local/temporary one)
and perhaps other info helping me deal with name collisions.
-We use the proposed pairing protocol for exchanging our
SIP URIs, fixed MIPv6 home addresses, create an IPsec SA etc.

This is also another obvious design with pros and cons IMHO.

Thanks,
pars

I really hope we can talk about these issues.
>
> Thanks,
> pars
>
> On 9/28/07, Dean Willis <[email-masked]> wrote:
> >
> >
> > On Sep 27, 2007, at 4:38 PM, [email-masked] wrote:
> >
> > >    From: "Pars Mutaf" <[email-masked]>
> > >
> > >    The following is a new abstract solution, a third alternative, a
> > > protocol
> > >    for "pairing" two cellular hosts:
> > >
> > >    Model of operation
> > >
> > >    1. The querier user types the target user's "human name" (as if
> > > he were
> > >       consulting a phonebook), or a pseudoynm.
> > >    2. The pairing request is forwarded to the target phone.
> > >    3. The query, along with the querier user's name, are displayed
> > > on the
> > >       target phone's screen.
> > >    4. The target user approves the request in real-time by pushing
> > > on the YES
> > >       button of the phone.
> > >    5. The two phones exchange their Mobile IPv6 home addresses, SIP
> > > URIs, and
> > >       establish an IPsec security association (using IKEv2).
> > >
> > > How do you make this work?  Step 2 seems to require that you have
> > > already located the target phone, whereas the protocol's *purpose* is
> > > to locate the target phone.
> > >
> >
> >
> > One possibility is that the directory service is operating on behalf
> > of the target, not the searcher. As such, the directory service is
> > trusted to know the display name to userID binding. When it receives
> > a query, the directory service uses the target's SIP contact
> > registration to send a consent request to the target user. If the
> > target user response positively, then the directory service returns
> > the directory's query result to the searcher.
> >
> > Basically, another layer of indirection (directory) in front of a
> > watcher pattern.
> >
> > There are probably other embodiments, but that's the obvious one.
> >
> > --
> > Dean
> >
> >
> >
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments on the application of sip
> >
>
>
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: [email-masked]
Date: Mon, 8 Oct 2007 19:06:38 -0400

What is the problem you are trying to solve?

Dale

---

From: "Pars Mutaf" <[email-masked]>
Date: Tue, 9 Oct 2007 10:17:02 +0200

> What is the problem you are trying to solve?

Thanks. I tried to introduce the problem in my first
mail which was perhaps too long:
http://www1.ietf.org/mail-archive/web/sip/current/msg20618.html

Briefly: the problem is that users cannot publish their
identifiers e.g. SIP URIs, for privacy reasons. They are
obligated to exchange their contact information manually
upon face-to-face contact. But face-to-face contact is not
always available, and even if it is available manual
exchange is difficult.

Details are in the e-mail cited above :-)

Please note that I invited IETF SIP researchers because they
are expert in telephony (i.e. the general idea, not only SIP).

Thanks,
pars

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Oct 2007 08:24:31 -0400

Pars Mutaf wrote:
> On 10/9/07, [email-masked] <mailto:[email-masked]>* 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>        From: "Pars Mutaf" <[email-masked]
>     <mailto:[email-masked]>>
> 

Maybe I'm missing something, but it seems to me that what you are 
seeking is exactly the function provided by a sip registrar. Your 
requirements from the referenced mail are:

> Model of operation
> 
> 1. The querier user types the target user's "human name" (as if he were

An AOR: sip:name@domain.

> 2. The pairing request is forwarded to the target phone.

The request is forwarded to the home proxy associated with the 
registrar. Then it is forwarded to a registered target phone. The caller 
doesn't need to ever know the actual address of the target phone.

> 3. The query, along with the querier user's name, are displayed on the
>    target phone's screen.

The target phone rings. The callerid information is typically displayed 
by that phone.

> 4. The target user approves the request in real-time by pushing on the YES
>    button of the phone.

The target user approves the request by answering the phone.

> 5. The two phones exchange their Mobile IPv6 home addresses, SIP URIs, and

The calling phone provided its contact address in the INVITE. The target 
phone returns its contact address in the response to the invite. They 
have also exchanged media addresses in SDP offer/answer.

It will require some additional work if you want an IPsec security 
association between caller and callee. Establishing an e2e secure path 
for a call has been a topic of interest for some time.

	Paul

---

From: "Pars Mutaf" <[email-masked]>
Date: Tue, 9 Oct 2007 14:58:59 +0200

On 10/9/07, Paul Kyzivat <[email-masked]> wrote:
> > < [email-masked] <mailto:[email-masked]>> wrote:
> >

Where did you get this information. It is private.

(I'm not saying that this a problem of SIP. This is general problem.)

Please note that the proposal is comparable to the 'phone book',
not SIP.

Thanks,
pars

        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Oct 2007 09:37:04 -0400

Pars Mutaf wrote:
> 
> 
> On 10/9/07, *Paul Kyzivat* <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> 
>     Pars Mutaf wrote:
>      > On 10/9/07, [email-masked]
>     <mailto:[email-masked]> <mailto: [email-masked]
>     <mailto:[email-masked]>>*
>      > < [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     wrote:
>      >
>      >        From: "Pars Mutaf" < [email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >
>     <http://www1.ietf.org/mail-archive/web/sip/current/msg20618.html>
>      >

In order to use a phone book, you must:
- start with the name you know for the person
- canonicalize it to a form that might be listed in a phone book
- choose which phone book to look in. This is effectively a
   domain in which names should be unique.
- look up the name to get an address. (This of course doesn't work
   if the target doesn't want to disclose the address - an unlisted
   number.)

The above isn't much different from me guessing from your name (Pars 
Mutaf) that your user name might be pars.mutaf, and then guessing that 
you might be using domain gmail.com. In fact the scale of the problem is 
comparable if I don't know where in the world your phone might be 
registered.

It is worse in that there isn't much consistency with how human names 
are mapped to user names.

It sounds like you are looking for a global registry of mappings from 
human names to various sorts of addresses. That might be something like 
ENUM, but with the keys being human names rather than phone numbers.

Given the difficulty there has been in getting a public enum 
established, I would anticipate it could be very hard to get agreement 
to establish a public registry keyed by human name - there are huge 
privacy issues.

	Paul

---

From: "Pars Mutaf" <[email-masked]>
Date: Tue, 9 Oct 2007 16:33:54 +0200

> comparable if I don't know where in the world your phone might be

There is a general privacy requirement which says that SIP URIs shouldn't
be predictable (i.e. based on human name).
Otherwise you will receive spam, unwanted calls, etc.
on your cell phone. I think everybody agrees with that.

There is also the domain name problem as you noticed.

These make the retrieval or manual exchange of phone numbers
difficult.

> human names to various sorts of addresses.

No :-)
(or, I misunderstood)
Please see below.

That might be something like
> ENUM, but with the keys being human names rather than phone numbers.

OK perhaps. But human name collisions must be handled.
Another solution would be based on multicast DNS, but for local
use only, as briefly described at:

http://www1.ietf.org/mail-archive/web/sip/current/msg20672.html

> to establish a public registry keyed by human name - there are huge

This is exactly my point. But there is a general misunderstanding.
The proposal wasn't clear I think (below is very simplified):

1. The querier types the target human name.
2. The request (e.g. for a phone number) is forwarded to the target user.
3. The target user approves it.
4. The target phone, returns its phone number.

I think the 3rd point is being missed (except, I guess, by Dean Willis who
made a comparison with consent framework. This is another discussion
topic.)

Thanks,
pars

        Paul

---

From: Adam Roach <[email-masked]>
Date: Tue, 09 Oct 2007 09:43:36 -0500

Paul Kyzivat wrote:
> human names to various sorts of addresses. That might be something 
> like ENUM, but with the keys being human names rather than phone numbers.

Alternately, you can see it as an LDAP directory with interactive user 
permissions (similar to the winfo/XCAP setup we have for presence). It 
would be a fairly straightforward effort to engineer a system fitting 
that description, but I think we'd need better defined requirements than 
we have so far.

For example: how does one locate the proper directory server for a given 
user? I doubt a unified global system to hold 2 billion to 3 billion [1] 
user records would be technically feasible; and, even it if is, I don't 
understand how it could be humanly useful. A search for "John Smith" or 
"Wen Zhang" in a directory containing half the world's population would 
turn up hundreds of thousands, and possibly millions, of records.

In fact, I don't have a particularly common name, and disambiguating 
*me* from the several dozen other Adam Roaches you get when you search 
on Google is something of a tricky task. And google gives a lot more 
context than any directory could ever hope to. Just looking at the top 
five hits on Google right now: you can probably guess that I'm not the 
tattoo artist or the wardrobe assistant --  but do you know enough about 
me to be certain I'm not the Adam Roach from Missouri listed on myspace?

In other words: I think there needs to be more scope around the problem 
before we start contemplating solutions; because the problem, as stated, 
has no workable solution. The hurdle isn't technological -- it's human.

/a

[1] http://www.news.com/2100-1039_3-6159491.html

---

From: "Pars Mutaf" <[email-masked]>
Date: Tue, 9 Oct 2007 17:08:14 +0200

> that description, but I think we'd need better defined requirements than

Thanks! But there is another question first. Will you subscribe:

> user?

Right.

> I doubt a unified global system to hold 2 billion to 3 billion [1]

I would think that a world-wide solution is overly ambitious (and difficult)
and not so useful for the average case (which covers a very large number
of users).

BTW, some folks mentioned location-based solutions.

Thanks,
pars

---

From: "Pars Mutaf" <[email-masked]>
Date: Tue, 9 Oct 2007 17:53:12 +0200

On 10/9/07, Joel M. Halpern <[email-masked]> wrote:
>
> At 08:58 AM 10/9/2007, you wrote:
> Presumably, the "this" refers to the SIP URI.
> If you don't have the SIP URI, what string do you think you
> have?  Human names are utterly useless for this, due to collision,
> misspelling, and many other problems.

To my knowledge, phonebook users never complained about that.

The real problem of the phonebook, today, is the privacy
problem. An extension is needed for interactive user
permissions as stated by Adam Roach.

A note about name collisions:

Similarly to a traditional phonebook user, if you are looking
for a certain John Smith, hopefully you will have some
additional information helping filter the results.

(in the proposed extension, the target cell phone may return
such information, e.g. company name, street address, etc.)

Note also that if anyone can send you a resolution request, that is
> roughly equivalent, in terms of intrusiveness, to anyone causing your
> phone to ring.

The proposal is rather as follows (abstract):

You solve to a challenge (e.g. a CAPTCHA) to obtain the target
phone number.
Then, you can make a call, send a message etc.

Thanks,
pars

Alternatively, if you want a challenge / response on the resolution
> request, you can give a challenge / response on the SIP request.
>
> Yours,
> Joel
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Oct 2007 12:22:44 -0400

Pars Mutaf wrote:
> 
> 
> On 10/9/07, *Joel M. Halpern* <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 

Phone books worked reasonably well in a different age. And they depended 
on people being willing to advertise certain context information to the 
public at large: their phone number and an address. I think today that 
people are not so willing to disclose that information publicly.

Today we often want to talk to people whose addresses we often don't 
know. Instead we may know their email address, or an IM address, etc. 
And those things are at least unique.

So there are two problems here:
- trying to find a unique address for someone given only
   some human name you have for them, and to disambiguate
   them from all the other people with similar names based
   on whatever information they might be willing to disclose
   to a random stranger.

- given some unique address that is known to be associated
   with a given individual, find a different address for the
   same individual that is usable for some desired form of
   communication.

The latter is probably a much more solvable problem.

> such information, e.g. company name, street address, etc.)

I'm not likely to have my phone return that sort of information to 
unknown requestors. I don't know who would.

> Then, you can make a call, send a message etc.

Really! Maybe you are willing to give your information out to anyone who 
can solve a CAPTCHA, but I'm not.

Note that in Adam's example you might be sending this request to dozens, 
hundreds, or more of targets that you are not interested in, and who are 
presumably not interested in you either. Then you are going to solve a 
capcha from each one enroute to finding the right one? And they are 
going to go along with this?

	Paul

> ------------------------------------------------------------------------
>

---

From: "Pars Mutaf" <[email-masked]>
Date: Tue, 9 Oct 2007 19:20:00 +0200

On 10/9/07, Joel M. Halpern <[email-masked]> wrote:
>
> What you are describing seems to be a directory (LDAP or White Pages
> or ...) with tools to prevent automated usage.
> It has almost nothing to do with SIP or with Mobile devices,

Cell phones make the solution attractive,
and the solution is most needed by cell phone users.

You need someone's phone number (and Mobile IPv6 home address).
You get all you need from the target phone *when needed*, if authorized
by the target user.

Or, when you meet someone and want get your phones paired, you
just type the target name because you have your cell phone in your hand.
The phones get paired. You don't need to type a long SIP URI and
Mobile IPv6 home address.

as the
> information sought could easily be any sort of communications
> establishment information.

This is a possible discussion topic.

Such directories have been tried, and generally fail on large scale.
> The internet tends to not have the kind of matching information that
> people are used to using.

I'm not sure what you mean by large scale. I suspect that it is an
unnecessarily ambitious requirement.

A local solution is already very much needed IMHO.

If you really want to build it, I suggest you uncouple it from SIP,

I don't know about solution space, currently. Discussion needed
to start somewhere, SIP WG was an obvious place.

Thanks,
pars

and make the argument to the apps area for a person resolution
> application.  I believe you have pointed to mailing lists that are
> already discussing this as a general problem.
>
> Yours,
> Joel
>
> PS: Phone books only work if you know the address you need.  Try
> using telephone information (411 in the US) without knowing what town
> your target is in.
>
> At 11:53 AM 10/9/2007, you wrote:
>
>
> >On 10/9/07, Joel M. Halpern
> ><<mailto:[email-masked]>[email-masked]> wrote:

---

From: [email-masked]
Date: Tue, 9 Oct 2007 14:00:51 -0400

I find the whole problem statement mysterious.  The stated problem is,
"How do I find a person's SIP URI without having them present to ask?"
and "How do I prevent unauthorized people from obtaining this
information?"

The first part is a general phone book problem.  But by hypothesis, it
requires relatively little authentication of me to obtain the SIP URI.
Yes, you can propose a step where the inquiry is passed to the target
for approval, but that means that anyone who attempts a lookup can
annoy the target person -- a direct failure of the privacy goal, since
the inquirer has just contacted the target!

If you want people to be interested in this, you're going to have to
assemble a much better problem statement and at least one plausible
solution, I think.

My suspicion is that treating the SIP URI itself has having strong
privacy requirements, but not treating the information needed to look
up the SIP URI as not having strong privacy requirements, is not going
to make any difference unless the process that maps between the two
has strong authentication of the inquirer.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Oct 2007 14:34:44 -0400

> https://www1.ietf.org/mailman/listinfo/humanresolvers

I subscribe to a lot of lists. I need some motivation before subscribing 
to another one. I expect a lot of people on *this* list are in the same 
boat.

You have gotten some people to respond to you here, though there is 
clearly a lot of skepticism. You will probably have better luck getting 
people to discuss here than at a new list. At least maybe you can try 
here to make a case for why people want to participate in your 
humanresolvers list.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Tue, 9 Oct 2007 15:59:48 -0500

On Oct 9, 2007, at 1:34 PM, Paul Kyzivat wrote:

> I subscribe to a lot of lists. I need some motivation before  
> subscribing to another one. I expect a lot of people on *this* list  
> are in the same boat.
>
> clearly a lot of skepticism. You will probably have better luck  
> getting people to discuss here than at a new list. At least maybe  
> you can try here to make a case for why people want to participate  
> in your humanresolvers list.

Arguably, this would be more of a candidate for the SIPPING list than  
the SIP list.

But as I said, it sounds like using an LDAP front-end. I'd image one  
could accomplish this by sending a SIP CONSENT request to a server in  
the domain of the target, where the SIP request has as its request  
URI and LDAP URL (RFC 2255, I think), with the user's name encoded in  
the LDAP URL. Assuming the consent phase hasn't previously occurred,  
said server would then look up the user name, translate it thru the  
usual SIP mechanisms, and send the CONSENT request onward. If the  
user grants consent, then the server would store this, and in the  
future either return a 302 with the user's SIP URI.

That's for the particular combination of requirements previously  
given. Many alternative approaches, such as proxying the request to  
the target rather than returning a 302 and gleaning "consent" based  
on the user's response to an initial INVITE request address slight  
variations in those requirements.

But I don't really think we need to be talking about this too much on  
the SIP list. Perhaps we should wait until the humanresolvers people  
better understand their requirements.

--
Dean

---

From: "Pars Mutaf" <[email-masked]>
Date: Wed, 10 Oct 2007 11:23:22 +0200

> "How do I find a person's SIP URI without having them present to ask?"

1) How do I find a person's SIP URI without having them present to ask.
2) When the person is present, how do we exchange our SIP URIs and
possibly other information easily. I.e., simply by typing a name we get the
phones paired.

Note that the protocol can be used for requesting any combination of
various identifiers from the target phone. For example, you will probably
need a Mobile IPv6 home address too. In this case, you will request
a SIP URI and a Mobile IPv6 home address (concurrently) from the
target phone.

> information?"

Obviously, a message with the querier user's name will be
displayed on the target phone:

               Pairing request from
               Michael Jordan. Accept? [YES/NO]

Of course, authentication needed between cell phone operators.
If a cerfiticate is unknown, the target user should be warned.

> the inquirer has just contacted the target!

This is a very good question. Here is an abstract solution:

Before the pairing request can be displayed on the target screen,
the querier "user" will need to solve a challenge. For example a CAPTCHA.
The attack that you mention above is similar to knocking at the door
of someone and running away. This could happen (I myself did that, I confess
:-/  ).
In our case the attack is even more stupid because the attacker
has to solve a difficult problem before disturbing someone!

> assemble a much better problem statement and at least one plausible

One plausible solution to me (a serverless one) can be based on mDNS, but
for wireless local use only.
Dean Willis is suggesting a solution based on SIP consent framework.
Others see it as extension to LDAP.
DNS based solutions are also being mentioned.

> has strong authentication of the inquirer.

I hope that I could answer this above.

Thanks,
pars

Dale

---

From: "Pars Mutaf" <[email-masked]>
Date: Wed, 10 Oct 2007 15:09:56 +0200

On 10/9/07, Paul Kyzivat <[email-masked]> wrote:
> to another one.

One more doesn't hurt? :-)

Thanks a lot for your suggestions below, I'm trying to make
a case for telephony people in general. I would like to thank
the SIP WG for their comments. An area director suggested
me to ask SIP WG feedback.

I'll send a mail to humanresolvers pointing to this discussion.

I hope to see you there for in-depth discussions on the
problem statement, requirements and solution space.

Regards,

pars mutaf

I expect a lot of people on *this* list are in the same

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Oct 2007 10:28:40 -0400

Elaborating on my earlier reply...

I question whether what you are trying to achieve even makes sense to 
attempt, at least in the form you have framed the problem. And I sense 
the same feeling from some of the other people, though that is only my 
impression.

Increasingly, people have multiple identifier (pseudonyms?) that they 
are known by in various contexts. Some of these are unique, in that 
there is a well defined relationship between the identifier and a 
specific human being. In other cases the relationship between the 
identifier and a human is non-unique, and other information must be used 
to resolve the ambiguity. Person names are of the non-unique form. URIs 
used for various forms of communication, including SIP and TEL, are 
often unique.

Just as it is increasingly common for people to use multiple identities, 
it is often the case that they don't desire the association between one 
of these identities and their person or other identities to be known. 
However this isn't always the case. Sometimes the distinct identifiers 
are simply an artifact of technology, and associations between them are 
willingly exposed.

(E.g. on some online forums I use a pseudonym. The operator of the list 
knows the mapping to my email address and name, but this kept private. I 
may choose to include my name, email address, or phone number in a 
message on this forum - exposing the relationship - or I may carefully 
refrain from doing so.)

I think you have two problems to solve here, and they probably need 
different solutions:

1) mapping from an ambiguous identifier for a person to an unambiguous 
identifier.

2) given one unambiguous identifier, obtain a different unambiguous 
identifier which enables a particular form of communication.

For (1) I think the best you can expect to do is have some kind of 
voluntary registry (roughly akin to the phone book) that lists the names 
of people and whatever information they choose to make public that might 
help disambiguate them from other people, and then a corresponding 
unambiguous identifier. There doesn't have to be just one such registry. 
Google does an admirable job of federating many sources of such information.

For (2) the solution is straightforward if the association between the 
identify you have and the one you want is public. If it is not public, 
then you must make a request and have it granted. If the identifier you 
have enables a communication path where you can make a query then the 
solution is straightforward - you just ask. If the identifier you have 
(say a Social Security number) doesn't enable communication, then you 
must delegate your request to some entity that knows the mapping you 
desire, and the policy for determining whether to grant it to you. (This 
could involve communicating with the target.)

What seem like a bad idea to me is trying to combine (1) and (2) when 
you don't have enough information to disambiguate. And IIUC that is what 
you are proposing - to have an agent that knows the mapping from names 
to phone numbers make queries to all people with matching names. IMO 
there will be widespread objection to that, even if requests are 
restricted to those requesters who have solved a CAPCHA.

	Paul

---

From: "Pars Mutaf" <[email-masked]>
Date: Thu, 11 Oct 2007 19:05:52 +0200

> could involve communicating with the target.)

Thanks for your input. I respect your requirements.
I still hope we can talk more in detail.

Can we add more levels to these privacy requirements?

We can assume that young users (living mostly in a cyberspace :-)
know each other's pseudonyms for example?

Or, I can tell you my pseudonym when we meet (and use this
info for easily pairing our phones). If later you lose contact(*)
you can re-initiate pairing if you remember the pseudonym.

*: your phone has lost state, or you have new phone,
   or I changed my phone number etc.

I mean the association between human name and pseudonym
may not be necessarily made public.

> to phone numbers make queries to all people with matching names.

IMO
> restricted to those requesters who have solved a CAPCHA.

I respect your objections, but this is also an approach
for another type of user IMHO.

If I desperately need to talk and I have 10 candidate target users
(with the same name), then I can call all of them one by one, until
I find the person. Note also that, when we talk about name collisions,
we should talk about a "double name collision". The querier's name
appears on the target phone's screen. So, if the target user doesn't
know me they will probably reject my request. Hoping that my
friend didn't reject my query I can try the next one.

If there are 100 candidate users, this is bad luck. But the service
still works for millions of others.

Thanks,
pars

PS: Without comment, hoping that this would give some ideas:
http://www.intelius.com/phone-search-name.html

        Paul
> >> You solve to a challenge ( e.g. a CAPTCHA) to obtain the target
> >> phone number.

---

From: "Pars Mutaf" <[email-masked]>
Date: Fri, 26 Oct 2007 12:28:06 +0200

Before you shoot me (I agree that this is orthogonal to SIP),
thanks all for your previous input, I'm here showing you the
results of your input; the new IP pairing problem statement,
thanks.
pars

                  IP host pairing problem statement

Today, cell phone numbers are not published in a phonebook for avoiding
telemarketers, prank callers, Spam and SPIT (SPam over Internet
Telephony). Users today exchange their phone numbers upon user contact,
often through oral communication.

In IP telephony, users will need a user friendly "pairing" protocol
that identifies the two phones and let them exchange their SIP URIs and
Mobile IPv6 home addresses, and possibly other information. The phones
will establish an IPsec security association upon this first contact.
IPsec will be required not only for protecting their SIP URIs from
eavesdroppers, but also for protecting data.

"IP host pairing" is defined as a pairing protocol that can operate
over IP; upon user contact and also over the Internet i.e. long distances.
It will address three problems of pairing:

1. Pairing when there is user contact: In this case, users can exchange
   their names or pseudonyms helping identify the hosts to each other the
   first time they meet.

2. Re-pairing, or updating pairing state through the Internet: The users
   may change their SIP URIs and/or Mobile IPv6 home addresses or other
   information. The users will need to update these informations without
   waiting until their next meeting. Or, they may need additional
   information which was not previously exchanged when there was user
   contact.

3. Pairing without user contact (where possible): Users may know each
   other but user contact may not be possible. Or, two previously paired
   hosts may lose pairing state. Users cannot probably wait until their
   next meeting to recover from loss of state.

Engineering problems:

   - Identifying the two hosts to each other in (1) and (3).
   - Preventing unauthorized and annoying pairing attempts from unknown
     users.
   - The design of the pairing protocol used to exchange and update
     the SIP URIs, home addresses and possibly other information.