Please report bugs to JIRA. The mailing list is not the place for reporting bugs. http://jira.freeswitch.org/ Reporting it on Jira let's us easily have any conversation about it there and properly documented in a single place. -Steve On 1 May 2012 12:58, Barnaby Ritchley <barnyritchley@hotmail.com> wrote:
Hi All
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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org