[SIPForum-discussion] UAC - INVITE Transaction Timeout Timer

Tomasz Zieleniewski tzieleniewski at gmail.com
Sat Jun 20 11:51:50 UTC 2009


Hi,

My comments inline.

2009/6/20 Shmulik Basan <sbasan at 10levels.com>

>  Hi,
>
>
>
> I don't think the below answer is accurate.
>
>
>
> SIP defines two types of responses, provisional and final.
>
> Final responses convey the result of the request processing, and are sent
> reliably.
>
 Provisional responses provide information on the progress of the request
> processing, but are not sent reliably in RFC 3261.
>
> Both UAC & UAS will response with CANCEL after 32 Sec when there is no
> additional provisional or final response.
>
If there is no response at all (provisional of final) then there is a
transaction timeout and no CANCEL will be generated by UAC, there is no need
to do that.
UAS won't send any CANCEL request because it can't. CANCEL request is used
by the UAC to cancel the ongoing request (transaction)
UAS It is resposible for responding to the request not canceling the request
which can be only done by the UAC (initiator).

> The PRACK should provide the reliable answer to the un-reliable response.
>
Prack ia an extension to SIP which provides additional reliable delivery of
provisional responses to base SIP.
It doesn't modify the transaction state machine with respoect to state
transitions and Timer B.

Kind regards,
- Tomasz Zieleniewski

>
>
> Please refer to RFC 3262.
>
>
>
>
>
> *From:* discussion-bounces at sipforum.org [mailto:
> discussion-bounces at sipforum.org] *On Behalf Of *Tomasz Zieleniewski
> *Sent:* Friday, June 19, 2009 3:51 PM
> *To:* sreekant nair
> *Cc:* discussion at sipforum.org
> *Subject:* Re: [SIPForum-discussion] UAC - INVITE Transaction Timeout
> Timer
>
>
>
> Hi,
>
>
> Timer B is only relevant while transaction is in the initial "calling"
> state.
> It is used both for reliable and unreliable transports.
> When transaction moves to "proceeding" state as it receives
> a provisional response, it is completely up to UAC what to do then.
> You can compare it to the situation when You call someone
> and You hear never ending ringing in the phone.
> Probably You will eventually give up and hang up.
> The same thing happens here, UAC hang up by sending
> a CANCEL which cancels the transaction.
>
>
> Kind regards,
> - Tomasz Zieleniewski
>
> 2009/6/18 sreekant nair <sreekant_nair at yahoo.com>
>
>
>
> Hi Everyone,
>
> Have a query regarding Timers.
>
> If a client sends an INVITE and receives a provisional response but does
> NOT get a Final Response, is there a Timer that clears up the transaction?
>
> RFC3261 specifies Timer B as the INVITE Transaction Timeout Timer. However
> in the state transition diagram, there is no mention of whether Timer B is
> stopped,restarted on moving from the "CALLING" state to the "PROCEEDING"
> state on receiving a 1xx message. These are my specific queries:
>
>    1. If while in "PROCEEDING" state no final response is received, what
>    happens?
>    2. Is it implied that Timer B is only stopped/canceled on receiving a
>    final response?
>    3. What happens when Timer B fires? Should the client send a CANCEL or
>    just kill the transaction?
>
> Thanks for any inputs in this regard.
>
> Regards
> Sreekant Nair
>
>
>
>
> _______________________________________________
> 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/20090620/0fcbe132/attachment-0002.html>


More information about the discussion mailing list