NTT COMWARE Hidehisa Matsutani wrote: > 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,
Yes. The general rule is, IIRC, for transactions within a dialog, you can initiate any non-INVITE transactions while other transactions are in progress, but you MUST NOT initiate an INVITE transaction while another INVITE transaction is in progress. By in progress, it means the transaction hasn't got a final response. > and UAC should terminate when it sends BYE, not when it receives 200(BYE). If by terminating you mean notifying application that the session is being tore down, then yes. But generally the session and dialog are kept alive internally by the stack until all transactions terminate, to allow the session/dialog to respond to incoming request (for the dialog) that comes because of race condition (the remote peer didn't see the BYE request before it decided to send the request). More over, the outgoing BYE may be challenged by proxy, so something (either the stack or application, depending on how the stack is modeled) has to react to this challenge and resubmit the BYE request, or otherwise you will leave the remote peer with a dangling session. Even more, you may not be able to destroy the dialog just yet. If there is an active SUBSCRIBE sessions using the same dialog, then the INVITE session will be destroyed, but the dialog and the SUBSCRIBE sessions must be left running. More on this can be found in draft-ietf-sipping-dialogusage-03 draft. > 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. First of all, you must allow transactions to complete independently. (following Jonathan's SIP mantra, "All transactions complete independently", https://lists.cs.columbia.edu/pipermail/sip-implementors/2002-March/002738.html). The BYE and re-INVITE are separate transactions, so they must complete independently. > 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? No, never. All transactions must complete. regards, -benny > 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 -- Benny Prijono http://www.pjsip.org _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
