On 5/20/13 2:12 PM, Priya Arya wrote:
> Hi All,
>
> I have certain queries about the session timer behaviour in the SIP Stack.
> The scenario is as follows :
>
> SIP Stack
> N/w
>
> At T0s
> INVITE
> -------------------------------------------------------------------------------->
> (having SE=600 &Min-SE = 600 )
>
> 100 Trying
> <---------------------------------------------------------------------------
> 180 Ringing
> <-------------------------------------------------------------------------
> 200 OK
> <-------------------------------------------------------------------------------
> (having Require:timer,SE=600,refresher=uas)
> ACK
> ---------------------------------------------------------------------------------->
>
> <---------------------------------Call Connected
> --------------------------------->
>
> At this point the Call is connected and the session timer is started by SIP
> Stack when 200 OK from the Network is received by the SIP Stack.
> After this, SIP Stack sends out a Re-INVITE with as the new offer(as the
> version number in the o-line is incremented here).
So this was a spontaneous re-INVITE, not motivated by session timer?
(It doesn't really matter, but it will help in understanding your case.)
> At T0+8s
> INVITE
> --------------------------------------------------------------------------->
> (Version number in o-line of Re-INVITE SDP is incremented by
> 1)
Did this have an S-E in it? Did it have Supported:timer? Did it have a
Min-S-E?
The RFC says:
In a session refresh request sent within a dialog with an active
session timer, the Session-Expires header field SHOULD be present.
When present, it SHOULD be equal to the maximum of the Min-SE header
field (recall that its default value when not present is 90 seconds)
and the current session interval. Inclusion of the Session-Expires
header field with this value avoids certain denial-of-service
attacks, as documented in Section 11. As such, a UA should only
ignore the SHOULD in unusual and singular cases where it is desirable
to change the session interval mid-dialog.
But it doesn't say "MUST be present". So the UAS must be prepared for
that case.
> 200 OK
> <-------------------------------------------------------------------------------
> (having SE=19200,refresher=uas)
Note that the RFC talks about session refresh requests as if they were
somehow distinguishable from INVITEs and UPDATEs used for other
purposes. And the UAS behavior doesn't have different rules for the
first request and subsequent ones. In reality there is no way to
distinguish, so you really must assume that *every* INVITE and UPDATE
will either serve as a refresh or else will cancel the timer.
So, if there was no S-E in the request, and there is none in the
response, then it must cancel the timer. In this case the S-E in the
response resets the timer to 19200 seconds. The UAC should realize that.
> ACK
> ---------------------------------------------------------------------------------->
>
> At T0 + 485s
>
> BYE
> ---------------------------------------------------------------------------------->
>
> The call is terminated with BYE by the SIP Stack after 485 seconds.
One question of course is why the BYE was sent.
I guess you are assuming it has something to do with a session timer
expiring, but do you know that?
> Here I have few doubts:
>
> 1) The refresher is network here in both the cases.
> The second 200 OK response is sent for the "Re-INVITE with new offer"
> containing the greater values of session timer than the first 200 OK.
> So, does the new value of Session-Expires=19200s in second 200Ok should
> be considered as session refresh request by the SIP Stack ?
As I explained above, every reinvite and update resets (or cancels) the
session timer.
The RFC doesn't come right out and say this, but it is implicit.
> 2) Should the SIP Stack restart its session timer with the new value "19200"
> or if the SIP Stack should restart its timer with the old value "600" on
> receiving second 200 OK ?
19200.
> 3) Here, the call is terminated with BYE after 485 seconds by the SIP Stack.
> What should be the exact time to terminate the call considering the fact
> that SIP Stack is running the session timer with the values received in 200
> OK responses?
The draft says:
Similarly, if the side not performing refreshes does not receive a
session refresh request before the session expiration, it SHOULD send
a BYE to terminate the session, slightly before the session
expiration. The minimum of 32 seconds and one third of the session
interval is RECOMMENDED.
That would be after 568 seconds for an S-E of 600, and 19,168 seconds
for S-E of 19,200. If the BYE was because of an assumed expiry of the
session timer, then I don't know where the value came from.
Thanks,
Paul
> Please share the references from the RFC to support the above queries.
>
> Regards
> Priya Arya
>
>
>
>
> ===============================================================================
> Please refer to http://www.aricent.com/legal/email_disclaimer.html
> for important disclosures regarding this electronic communication.
> ===============================================================================
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
