< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

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


On 3/13/10 11:02, Mar 13, Scott Godin wrote:
[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.

We could always add a "something may be in the process of going wrong" or "the session might be in distress" callback or something like that. In practice, I'm not sure what the application would usefully do with this information though.

I think the current handling -- treating this response as a matter that is purely internal to the stack -- is correct.

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.

Not really. When you're in doubt regarding what response codes do what to the dialog/usage/transaction, the best place to look first is RFC 5057. Here's the relevant text for 503:

   (15) 503 Service Unavailable:  As per [RFC3263], the logic handling
      locating SIP servers for transactions may handle 503 requests
      (effectively, sequentially forking at the endpoint based on DNS
      results).  If this process does not yield a better response, a 503
      may be returned to the transaction user.  Like a 500 response, the
      error is a complaint about this transaction, not the usage.
      Because this response occurred in the context of an established
      usage (hence an existing dialog), the route-set has already been
      formed and any opportunity to try alternate servers (as
      recommended in [RFC3261]) has been exhausted by the RFC3263 logic.

In other words, a 503 only affects the transaction, not the usage or dialog.

Can anyone see a reason why it would be bad to treat 503's as a session failure?

If the element that generated the 503 implements the handling specified in RFC 5057, then it will not expect the dialog to go away. That would lead to a mismatch between the two UAs regarding their view of whether the dialog is alive.

/a