Hi Paul, Hi Dale, I am a little confused. I was thinking first the Re-INVITE transaction must be finished then the BYE transaction could be started.
In my understanding the scenario would look INVITE 200 OK ACK => BYE 200 OK. I was sure that there is a sentence in the RFC 3261 which I did not find. Regards, Markus [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
