I believe your remote gateway INVITE that include refresher=uac in the INVITE was incorrect. From what I understand, the refresher should be in 200 OK message. Here is a link that you can clearly see SIP session timer call flows in different scenerio: <a href="http://www.dialogic.com/webhelp/IMG1010/10.5.3/WebHelp/Description/SIP/SIP_Session_Timer_Call_Flows.htm">http://www.dialogic.com/webhelp/IMG1010/10.5.3/WebHelp/Description/SIP/SIP_Session_Timer_Call_Flows.htm</a><br>
<br>As per Steve, if you think it's a bug, please open a ticket in Jira.<br><br>-djbinter<br><br><br><div class="gmail_quote">On Tue, May 1, 2012 at 7:36 AM, Steven Ayre <span dir="ltr"><<a href="mailto:steveayre@gmail.com" target="_blank">steveayre@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Please report bugs to JIRA. The mailing list is not the place for<br>
reporting bugs.<br>
<br>
<a href="http://jira.freeswitch.org/" target="_blank">http://jira.freeswitch.org/</a><br>
<br>
Reporting it on Jira let's us easily have any conversation about it<br>
there and properly documented in a single place.<br>
<br>
-Steve<br>
<div><div class="h5"><br>
<br>
<br>
On 1 May 2012 12:58, Barnaby Ritchley <<a href="mailto:barnyritchley@hotmail.com">barnyritchley@hotmail.com</a>> wrote:<br>
> Hi All<br>
><br>
> We have a situation where FS seems not to behaving correctly with session<br>
> timers.<br>
><br>
> Call originates from remote party with invite as per:<br>
><br>
> INVITE <a href="mailto:sip%3A%2B1234@1.2.3.4">sip:+1234@1.2.3.4</a>;user=phone SIP/2.0<br>
> Max-Forwards: 69<br>
> Session-Expires: 3600;refresher=uac<br>
> Min-SE: 600<br>
> Supported: timer, 100rel<br>
> To: +1234 <<a href="mailto:sip%3A%2B1234@1.2.3.4">sip:+1234@1.2.3.4</a>;user=phone><br>
> From: <<a href="mailto:sip%3A%2B5678@5.6.7.8">sip:+5678@5.6.7.8</a>;user=phone>;tag=381443<br>
> P-Asserted-Identity: <<a href="mailto:sip%3A%2B5678@5.6.7.8">sip:+5678@5.6.7.8</a>><br>
> Call-ID: 1333524918-9038500@xxxxx<br>
> CSeq: 1 INVITE<br>
> Allow: CANCEL, ACK, INVITE, BYE, OPTIONS, INFO, PRACK, UPDATE<br>
> Via: SIP/2.0/UDP<br>
> 7.8.9.1:5060;branch=z9hG4bKab17954781a678af6dfd6916593dc954<br>
> Contact: <<a href="http://sip:+5678@5.6.7.8:5060" target="_blank">sip:+5678@5.6.7.8:5060</a>><br>
> Expires: 330<br>
> Content-Type: application/sdp<br>
> Accept: application/sdp<br>
> Content-Length: 387<br>
><br>
><br>
> Here you can see the UAC supporting timer, and specifying a session expires<br>
> of 3600.<br>
><br>
> FS responds with 100 trying (not relevant) then 180 runing (also not<br>
> relevant) then 200OK as per:<br>
><br>
> SIP/2.0 200 OK<br>
> From: <<a href="mailto:sip%3A%2B5678@5.6.7.8">sip:+5678@5.6.7.8</a>;user=phone>;tag=381443<br>
> To: +1234 <<a href="mailto:sip%3A%2B1234@1.2.3.4">sip:+1234@1.2.3.4</a>;user=phone>;tag=UrcX58SSF2Nrm<br>
> Call-ID: 1333524918-9038500@xxxxx<br>
> CSeq: 1 INVITE<br>
> Contact: <sip:+1234@1.2.3.4:5060;transport=udp><br>
> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, NOTIFY<br>
> Supported: timer, precondition, path, replaces<br>
> Allow-Events: talk, hold, refer<br>
> Session-Expires: 3600;refresher=uac<br>
> Min-SE: 600<br>
> Content-Type: application/sdp<br>
> Content-Disposition: session<br>
> Content-Length: 249<br>
><br>
><br>
> So, here freeswitch is responding with the session-expires and refresher<br>
> UAC. Then after 60 mins, the call is dropped as FS sends a Bye to the UAC<br>
> because it does not receive a session refresh. Here is the Bye:<br>
><br>
> BYE <a href="http://sip:+5678@5.6.7.8:5060" target="_blank">sip:+5678@5.6.7.8:5060</a> SIP/2.0<br>
> Via: SIP/2.0/UDP 178.255.58.28;rport;branch=z9hG4bK2vm55Zp2D6vHm<br>
> Max-Forwards: 70<br>
> From: +1234 <<a href="mailto:sip%3A%2B1234@1.2.3.4">sip:+1234@1.2.3.4</a>;user=phone>;tag=UrcX58SSF2Nrm<br>
> To: <<a href="mailto:sip%3A%2B5678@5.6.7.8">sip:+5678@5.6.7.8</a>;user=phone>;tag=381443<br>
> Call-ID: 1333524918-9038500@xxxxx<br>
> CSeq: 27563136 BYE<br>
> Contact: <sip:+1234@1.2.3.4:5060;transport=udp><br>
> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, NOTIFY<br>
> Supported: timer, precondition, path, replaces<br>
> Reason: SIP;cause=408;text="Session timeout"<br>
> Content-Length: 0<br>
><br>
> When we raised this with the UAC, their response is that the reason they are<br>
> not refreshing the session is because FS should be sending a Require: timer;<br>
> header in the response, so their UAC thinks that session timers are not in<br>
> use.<br>
><br>
> This is documented in para 9 of RFC4028:<br>
><br>
> If the refresher parameter in the Session-Expires header field in the<br>
> 2xx response has a value of 'uac', the UAS MUST place a Require<br>
> header field into the response with the value 'timer'. This is<br>
> because the uac is performing refreshes and the response has to be<br>
> processed for the UAC to know this.<br>
><br>
><br>
> It appears the FS is not doing this, but is hanging up the call anyway, so<br>
> we are getting dropped calls that are around the 60 mins mark.<br>
><br>
> Whats everyones view on this? It would seem logical that if FS is not<br>
> sending requires in the return 200, that the UAC will think that the session<br>
> timers are not being used in the session, and therefore will not refresh it.<br>
><br>
><br>
> Brgds<br>
><br>
><br>
</div></div>> _________________________________________________________________________<br>
> Professional FreeSWITCH Consulting Services:<br>
> <a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
> <a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
><br>
> FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
> <a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
><br>
> Official FreeSWITCH Sites<br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
> <a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
> <a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
><br>
> FreeSWITCH-users mailing list<br>
> <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
><br>
<br>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</blockquote></div><br>