comment near end.
[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.
Its only out of sequence if the earlier reinvite was lost. If the
earlier reinvite had been received and is in progress, then the
retransmission won't be seen as out of sequence.
> 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.
Assuming the reinvite had been previously received, and there is a
transaction active, a variety of responses may be possible:
- upon processing the BYE and tearing down the dialog usage, the UAS
could just send a 487 to the reinvite to get rid of it. That would make
sense if the reinvite had already been identified as part of the dialog
usage and was in progress.
- if for some reason the reinvite had not yet been associated with the
dialog usage, and the BYE is processed ahead of it, then when the
reinvite is finally processed there will be no corresponding dialog
usage, but there might still be a dialog. If so, a 481 might be returned
indicating no matching usage.
-- OR, this could be treated as a new invite within an existing dialog,
and so be treated as a new call. (This is not a recommended behavior and
clearly has a bad result here.)
-- OR, if the dialog itself has gone away, a 481 would be the right
return value.
Paul
> 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
