[SIPForum-discussion] Why three way handshake for INVITE?

[vidyut gupta]

Hi Sachin,

"I understood what you said but what if the OK gets lost i.e no ACK is
received by B party. The transaction layer will resend the OK (as per
the timers)"
 --- Transaction layer doesn't retransmit the 200 OK, this the job of TU

RFC 3264 says that whenever UA sends INVITE with an offer it must be ready to receive the media on advertise ports, same is true for 200 OK as well. So it depends on UA implementations, they may send but should be able to receive the media without receiving the ACK (provided offer-answer has already been completed).

Regards,
Vidyut

--- On Mon, 8/16/10, sachin garg <sachingarg2k1 at gmail.com> wrote:

From: sachin garg <sachingarg2k1 at gmail.com>
Subject: Re: [SIPForum-discussion] Why three way handshake for INVITE?
To: "M. Ranganathan" <mranga at gmail.com>
Cc: discussion at sipforum.org
Date: Monday, August 16, 2010, 9:17 AM

@Ranganathan:
I understood what you said but what if the OK gets lost i.e no ACK is received by B party. The transaction layer will resend the OK (as per the timers). But B party has already picked up the phone. So, the dead air could be heard by B party for a very small duration of time.Or is it so that unless and until ACK is received the user agent will not try to play the media and hence no question of dead air?



 
regards


On Fri, Aug 13, 2010 at 10:37 PM, M. Ranganathan <mranga at gmail.com> wrote:

The delay is caused by the human picking up the phone ( that is when
the OK gets sent ).  The ACK indicates to the UAS that the OK was



actually seen by the UAC, thereby allowing the UAS to set up a media
stream. If not for the ACK , you could have a situation where the OK
is lost and the human picking up could hear dead air.  INVITE
transactions are long running and expensive to set up - hence the



three way handshake. This does not apply to other kinds of
transactions.





On Fri, Aug 13, 2010 at 12:05 AM, sachin garg <sachingarg2k1 at gmail.com> wrote:
> Hi,
>
> I was curious to know that why SIP (RFC3261) mandates a 3 way handshake for



> INVITE only.
> The extract (RFC 3261 section 17.1) says "
>
> The long delays expected for
>
>
>    sending a response argue for a three-way handshake"
>
>



> I can understand about the need of session parameters negotiation but what
> is the rationale behind the delay?
>
> regards
>

> _______________________________________________
> This is the SIP Forum discussion mailing list
> TO UNSUBSCRIBE, or edit your delivery options, please visit
> http://sipforum.org/mailman/listinfo/discussion



> Post to the list at discussion at sipforum.org
>
>



--
M. Ranganathan





-----Inline Attachment Follows-----

_______________________________________________
This is the SIP Forum discussion mailing list
TO UNSUBSCRIBE, or edit your delivery options, please visit http://sipforum.org/mailman/listinfo/discussion
Post to the list at discussion at sipforum.org



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20100820/51c74731/attachment-0002.html>