Re: [Sipping] Inserting a B2BUA into an existing dialog

[Arjun Roychowdhury <arjunrc at gmail.com>]

Not sure I followed your thought below. If A and B already implement
the standards required (REFER/INVITE/Replaces/dialog events etc) then
these are all that are needed to effect this change.

However, if C wants to break into a call between A & B when it was not
in the path to begin with, it _must_ happen with the consent of the
participants. If not, imagine how simple it would be for me to break
into someone's private conversation and start a recording process.

Let's assume a practical case (mix of local policy and SIP)

1. A wants to make a call to B. The call passes through some local
policy servers where it is 'marked' that A is now speaking with B -
the call gets connected directly with no B2B in between.

2. A little while later, into the conversation, some local policy gets
triggered which now requires the existing A-B conversation to
'migrate' to a 'centrally hosted conference' (non SIP policy trigger)

3. As as result of this, "C"  could just send a regular INVITE to both
A and B with and isFocus contact asking A and B to join its
conference. It cannot, however, force them into joining the conference
- it must be co-operative, since C was not in the path in the first
place (and if it could, refer to security concerns above)

If you want C to indicate to A & B that its a dialog replacement, then
C can send invites with the replaces header - the dialog ID could have
been recovered using the dialog event pkg (or even 'picked up' from
local 'state' if A and B don't support the event package - but then
the 'discover of the dialog ID' becomes a backend provisioning issue
and not of SIP)

regds
arjun

On 6/15/05, Dale Worley <dworley at pingtel.com> wrote:

> Trivially, we could assume that UA A knows how to implement the appopriate
> messages to B, etc., and that this facility in A can be triggered by a
> message from C.  But that is really ugly.  I'd like to assume that A and B
> provide no more facilities than are already defined in SIP (e.g., REFER,
> INVITE/Replaces, dialog events, etc.), and that C can use these operations
> to effect this transformation.
> Dale
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sip at ietf.org for new developments of core SIP
> 


-- 
Arjun Roychowdhury

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP