[Freeswitch-users] Freeswitch and RFC4028

[Steven Ayre]

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 at 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 at 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 at 1.2.3.4;user=phone>
> From: <sip:+5678 at 5.6.7.8;user=phone>;tag=381443
> P-Asserted-Identity: <sip:+5678 at 5.6.7.8>
> Call-ID: 1333524918-9038500 at 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 at 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 at 5.6.7.8;user=phone>;tag=381443
> To: +1234 <sip:+1234 at 1.2.3.4;user=phone>;tag=UrcX58SSF2Nrm
> Call-ID: 1333524918-9038500 at xxxxx
> CSeq: 1 INVITE
> Contact: <sip:+1234 at 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 at 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 at 1.2.3.4;user=phone>;tag=UrcX58SSF2Nrm
> To: <sip:+5678 at 5.6.7.8;user=phone>;tag=381443
> Call-ID: 1333524918-9038500 at xxxxx
> CSeq: 27563136 BYE
> Contact: <sip:+1234 at 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 at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>