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 PROTECTED]> Sent by: [EMAIL PROTECTED] 04/21/2005 12:30 PM To <[email protected]>, <[email protected]> cc Subject [Sip] RE: [Sip-implementors] UAC behaviour > 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 mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
