Hi,
Thank you for the response. Actually I'd like to discuss to end the
dialog, not cancelling the re-INVITE transaction. As a result, I
understand UAC can send BYE while the re-INVITE transaction is pending,
and UAC should terminate when it sends BYE, not when it receives 200(BYE).
I have a following question in the similar sequence.
What if the race condition between F1-1 and F2 happens?
If the UAC terminated the transaction when sending BYE,
it cannot send ACK for the re-INVITE. Then the response for the INVITE
may be re-transmitted.
If the UAS terminate the transaction on receiving BYE, the
re-transmission is going to be stopped. If not, the re-transmission is
continued until it expires.
I think it's okay because the dialog is successfully terminated in both
UAS and UAC. Do you think it's okay if the ACK is not transmitted in
this case?
UAC UAS
| |
The session has been already established
==========================
| |
| F1 |
|--------------------->| INVITE(Session timer refresh)
| F2 |
|----------- |
| F1-1 \ |
|<-----------\---------| 200(INVITE)
| \ |
| ------->| BYE
| F3 |
|<---------------------| 200(BYE)
Regards,
Hidehisa
On Fri, 29 Sep 2006 22:37:59 -0400
[EMAIL PROTECTED] wrote:
> From: NTT COMWARE Hidehisa Matsutani <[EMAIL PROTECTED]>
>
> (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
> | |
>
> In support of Paul -- There seems to be no reason that the UAC can't
> send a BYE while the re-INVITE is pending. (It can't send the BYE
> before getting at least a provisional response from an original
> INVITE, but that is because until it receives a response, it doesn't
> know the to-tag, and so it is impossible send a BYE within the
> dialog.)
>
> The UAC, upon receiving the BYE, will terminate the dialog. The UAC,
> upon receiving the 200 to the BYE could abandon the INVITE, I suppose,
> but it would be poor design to do so.
>
> But when the UAS receives the retransmission of the INVITE, it is
> out-of-sequence, since the UAS has already processed the BYE. So it
> must reject the INVITE with a 500 response. I believe that the
> sequence-check must be done before any semantic processing of the
> request, so it can't be argued that a 481 response is acceptable.
>
> Dale
> _______________________________________________
> 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
