From: SiM <[EMAIL PROTECTED]>
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.
You also need the To tag. See section 4 of RFC 4538.
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.
That is correct. But many UAs do not send the headers in a refer
event package, so that technique often does not work in practice.
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 ).
No, no such mechanism has been defined. The REFER does establish a
dialog, but the dialog usage is the subscription usage which carries
the NOTIFY messages. The REFER-sender can terminate the subscription
usage (and the dialog) with an appropriate SUBSCRIBE. But since the
dialog has no INVITE usage, an in-dialog REFER in the dialog has no
defined meaning, as in-dialog REFERs (without Target-Dialog) operate
on the INVITE usage of the containing dialog.
Dale
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
