Hi Alan,
I don't think of the Event package parameters as a filter in the same
sense as a filter body in the SUBSCRIBE request. The main difference
here is that it is not meaningful to think about updating the Event
package parameters for the same subscription, while it is perfectly
acceptable to modify a SUBSCRIBE filter body.
thanks,
-rohan
On Nov 12, 2008, at 6:00 PM, 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?
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
