Re: [reSIProcate] Session Timers bug: refresher="uas" is not respected by InviteSession

[jgeras@xxxxxxxxxxxxxxx]

Wow...  Glad I asked.  Thanks for the explanation!

 

Looks like this has confused a few people in the past, as I've even found examples from other implementations that are doing it wrong (http://www.tahi.org/sip-ipv6/ua6/doc-1.2/sip-ipv6-ua/UA/timer/UA-17-1-3.html for one...)

 

Having said that, I have to admit that I was too easily convinced by the original bug report :-)

Reading RFC 4028, section 7.4:

   If the session refresh request is not the initial one, it is
   RECOMMENDED that the refresher parameter be set to 'uac' if the
   element sending the request is currently performing refreshes, and to
   'uas' if its peer is performing the refreshes.  This way, the role of
   refresher does not change on each refresh.  

Looks like the key to this is reading 'the request' to mean 'the session refresh request'.

 

Thanks again,

 - Jeremy -


-----Original Message-----
From: Scott Godin <slgodin@xxxxxxxxxxxx>
Sent: Mon, September 24, 2007 7:38 pm
To: 'Jeremy Geras' <jgeras@xxxxxxxxxxxxxxx>, resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
Subject: RE: Session Timers bug: refresher="uas" is not respected by InviteSession

Hi Jeremy,

 

Some history….

 

When I first implemented session timers (a while back now) – I was confused over the terms refresher=uac and refresher=uas.   About whether the refresher parameter (uas vs uac) on a refresh request was referring to the original invite or the the actual refresh request  – so I posed a question to the IETF list.  The answer I got was that the refresher parameter refers to the transaction itself.

 

So given your example below – since the proxy is requesting “uas” refresher and it is the UAS of the initial invite – then it should send the refresh (as it does).   In the refresh request your proxy is specifying that the UAS is the refresher – in this case the UAS of this re-invite, is actually DUM – so DUM should be the refresher.  And it tries to do refresh (passing itself as the refresher – uac).

 

The short story is, that given the advice I previously received, DUM is behaving correctly.

 

Scott

 

From: Jeremy Geras [mailto:jgeras@xxxxxxxxxxxxxxx]
Sent: September 24, 2007 4:24 PM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
Cc: slgodin@xxxxxxxxxxxx
Subject: Session Timers bug: refresher="uas" is not respected by InviteSession

 

Hi,

 

I’m seeing odd behaviour with session timers in the following case.  I have a fix that I’ve tested out (see attached patch), but I’d like to run it by you (Scott) before committing it as I believe you’re more familiar with that code...

 

(note that the default Session-Expires used in the following is 90 seconds)

 

DUM   -------------------   proxy

 

INVITE ----> (no refresher preference specified)

<---- 100

<---- 180

<---- 200 (refresher=”uas”)

ACK ---->

 

… 45 seconds go by …

 

<---- INVITE (refresher=”uas”)

200 ----> (refresher=”uas”)

 

… 45 seconds go by …

 

<---- INVITE (refresher=”uas”)

INVITE ----> (refresher=”uac”)

 

At this point, DUM is confused and thinks that it is the refresher, so we get the INVITE glare condition, and things go downhill from there.  The problem seems to be logic in InviteSession that gets executed when it receives the first refresh after 45 seconds.

 

I’ve tested out the attached patch, but please let me know if you think I’ve missed something…

 

Thanks,

 - Jeremy -

 

 

Jeremy Geras

Software Developer

CounterPath Solutions Inc.

(formerly NewHeights Software Corp.)