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

[Paul Kyzivat <pkyzivat at cisco.com>]

inline.

	Paul

Dale Worley wrote:
> > From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
> >
> > 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
>
> What I was hoping for was that this topic had been well-discussed and a good
> solution was already known...

Not the spin you have in mind.

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

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

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

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.

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

_______________________________________________
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