RE: [Sip] Why do we need 3-way handshake for INVITE transaction....

[Prasanna Venkatesh <prasanna@huawei.com>]

Hi,
	One of the simplest policies could be accept the first 200.  After the UA
receives the first 200, it sends a ACK+BYE for all subsequent 200 responses.
	However for a very intelligent UA (C&s) pair, it could use Call-Info to
determine the selection, the call-info being a part of the 200 response. The
call-info could either containing a link to a URL on reaching which the UAC
could determine the type of callee or it could be a business-card using
which it could determien the type of callee.
	There are crude ways of doing this also, like using say the URL or display
name of the Contact, though it is not advisable.

But I do not know a clean way where the callee mentions to the caller the
kind of device it is or the identity of the person answering the call (as
the display name of the To is also fixed by the UAC).  Any solution to do
this?

Cheers,
Prasanna

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of
Nataraju A.B.
Sent: Saturday, May 31, 2003 4:21 AM
To: Arjun Roychowdhury; Vishal Phirke
Cc: sip@ietf.org; sip-admin@ietf.org; Sip-implementors@cs.columbia.edu
Subject: Re: [Sip] Why do we need 3-way handshake for INVITE
transaction....



----- Original Message -----
From: "Arjun Roychowdhury" <aroychow@hns.com>
To: "Vishal Phirke" <vishal_phirke@nmss.com>
Cc: "Nataraju A.B." <natarajuab@huawei.com>; <sip@ietf.org>;
<sip-admin@ietf.org>
Sent: Saturday, May 31, 2003 1:27 AM
Subject: Re: [Sip] Why do we need 3-way handshake for INVITE transaction....


> On 05/30/2003 03:03:53 PM, "Vishal Phirke" wrote:
>
> > 2. Invites can be forked. And if multiple destinations send
> > 200 OK, you
> > don't want to end up with multiple connections. Instead, 3-way
> > handshake
> > allows the decision of accepting one of them delayed till Ack
> > is sent by
> > the originator of the request.
> >
>
> I dont think this is a valid reason for 3-way handshakes. By definition,
> all 200 OKs are proxied back. Its upto the caller UA
> to then send BYE/OK to callees that it does not want to talk to due to
> forking. Therefore, the ACK is sent to all of them and doesnt
> help in delaying the decision.

[ABN] what could be the logic which the application might use to reject the
responses,
I mean which one out of 'n' 200-OK response for INVITE will be accepted and
rest all will be rejected.
The application only intended to contact the calle, but it does not have any
information about the callee information (which one to select).

will this be driven by a local policy ????

Regards,
-Nataraju A.B.

>
> regds
> arjun
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip