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

From: "Dale Worley" <[email-masked]>
Date: Tue, 14 Jun 2005 18:18:07 -0400

All of these suggestions work, but they don't quite cover the case I'm
interested in.  Certainly, one endpoint can managed it, by sending a REFER
to the other endpoint to divert its call to the B2BUA, and then transferring
its own call.  But that's a fairly complex sequence of operations that
requires specific support in the UA.  And especially if one wants a third UA
to be able to trigger the action "remotely".  I was hoping that there was
some combination of existing SIP features that could be used to perform the
action remotely.

(In contrast, using REFER and INVITE/Replaces, a UA can do significant call
transferring.  Unfortunately, there seems to be no way to transfer a call
without causing one endpoint to be dropped permanently from the
conversation.)

Dale

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Jun 2005 18:58:51 -0400

Dale,

Then can you be more explicit about
- the starting state of all participants
- the desired end state
- what set of restrictions you want to operate under

	Paul

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 15 Jun 2005 15:11:26 -0400

> From: Paul Kyzivat [mailto:[email-masked]]
>

What I was hoping for was that this topic had been well-discussed and a good
solution was already known...

What I'd like to see runs along these lines:

Usage scenario:

1) Dialog between UAs A and B.  Ideally, A and B need no features other than
those already defined in SIP.

2) UA C decides to insert istelf "between" A and B.  (In general, C could be
the same as A or B, but in that case, it's clear how to implement it.)

3) C sends appropriate messages to A and B.  After they are executed: at UA
A, the dialog A-C has replaced dialog A-B, and at UA B, dialog B-C has
replaced dialog A-B.  C provides a media path between dialog A-C and B-C.

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.

(Oddly, if one is already in situation (3), it is straightforward for C to
transform it to (1).)

I hope that makes it clearer.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Jun 2005 19:06:34 -0400

inline.

	Paul

> solution was already known...

Not the spin you have in mind.

> the same as A or B, but in that case, it's clear how to implement it.)

The obvious question is: How would C know to do that? Either C is 
already in cooperation with A or B, or else C is operated by the user of 
A or B.

The other obvious reaction is that you are trying to institutionalize 
wire tapping. That won't make you popular. (Well, maybe with the FBI, 
but not with people here.)

> replaced dialog A-B.  C provides a media path between dialog A-C and B-C.

How about:

- C subscribes to dialog event package for both A and B
   (probably already did to know it wants to do this)
- C sends an INVITE/Replaces to A with no offer.
- A responds to the invite with offer SDP1
- C then sends INVITE/Replaces to B with SDP1
- ...

That gets you a call with C in the signaling path but not the media 
path. You can work out how to intercept the media too if you insist.

---

From: Arjun Roychowdhury <[email-masked]>
Date: Wed, 15 Jun 2005 20:27:18 -0400

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

-- 
Arjun Roychowdhury

---

From: "Dale Worley" <[email-masked]>
Date: Thu, 16 Jun 2005 09:00:18 -0400

> From: Arjun Roychowdhury [mailto:[email-masked]]
>

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.

> these are all that are needed to effect this change.

I have yet to see how to implement this operation with existing mechanisms.

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

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Thu, 16 Jun 2005 09:05:32 -0400

> but not with people here.)

One possibility is that C is the attendant console in an office PBX, and
e.g. the attendant is setting up a conference call.

Another possibility is that A's UA does not have a conference bridge
capability, but by hitting some keys, a second call can be placed from the
UA to a conference bridge device to activate it.  The conference bridge
device then needs to direct (dumb) UAs A and B to finish the conference
set-up.

> - A responds to the invite with offer SDP1

A sends BYE to B.

> - C then sends INVITE/Replaces to B with SDP1

B responds "No such dialog".

Dale

---

From: Arjun Roychowdhury <[email-masked]>
Date: Thu, 16 Jun 2005 10:32:28 -0400

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

> before its INVITE/Replaces arrives from C, the user at B perceives that the

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

---

From: "Dale Worley" <[email-masked]>
Date: Thu, 16 Jun 2005 10:54:16 -0400

> replaced by another - that is not the same as dropping call.

That's true, but only if the dialog that the Replaces refers to exists at
that moment.  But if C sends an INVITE/Replaces to A, A may manage to get a
BYE sent to B before C sends an INVITE/Replaces to B.  Thus, B terminates
the A-B dialog *before* it receives the INVITE/Replaces from C.

> To avoid this, the only thing I can

The problem with this idea is that there is no currently defined way to
instruct a UA to do this.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Jun 2005 11:46:28 -0400

> e.g. the attendant is setting up a conference call.

possible

> device then needs to direct (dumb) UAs A and B to finish the conference

Might work in some cases. But is also likely that other things will go 
amiss in this case. A-B call is on hold while calling the bridge device. 
  Depending on how it does hold, bridge may not be able to figure out 
the dialog. Or, since this requires multiple calls from A, maybe there 
is more than one call on hold and the bridge is confused about which one 
to  conference.

Nevertheless, will just assume there are plausible cases.

>>- A responds to the invite with offer SDP1

It would be very unwise of B to send the BYE at this time, since the 
invite/replaces hasn't yet succeeded and could still fail. In most 
transfer scenarios the BYE is done quite late.

> B responds "No such dialog".

If A waited, as it should, before doing the BYE, then this won't happen.

	Paul

---

From: "Dale Worley" <[email-masked]>
Date: Thu, 16 Jun 2005 11:54:58 -0400

> transfer scenarios the BYE is done quite late.

Well, once A has received the INVITE/Replaces and sent the 200, I see no
specification requirement that it cannot send the BYE on the replaced dialog
immediately.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Jun 2005 13:01:35 -0400

> specification requirement that it cannot send the BYE on the replaced dialog

I don't believe there is any specification *requirement* that it send a 
BYE at all, although that is the implication. There isn't any indication 
of when.

In this case the UA can't switch media over to the new dialog until it 
gets an answer to its offer. Until then, while it MAY send a bye on the 
old dialog it would be unwise to do so, because it then will have no 
place to send media.

Of course, some devices may be unwise. And in that case the call flow I 
suggested won't work.

	Paul