re-subjecting.
On Nov 13, 2008, at 9:24 AM, Victor Pascual Ávila wrote:
On Thu, Nov 13, 2008 at 4:16 PM, Robert Sparks
<[EMAIL PROTECTED]> wrote:
On Nov 13, 2008, at 8:37 AM, Iñaki Baz Castillo wrote:
2008/11/13 Paul Kyzivat <[EMAIL PROTECTED]>:
I understand the reasoning behind 481 but I am a *bit* troubled
by it. It
is
a distinct semantic for 481, though one that is unambiguous. But
481
already
has three distinct meanings, so adding another doesn't seem like
a great
idea.
I agree, imagine if you sends such a SUBSCRIBE but as refresh
SUBSCRIBE (in-dialog request), and you get 481. What does it mean?:
a) The current SUBSCRIBE dialog doesn't exist anymore.
b) The indicated dialog in the "Event:
dialog;call_id=xxx,to_tag=xxx"
doesn't exist.
It might be a bit of a stretched analogy, but in this particular
situation:
The response to the subscribe definitely talks about the
subscription usage
(its the envelope)
Information about the pointed-to dialog ending is carried in
NOTIFYs (its
the stuff in the envelope)
IMO, RFC 4235 establishes a relationship between the envelope and
the content:
Section 3.4. Subscription Duration
"In that case, when the dialogs terminate, so too does the
subscription."
That doesn't change the answer above though.
The response to the subscribe is about the subscription-usage being
gone.
That might be the case because all the dialogs being subscribed to are
gone, but the error doesn't tell you that.
Further, when those dialogs went away, NOTIFYs would have been
generated.
The only case where you wouldn't have that information before your
resubscribed failed is if
the NOTIFYs and the reSUBSCRIBE crossed on the wire.
--
Victor Pascual Ávila
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
