SiM wrote:
> Hello All,
> What is the way to CANCEL the INVITE's trigerred from a
> REFER request . ?
AFAIK there is no reliable way to do this.
> 1.) What i understand is that one way is to use the Dialog event package and
> then send a REFER request with the method=CANCEL, adding the Target-Dialog
> header, with whatever information is available from the NOTIFY. i.e a Half
> Dialog information, which is the From tag and the Call-Id, of the INVITE
> request.
This *might* work if the target understands a REFER with method=CANCEL
*and* is willing to act on it.
A fundamental problem with REFER is that the UAS must be able to
understand the intent of the request sufficiently to fill in any missing
pieces of the request *and* decide that this is a request that it should
be willing to do. (It wouldn't be wise to just issue any old request
without understanding it.)
> 2. ) Is it also possible that we use the SIP Response headers that are passed
> in the NOTIFY ( received due to the implicit subscription that the REFER
> creates ) and form the Target-Dialog header ? i.e if the REFER recepient
> sends the Call-Id, From header and To Header in the NOTIFY messages apart
> from the SIP Response line.
The issues for the UAS are the same here as with 1.
> 3.) Finally, if the REFER request creates an implicit subscription, which
> also means that there is some mapping between the REFER dialog and the INVITE
> transaction at the REFER recipient ( as the REFER recipient, sends NOTIFY'ies
> for the Invite transaction responses) , would a REFER with a method=CANCEL ,
> without a Target-Dialog header be enough ? As the REFER recipient knows
> exactly which transaction it has to CANCEL ( As there is already some mapping
> ).
Well... in the past we have assumed that a REFER in the same dialog as
an INVITE implicitly applies to the INVITE. Now you are suggesting that
a REFER in the same dialog as a refer-event subscription should apply to
the request that the subscription is watching. One might as well infer
that it applies to the refer-event subscription itself. (Doesn't make
much sense with cancel however.)
These are increasingly tenuous inferences based solely on the assumption
that the one thing you have in mind to do is the most reasonable
inference for the recipient to make. I think it is bad to make such
arbitrary assumptions. Instead, we should be making uses of REFER more
explicit in what they expect the recipient to do, so less guessing is
needed. Dale Worley has published a draft on this subject.
I think the simple answer to your question is that without some
additional standards work there is nothing you can do that will be sure
to get the CANCEL you want, unless you control the implementation of
both ends.
Paul
> Please let me know your thoughts .
>
> Thank you.
>
> Best regards,
> Simith
>
>
>
>
>
>
>
> ---------------------------------
> Here’s a new way to find what you're looking for - Yahoo! Answers
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
