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

sachin garg sachingarg2k1 at gmail.com
Mon Aug 16 03:47:01 UTC 2010


@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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20100816/5c7df59f/attachment-0002.html>


More information about the discussion mailing list