Alf Salte wrote:
> If you want to terminate or cancel an INVITE you should send CANCEL and
> not BYE. BYE is used to close a dialog that is established. CANCEL is
> used to close a dialog that is in the process of being established but
> has not yet been established.
If you want to stop the reinvite, then you can use CANCEL. I believe the
point here is to end the call, and the reinvite is just a distraction.
Its probably a convenience here: the phone was just hung up, and would
like to end the call, and doesn't want to wait for the reinvite to complete.
I don't believe there is anything incorrect about sending a BYE while
the reinvite is active. But it won't prevent waiting for the reinvite to
complete.
I forget the exact words Jonathan uses, but he is known to get quite
vigorous in reminding people that transactions are all independent of
one another. Every one has to complete, regardless of how they relate to
dialogs. The relationship between transactions that is provided by
dialogs and dialog usages is layered on top of the basic transaction
mechanism. Even in the case of CANCEL, the CANCEL transaction and the
transaction that is the target of the CANCEL both must complete. The
cancel at best has the effect of hurrying a final response. But it has
no effect on retransmissions or anything else.
BYE is even more loosely coupled. When the BYE is completed, the
invite-dialog-usage is destroyed, and perhaps the dialog if there were
no other usages. But incomplete transactions that were initiated in the
dialog continue.
Paul
> Also, since you cannot send CANCEL until after you have received a
> response from INVITE you shouldn't send anything until you get some
> response. If that response is 1xx then you should send CANCEL and if it
> is 2xx you should send ACK and then BYE and if it is any other response
> you should send ACK and nothing more. (the error ACK is sent in
> transaction and sent by the transaction layer so UA is not supposed to
> worry about it).
>
>
>
> I.e. you have three possible scenario:
>
>
> A ---> INVITE --> B
>
> Until you get response from B you can do nothing but retransmit the
> original INVITE until you time out. If you want to cancel the INVITE
> you can of course stop sending the retransmissions as you are not
> interested in establishing any dialog any more anyway. However, if
> one of those INVITEs you have already sent do reach B and B send a
> response you must be prepared to handle that response when it arrives.
>
> If you receive no response from B then you probaby haven't managed to
> reach B anyway so there is nothing to cancel or stop. Just stop sending
> the INVITE retransmits and you are done.
>
> When B receive the INVITE and then send you a response you get the
> three different cases.
>
> Case 1 - you receive a 1xx.
>
> A <--- 1xx ---- B
>
> At this point send a CANCEL.
>
> A ---- CANCEL ---> B
>
>
> Now, if B receive the CANCEL before it send a 200 OK, B will stop
> ringing etc and send a 487 error response to INVITE and send a 200 OK
> response to CANCEL. I.e. A will receive a 200 OK response to CANCEL
> and also receive a 487 error response to INVITE. You handle this
> case as case 3 below (receive error response).
>
> It is also possible that B send a 200 OK response to INVITE before
> it receives the CANCEL you sent. If so you should handle it as case 2
> below. I.e. you will receive a response to the CANCEL and also a
> 200 OK response to INVITE. In this case it is like case 2 below.
>
> Case 2 - receive a 2xx response.
>
> In this case you have established a dialog. Send first ACK to B and
> then send BYE to B to close the dialog.
>
> A ---- ACK ----> B
> A ---- BYE ----> B
>
> B will then send a response to the BYE and the dialog is closed.
>
> Note that due to forking it is possible that you receive several 2xx
> responses from different parties. If you want to close all of them you
> have to do this ACK then BYE for each of them. If you want to keep some
> of them and establish dialog with them and communicate with them you
> will just send ACK and then wait with BYE until you decide to close
> the connection.
>
> Case 3 - receive an error response 3xx, 4xx, 5xx, 6xx.
>
> In this case you have not established any dialog so no need to send
> BYE. However, you must send ACK but this ACK is typically sent by
> transaction layer so UA does not have to worry about it. I.e. there
> is nothing more to be done.
>
> Alf
>
>
> On Fri, 2006-09-29 at 21:39 +0900, NTT COMWARE Hidehisa Matsutani wrote:
>> Hi,
>>
>> I have some questions to implement a SIP application.
>> Please take a look on the sequence below:
>>
>> (1) What do you think of the sequence?
>> Is UAC allowed to send BYE just after it sends INVITE(session timer
>> refresh)? Or should UAC send after the INVITE transaction?
>> (In the other words, F2 should be sent after F1 transaction is completed,
>> shouldn't it?)
>>
>> (2) If the sequence is allowed, when should UAC stop the re-transmission
>> for the INVITE?
>> I think the re-transmission should be stopped when BYE transaction is
>> started, -- after F2.
>> Someone says re-transmission should be stopped after 200(BYE) is
>> received, -- after F3.
>> Which is better do you think?
>>
>> UAC UAS
>> | |
>> The session has been already established
>> ==========================
>> | |
>> | F1 |
>> |--------------------->| INVITE(Session timer refresh)
>> | F2 |
>> |--------------------->| BYE
>> | F3 |
>> |<---------------------| 200(BYE)
>> | F4 |
>> |--------------------->| INVITE(re-transmit of F1)
>> | F5 |
>> |<---------------------| 481(INVITE)
>> | : |
>> | : |
>> | F6 |
>> |<---------------------| 481(INVITE) re-transmit of F5
>> | |
>>
>> Best Regards,
>>
>> HIDEHISA Matsutani E-mail: [EMAIL PROTECTED]
>> NTT COMWARE CORPORATION
>> NWS Headquarters Core-NWS Department NW-OpS-BU IP-Service-Platform PJ
>> Tel: +81-43-211-2102 Fax: +81-43-211-5123
>>
>>
>>
>>
>> _______________________________________________
>> Sip-implementors mailing list
>> [email protected]
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
