[reSIProcate] [recon-devel] Subscription not expiring at client-side

[Scott Godin]

[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 at inovax.com.br>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 at resiprocate.org
> List Archive: http://list.resiprocate.org/archive/recon-devel/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20100313/9a686f37/attachment.htm>