Section 4.1 states
Each such standalone REFER transaction MUST use a new (unique)
Call-Id header field value.
I think you can hedge on this a bit and put several successive
standalone REFERs (to the same target) in the same dialog, as long as
you're careful to increment CSeq and use the right tags. Or does that
depend on the target UA keeping state that we can't be assured that it
keeps?
Section 4.2
A REFER request triggering a request which is in a dialog MUST
always place a Contact URI in the Refer-To header.
More specifically, it must use the Contact URI used by the remote UA
in the target dialog.
Section 4.3
For example, the controller might want the Refer-Receiver to send a
BYE, CANCEL, or response to an INVITE in the context of a dialog
created with INVITE.
I don't expect UAs to handle "method=CANCEL" given the unique
requirements on using CANCEL: There seems to be no way for the target
UA receiving a REFER with method=CANCEL to determine which outstanding
request within the target dialog is to be canceled.
Section 4.4
A complete solution to remote call control will require that these
primitives are addressed as well:
[...]
Merge sessions
Remote merging of sessions can be done with existing primitives: If
the target UA <[EMAIL PROTECTED]> has two dialogs (dialogA, dialogB) with
two remote UAs (<[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>), then the
dialogs can be merged by sending:
REFER [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
Refer-To: [EMAIL PROTECTED]&[EMAIL PROTECTED]
Target-Dialog: dialogB
(where [...] represents the nested escaping needed to make this work).
which causes the target to send a REFER within dialogB:
REFER [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Refer-To: [EMAIL PROTECTED]
which causes remote B to replace dialogB with the dialog generated by:
INVITE [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Join: dialogA
This newly created dialog is mixed at the target with existing
dialogA.
Section 5
The "response=xxx" parameter seems to be a nice concept, but if there
are multiple outstanding requests in the target dialog, which one is
the UA to send the response to?
Dale
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
