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 PROTECTED]
04/20/2005 02:23 AM
To
Udit Goyal/C/US/[EMAIL PROTECTED]
cc
[email protected], [EMAIL PROTECTED]
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 protected]
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-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
