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

[Arjun Roychowdhury <arjunrc at gmail.com>]

On 6/16/05, Dale Worley <dworley at pingtel.com> wrote:
> > From: Arjun Roychowdhury [mailto:arjunrc at gmail.com]
> 
> In any case, I would expect that it would require C to know the dialog-info
> (Call-Id, to-tag, from-tag) for the A-B dialog.  But we have already agreed
> that the dialog-info is sensitive and should only be known by UAs that have
> the right to intervene in the dialog -- If C knows the the dialog-info, it
> can use existing mechanisms to hijack the dialog in various ways.  There are
> no *new* security/privacy concerns here.

Discovering dialog-identifier is not the security concern - I assume
that will already be covered by the authentication required for C to
subscribe to A/B's dialog-state in the first place. Being able to
hijack an existing session between A&B  without their consent is the
security concern. If you don't require that C 'takes over without A
and B knowing and possibly rejecting' then this point is moot.

> > If you want C to indicate to A & B that its a dialog replacement, then
> > C can send invites with the replaces header
> 
> It could, but consider what happens when A processes the INVITE/Replaces --
> It sends a BYE on the A-B dialog.  If B receives the BYE and processes it
> before its INVITE/Replaces arrives from C, the user at B perceives that the
> call was dropped.

No - If B receives a Replaces header with an INVITE (either from C or
A), that is an indication to B that the existing dialog is being
replaced by another - that is not the same as dropping call. The
latter would imply that B is unaware that the new call  C-B is
'related' to the previous A-B.
If you are concerned that the BYE will result in an 'audio restart' or
break, well, that depends on how B manages its media streams. If you
look at the suggested callflow in 4.10 of the conferencing-scenario
draft, you would notice that on receiving the INVITE with replaces, B
switches RTP media streams to the replaced call and _then_ sends BYE
out. From a behaviour perspective, if a UA receives an INVITE
replaces, it should know that it needs to switch the media stream (if
it accepts this redirection) as opposed to shutting it down/clearing
local microphone interfaces/releasing media resources etc and
restarting all over again (to reduce the infamous crackle-and-pop
effect of audio)

There could be a possible sync issue if C were to send INV(replaces)
to A and B. For some reason one of them don't get it before the other
sends them a BYE for A-B or B-A. To avoid this, the only thing I can
think of is the C does not invite both A & B instead it just invites
one party and the other invites his peer - this is again within the
parameters of the conferencing extensions for SIP - just that I am not
sure if in your scenario, you are willing to put the intelligence into
the UA to be able to send a replaces to its peer if it is switching a
dialog .

regds
arjun



-- 
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