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