[SIPForum-discussion] UAC - INVITE Transaction Timeout Timer

[Tomasz Zieleniewski]

Hi,
*
*Base SIP (defined by RFC 3261 and updated by 3265, 3853, 4320, 4916 and
5393)
doesn't make use of Timer B except when transaction is in the initial
"calling" state.
You can apply such behavior that Timer B is still active in "proceeding"
state and fires
which causes a CANCEL to be sent but this would be an implementation
specific behaviour.

Session timer mechanism is a keepalive mechanism for SIP Session.
It is arranged through a periodic session refresh by re-INVITE or UPDATE
requests.
When initial INVITE transaction is in the "proceeding" state there is no
session yet established
and You can not send another INVITE as long as You don't receive response to
the currently processed.
Beside that session timer mechanism is targeted rather for proxies then UAs.
User agents can determine state of the session through local means while
Proxy don't.
Session timer gives them a way to explicitly determine if the ongoing
session can be considered finished.

Kind regards,
- Tomasz Zieleniewski

2009/6/19 sreekant nair <sreekant_nair at yahoo.com>

> Thanks Tomasz,
>
> Rely on the user to hang up thereby sending a CANCEL to the far end -
> interesting. So does your statement imply that on receiving a provisional
> response, we must STOP TIMER B?
>
> A related query - Any idea how the "session-expires" header works in
> conjunction with this scenario? The client I use supports this header and
> uses a default value of 1800 seconds. Does that mean the SIP stack starts
> another timer for 30mins and hypothetically if the user never ends the call,
> should this tear down the transaction? Or is this timer only started for
> Confirmed Dialogs?
>
> Thanks again.
> Sreekant
>
> ------------------------------
> *From:* Tomasz Zieleniewski <tzieleniewski at gmail.com>
> *To:* sreekant nair <sreekant_nair at yahoo.com>
> *Cc:* discussion at sipforum.org
> *Sent:* Friday, June 19, 2009 8:50:50 AM
>
> *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/1ed98fad/attachment-0002.html>