We have a situation where FS seems not to behaving correctly with session
timers.

Call originates from remote party with invite as per:

INVITE sip:+1234@1.2.3.4;user=phone SIP/2.0
Max-Forwards: 69
Session-Expires: 3600;refresher=uac
Min-SE: 600
Supported: timer, 100rel
To: +1234 <sip:+1234@1.2.3.4;user=phone>
From: <sip:+5678@5.6.7.8;user=phone>;tag=381443
P-Asserted-Identity: <sip:+5678@5.6.7.8>
Call-ID: 1333524918-9038500@xxxxx
CSeq: 1 INVITE
Allow: CANCEL, ACK, INVITE, BYE, OPTIONS, INFO, PRACK, UPDATE
Via: SIP/2.0/UDP
7.8.9.1:5060;branch=z9hG4bKab17954781a678af6dfd6916593dc954
Contact: <sip:+5678@5.6.7.8:5060>
Expires: 330
Content-Type: application/sdp
Accept: application/sdp
Content-Length: 387


Here you can see the UAC supporting timer, and specifying a session expires
of 3600.

FS responds with 100 trying (not relevant) then 180 runing (also not
relevant) then 200OK as per:

SIP/2.0 200 OK
From: <sip:+5678@5.6.7.8;user=phone>;tag=381443
To: +1234 <sip:+1234@1.2.3.4;user=phone>;tag=UrcX58SSF2Nrm
Call-ID: 1333524918-9038500@xxxxx
CSeq: 1 INVITE
Contact: <sip:+1234@1.2.3.4:5060;transport=udp>
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, NOTIFY
Supported: timer, precondition, path, replaces
Allow-Events: talk, hold, refer
Session-Expires: 3600;refresher=uac
Min-SE: 600
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 249


So, here freeswitch is responding with the session-expires and refresher
UAC. Then after 60 mins, the call is dropped as FS sends a Bye to the UAC
because it does not receive a session refresh. Here is the Bye:

BYE sip:+5678@5.6.7.8:5060 SIP/2.0
Via: SIP/2.0/UDP 178.255.58.28;rport;branch=z9hG4bK2vm55Zp2D6vHm
Max-Forwards: 70
From: +1234 <sip:+1234@1.2.3.4;user=phone>;tag=UrcX58SSF2Nrm
To: <sip:+5678@5.6.7.8;user=phone>;tag=381443
Call-ID: 1333524918-9038500@xxxxx
CSeq: 27563136 BYE
Contact: <sip:+1234@1.2.3.4:5060;transport=udp>
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, NOTIFY
Supported: timer, precondition, path, replaces
Reason: SIP;cause=408;text="Session timeout"
Content-Length: 0

When we raised this with the UAC, their response is that the reason they are
not refreshing the session is because FS should be sending a Require: timer;
header in the response, so their UAC thinks that session timers are not in
use.

This is documented in para 9 of RFC4028:

If the refresher parameter in the Session-Expires header field in the
2xx response has a value of 'uac', the UAS MUST place a Require
header field into the response with the value 'timer'. This is
because the uac is performing refreshes and the response has to be
processed for the UAC to know this.


It appears the FS is not doing this, but is hanging up the call anyway, so
we are getting dropped calls that are around the 60 mins mark.

Whats everyones view on this? It would seem logical that if FS is not
sending requires in the return 200, that the UAC will think that the session
timers are not being used in the session, and therefore will not refresh it.


Brgds