aayush bhatnagar wrote:
If you send an in dialog request (REFER in our case), then you cannot
decouple its semantics with the existing dialog usage.
You say "*the* dialog usage" as if there can be only one. There could be
more than one. It might be coupled to:
- the *only* existing usage
- to *one* of several existing usages
- to *none* of the one or more existing usages
For instance, I could have a dialog with just an INVITE usage (the
common case) and within that dialog send a REFER of a MESSAGE. That
MESSAGE really has nothing to do with the INVITE usage.
So saying that
even if i send a REFER within an existing dialog, and still decouple
it from the existing dialog usage will not be possible.
If there were such a requirement, then REFER should have been sent as
a standalone dialog creating request outside the INVITE usage.
One can argue that it *should* have been. But that isn't the point of
this discussion. In many cases using the same dialog as been an
expedient to ensure reaching the same UA when you aren't sure the remote
target url for the dialog is in fact routable.
The recipient of the in dialog REFER will treat it like it should any
in dialog request. It has no way to decide if this request potentially
had nothing to do with the existing dialog usage.
You are being sloppy in your use of "dialog" and "dialog usage", as if
you are not familiar with RFC 5057. If you aren't, please read it.
i agree with you when you say that an indialog refer receiving a 481
would mean that the INVITE dialog has been torn down.
See my reply to Dale.
However, a refer dialog usage can also terminate, if the UAC sends a
481 in response to the NOTIFY sent by the UAS (Suppose the transaction
did not match).
You need to spell out more details of the case. If it were the *first*
NOTIFY, resulting from an in-dialog REFER, then that response would be
indicative of a screwup somewhere.
However, if there had been a prior NOTIFY on the refer subscription that
indicated that the subscription was over, and then somehow *another*
NOTIFY was sent, the 481 would be appropriate, indicating that the
refer-usage was no longer present.
This scenario may happen irrespective of whether the
REFER was within the invite usage or created its own distinct dialog.
If this happens when REFER was sent within an Invite dialog, then the
UAC will be mistaken to clean up its INVITE dialog state.
Go read 5057. The usages are to be handled separately. So this should
*not* provoke the UAC to clean up its INVITE dialog usage.
I did not understand one part in the paradox above when you said...
"A REFER within an established dialog having no invite usage to be
considered as an out of dialog REFER"
Do you mean to imply a REFER in some other Subscribe event package
dialog for example?
Yes, that is what I meant. I don't have any meaningful cases in mind,
but it is a theoretical possibility.
Paul
aayush.
On 3/25/09, Dale Worley <[email protected]> wrote:
On Mon, 2009-03-23 at 21:32 -0400, Paul Kyzivat wrote:
I would argue that the REFER is part of the INVITE usage, because REFER
in that context is intimately related to the INVITE usage -- it is
intended to transfer the INVITE usage/dialog transferred to a different
destination.
Well, I guess there is that implied association. (Part of the "do what
*I* had in mind" approach that REFER has.) Since this was never spelled
out, it could also be simply "while this isn't part of an INVITE usage,
if there happens to be an INVITE usage, please refer that one."
I guess the question is: would it be valid to send a REFER within an
existing dialog that had no INVITE usage? If it were valid, presumably
it would have the same meaning as sending one outside a dialog, except
that the resulting subscription would share the dialog. I expect that is
a usage it would be difficult to find in the wild.
That's a nice pathological case. But within the context of the current
5 possible meanings of REFER, it seems to be most parallel to the
out-of-dialog REFER.
Ah, but now I want to reconsider. Remember that REFER can take a method
name. So, rather than referring an INVITE, I could be referring MESSAGE,
OPTIONS, BYE, or maybe (????) SUBSCRIBE. In some of those cases, the
association to the INVITE usage is probably meaningless. (Of course its
meaningful for BYE.)
A fascinating possibility! But I'm not sure that we've ever defined how
a REFER within a simple INVITE dialog, specifying a non-INVITE method
should act. So there's no analog to follow.
And it seems quite safe that if the REFER receives a 481 response, the
INVITE usage must not be functional any more, since the far end of that
usage has denied that it can act on the REFER.
IIRC, 5057 decided that each dialog usage must get its own 481 before it
goes away. I don't think there are any cases where a single 481 response
can make multiple usages go away.
So the important question is whether the REFER is part of the INVITE
usage and so its 481 takes down the INVITE usage or not. That gets
especially interesting if the dialog already had both an INVITE usage
and a SUBSCRIBE usage. Does it make sense that the refer take down the
INVITE usage and leave up the SUBSCRIBE usage?
I think we're a victim of sloppy terminology here. If I send a REFER,
and the far end responds 481, then clearly the far end knows of no
INVITE usage, or otherwise it would not have responded 481. So I should
delete my belief that there is an INVITE usage. Whether we consider the
REFER in question to be "part of" the INVITE usage or not doesn't change
anything -- the 481 is evidence that the far end has no knowledge of the
usage.
However, we do have this fine paradox: If we assume that a REFER within
an established dialog that has no INVITE usage is to be treated as an
out-of-dialog REFER, then *no* REFER will receive a 481 response!
Indeed, if I send a REFER thinking that there is an active INVITE usage,
but the far end believes the INVITE usage has ended, will cause the far
end to do something (initiate an independent dialog) that is
considerably different from what I expected (transfer the current INVITE
usage).
Dale
_______________________________________________
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
