> From: [EMAIL PROTECTED]
>
> Consider the following prepaid card application scenario::
>
> Assuming party A and B are talking and following steps occur:
> i) Party B hung up.
> ii) B2BUA end the dialog with user B and connect user A to
> media server
> using REINVITE asking for another number.
> iii) After A presses the digits, B2BUA initiates a new dialog
> for user C
> iv) When party C is ringing, B2BUA sends 180 Ringing to agent A.
IMHO, the fundamental problem is that your call flow maintains one dialog
between A and the B2BUA, but you want to reflect back to A all the call
progress indications (provisional responses) from the dialogs between B2BUA
and B, C, etc.
To avoid this, perhaps the B2BUA could issue INVITE with Replaces: to A to
"reinitialize" the dialog state with A. (In reality, replace the previous
dialog with a new one.)
>
>
> User A B2BUA User B
> Media Server
> | |(1) BYE | |
> | |<------------------| |
> | |(2) 200 | |
> | |------------------>| |
| INV with Replaces|
|<------------------|
| BYE of dialog 1 |
|------------------>|
| 200 of dialog 2 |
|------------------>|
OK, I'm too lazy to draw the entire message flow. But it seems like you
could generate suitable INVITEs with Replaces and/or REFER messages to cause
A to drop the dialog with B, establish a new one with the media server, then
drop that dialog and replace it with one to C, etc. Since each is a new
dialog, A's UA will receive and display correctly any call progress
indications.
This is also more in line with the architecture envisioned in RFC 3261.
Instead of having a B2BUA, you might be able to just use a proxy that keeps
itself in the signaling path with a Record-Route.
Dale
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
