Subject: [Sip] Re: [Sip-implementors] UAC behaviour

From: [email-masked]
Date: Wed, 20 Apr 2005 11:35:13 -0400

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.

    User A              B2BUA               User B         Media Server
      |                   |(1) BYE            |                   |
      |                   |<------------------|                   |
      |                   |(2) 200            |                   |
      |                   |------------------>|                   |
      |                   |                   |                   |
      |                   |                   |                   |
      |(3) INV no SDP     |                   |                   |
      |<------------------|                   |                   |
      |(4) 200 offer2     |                   |                   |
      |------------------>|                   |                   |
      |                   |(5) INV offer2     |                   |
      |                   |-------------------------------------->|
      |                   |(6) 200 answer2    |                   |
      |                   |<--------------------------------------|
      |(7) ACK answer2    |                   |                   |
      |<------------------|                   |                   |
      |                   |(8) ACK            |                   |
      |                   |-------------------------------------->|
      |(9) RTP            |                   |                   |
      | (Connected to media server, user A dials digits)          |
      |...........................................................|
      |                   |(10) BYE           |                   |
      |                   |-------------------------------------->|
      |                   |(11) 200 OK        |                   |
      |                   |<--------------------------------------|
      |                   |(12) INV no SDP    |       User C      |
      |                   |-------------------|-------->|         |
      |                   | (13) 180 Ringing  |         |         | 
      | (14)180 Ringing?? |<------------------|---------|         |
      |<------------------|                   |         |         |
      |                   |(15) 200 offer3    |         |         |
      |                   |<------------------|---------|         |
      |(16) INV offer3'   |                   |         |         |
      |<------------------|                   |         |         |
      |(17) 200 answer3'  |                   |         |         |
      |------------------>|                   |         |         |
      |                   |(18) ACK answer3'  |         |         |
      |                   |-------------------|-------->|         |
      |(19) ACK           |                   |         |         |
      |<------------------|                   |         |         |
      |(20) RTP           |                   |         |         |
      |.......................................|.........|         |

My question is what will happend for message F14.
Use agent A invite and reinvite transactions are already completed and the 
dialog is in cofirmed state. However as per application, the behaviour 
should be like calling party A is now initiating the call to user C and A 
should hear the ringback.

So if it receives provisional response, what should be the behaviour, is 
it mentioned somewhere in RFC?

-Udit

[email-masked] 
04/20/2005 02:23 AM

To
Udit Goyal/C/US/3Com@3Com
cc
[email-masked], [email-masked]
Subject
Re: [Sip-implementors] UAC behaviour

Udit,
Please excuse my ignorance but can you explain / point me to the
draft RFC that covers how this works ?. If you finish the initial A to B
call, either party hanging up sends a BYE - the session and dialog will 
end
OR did the initial call setup with pre-paid verification created a dialog
that exists beyond the A to B call | session (3PCC server is B2BUA or
something ?).

Assuming the scenario is valid a UAS can respond with a 180 and I
would expect that it could be used to quench INVITE retransmissions and
trigger local ringback.

BUT..

In the scenario you describe below using 3PCC A is being INVITEd to
setup up the new call leg between A and C, so it is the UAS for this
request. So, it will be be doing the responses - 1xx, 200 OK and therefore
it wont receive a 180 ringing at all for the effect you were looking for.

Regards - Wayne.

Udit asked:
*********************************

>I want to know what should be the behaviour of UAC after receiving 180
>response when dialog is already in confirmed state.
>I think it should process it, is this behaviour mentioned anywhere in 
RFC?
>
>
>This scenario can occur in prepaid calling card application where user A
>first calls B, and after finsihing talking, he calls another user C on 
the

>same call.
>To connect user C, we can send Re-invite to user A agent resulting in 
call

>connected between A and C as per thirdparty call control.
>
>But before the call is answered by user C, if 180 Ringing is send to user
>agent A, it should play ringback as user need to hear the ringback to 
know

>the status of the second call.
>
>-Udit
_______________________________________________
Sip-implementors mailing list
[email-masked]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

**********************************************************************
Any personal or sensitive information contained in this email and
attachments must be handled in accordance with the Victorian Information
Privacy Act 2000, the Health Records Act 2001 or the Privacy Act 1988
(Commonwealth), as applicable.

This email, including all attachments, is confidential.  If you are not 
the
intended recipient, you must not disclose, distribute, copy or use the
information contained in this email or attachments.  Any confidentiality 
or
privilege is not waived or lost because this email has been sent to you in
error.  If you have received it in error, please let us know by reply
email, delete it from your system and destroy any copies.
**********************************************************************

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

---

From: "Dale Worley" <[email-masked]>
Date: Thu, 21 Apr 2005 12:30:01 -0400

> From: [email-masked]
>

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

>       |                   |(1) BYE            |                   |

        |  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

---

From: [email-masked]
Date: Thu, 21 Apr 2005 13:05:15 -0400

Hi Dale,

Thanks for the response..
I know the only thing that we can do for this scenario is to have B2BUA 
sends REFER method so that user A can initiate new INVITE and hence it can 
act as UAC and respond to 180 ringback.

Even if we use INVITE with Replaces, it will still act as UAS and hence 
will not process 180 response.

Actually only concern is because of the exsiting architectute B2BUA has to 
keep track of different dialogs which is not generally the case in other 
protocols if he wants to implement these types of scenarios. Some 
implementations think it of as call legs (or sessions) and they dont want 
maintain two different dialogs which are more or less session for them.

As there is no mechanism to reinitialize the state of the dialog of UAC, 
you always need to send the REFER method so that UAC start a new dialog 
and hence will behave as a new call. It is a new dialog but for user its 
not a new call.

One possible quick solution was to have Aler-Info header in the Re-invite 
send to the UAC which will indicate to UAC that UAC can play ringback to 
the user, but this only solves the ringback problem. There can be other 
different scenarios.

Actually the scenario which I have discussed is very common, it can be for 
toll free calling card calls also where first the call is connected to 
voice mail server (using 2xx and not reliable provisional response) to get 
the digits and then call is connected to the actual destination party.
Basically, from SIP perspective we have to treat all these scenarios as 
like transfer where B2BUA takes the role of transferor and connecting the 
user A to different calls. I am not sure if this type of approach will 
have any repurcussions on billing issues.

-Udit

"Dale Worley" <[email-masked]> 
Sent by: [email-masked]
04/21/2005 12:30 PM

To
<[email-masked]>, <[email-masked]>
cc

Subject
[Sip] RE: [Sip-implementors] UAC behaviour

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.

|  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