On 5/23/13 5:28 AM, Priya Arya wrote:
> Hi Paul,
>
> Thanks for the response.
> I have marked inline the answers to the queries.
Then, based on what you have said, the "SIP Stack" is broken:
- the 2nd invite (first re-invite) was incorrect because it didn't
include an S-E
- it apparently failed to honor the S-E in received in the
response to that invite.
I don't see anything that the "N/W" is doing wrong.
Thanks,
Paul
> Regards
> Priya Arya
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu]
> Sent: Tuesday, May 21, 2013 12:34 AM
> To: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] Query regarding session timer behaviour in
> SIP Stack
>
> 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.)
>
> <------- This Re-INVITE was originated by the Application running at the top
> of SIP Stack and not motivated by the session timer ------>
>
>> 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?
>
> <----- Re-INVITE message contains "Supported:timer" only and neither Min-S-E
> nor S-E in it ------>
>
>
> 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?
>
> <----- After checking the logs of SIP Stack, I found that the BYE is sent out
> on the expiry of Session refresh timer and so the BYE terminates the call
> ------>
>
>
>> 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
>
>
>
>
> ===============================================================================
> 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
