On 10/9/07, Paul Kyzivat <[EMAIL PROTECTED]> wrote:
>
>
>
> Pars Mutaf wrote:
> > On 10/9/07, [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>*
> > < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
> >
> > From: "Pars Mutaf" <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>>
> >
> > 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.
> >
> > 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.
>
> 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
> > consulting a phonebook), or a pseudoynm.
>
> An AOR: sip:[EMAIL PROTECTED]
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
> 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
> > establish an IPsec security association (using IKEv2).
>
> 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
>
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
