Re: [reSIProcate] [recon-devel] Subscription not expiring at client-side
[Cross posting to resiprocate-devel so a wider audience can review this.]
According to RFC4028 - the session is only immediately torn down if we get a 481 or 408 response to the session refresh. All other error responses (ie. 503) should be processed as specified in 3261. For DUM onOfferRejected will be called - however recon does not pass this up the application, since it doesn't directly expose offer/answer logic to the user.
All that being said, it does seem to me that the right thing to do here is to treat a 503 response that same as a 481 or 408 and tear down the session. I'm not sure the reason why the RFC authors did not include 503's to be treated the same way as a 408, since a 503 also indicates an inability to communicate with other end.
Can anyone see a reason why it would be bad to treat 503's as a session failure?
Thanks,
Scott
On Fri, Mar 12, 2010 at 5:43 PM, Julio Cabezas
<jcabezas@xxxxxxxxxxxxx> wrote:
Hi,
How can I use Session Timers in recon ?
I am already setting it up with UserAgentMasterProfile::addSupportedOptionTag()
and also setting its mode and timeout.
I can see with Wireshark that my softphone(with recon) is correctly
doing a re-INVITE before timer expiration, but on receiving “503 Service
Unavailable” it seems not to be invoking any callback on recon API.
Thanks,
Julio Cabezas
_______________________________________________
recon-devel mailing list
recon-devel@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/recon-devel/