Alan Johnston wrote:
Hold on a minute - are we sure the notifier should send a 481?
I have always thought about the call-id, and tag Event package
parameters as essentially a filter - that is only send me notifies about
this particular dialog. If I subscribe to an event package with a
filter, but nothing matches the filter at that moment, would we normally
expect the subscription to be refused? Instead, I would expect an
immediate notification saying subscription is created but then not get
any notifications until the filter conditions are met. Or is my
understanding of how filtering works wrong?
I'm inclined to think of it in much this way, but there are some odd
twists to it:
- These options (or filter) also serve as data used for authentication
and authorization. Namely, possessing a valid dialog id is considered
a form of identity, that is then coupled to authorization to subscribe
with a limitation on seeing only data about that dialog.
- IMO it can be assumed that if someone supplies the notifier with what
should be one of its own dialog ids, and it isn't currently defined,
then it won't be valid in the future, and so should not serve as a
valid identification. So such a subscription should fail, except
perhaps if the subscriber can be authorized to subscribe on some
other basis.
On that basis, I can see a 403 response if the dialog id isn't valid and
the subscriber has no intrinsic authorization to subscribe.
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.
Thanks,
Paul
As such, I think it still works - if the subscriber does not receive any
notifications that match the dialog, he does not get the DERIVE
authentication he is after.
Thanks,
Alan
Rohan Mahy wrote:
Be generous in what you expect, but send a 481. ;-)
thanks,
-rohan
On Nov 12, 2008, at 2:31 PM, Adam Roach wrote:
We can argue about whether a UA should send a 481 in this case. What
we can't do is change what any given deployed UA actually does in
this case.
The difference between "should" and "does" is critical when trying to
leverage deployed behavior.
/a
On 11/9/08 4:02 PM, Rohan Mahy wrote:
Hi Jiri,
I am just saying that you if you send a 481 in this case, the
semantics are clear and consistent with some other event package
that uses call-id attributes. If you receive a 481 in this case you
can act accordingly. You could also get back a NOTIFY with a body
with full state with no dialogs, but this is less useful.
thanks,
-rohan
On Nov 9, 2008, at 1:45 PM, Jiri Kuthan wrote:
Hi Rohan,
is this our wishful thinking (I would like it too for it simplifies
few
things) only, or is there a normative reference (which I can't find).
The way I read the related stuff is I get a 200 for the SUB back, and
an "empty" NOTIFY.
-jiri
Rohan Mahy wrote:
Hi,
The UA should respond with a 481. In the case of an out of dialog
request the *meaning* of the response in this context is easy to
understand. A receiving UA realizes that it referred to some
dialog that does not exist. There are far too few response codes
for us to create a new one in this situation, and it is unlikely
that an automaton will be able to recover from this error if it
has a different code.
thanks,
-rohan
On Oct 25, 2008, at 10:26 AM, Iñaki Baz Castillo wrote:
This SUBSCRIBE arrives to Alice's UA which is not aware of that
dialog. Which
response should it reply? The flow suggests "481 Call/Transaction
doesn't
exist", but... is it correct?
AFAIK, a 481 should be replied when an *in-dialog* request
arrives to an UAS
which is not aware of that dialog. But in the above case we have
an *initial*
request and the 481 refers to the specific dialog in the "Event"
header.
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
