Dear Ken Ho,
Thank you for your comments.
- Scenalio 1:
First, I explain Scenalio 1.
Scenalio 1 seems to describe about the problem which would happen when the UAS
recieves a re-transmitted INVITE after it terminates the server transaction (on
sending a 200 OK response).
I guess the Scenalio1 is described as following sequence flow.
Alice Bob
| |
| INVITE F1 |
|------------------------------->|
| 180 F2(Packet loss) |
| X<---------------------|
| |
| 200 F3(Packet loss) |
| X<---------------------| Terminate(ServerTransaction)
| |
| INVITE F4(Retransmission) |
|------------------------------->|
| |
| |
In this case, according to RFC3261, I think that the UAS performs followings
procedures:
1. At first, searching the server transaction which matches the re-transmitted
INVITE.
2. But the server transaction for the re-transmitted INVITE has terminated when
it sent 200 OK.
3. Then the TU receives the INVITE, and the TU determines whether it is the
request request within a dialog. or not.
4. But the re-transmitted INVITE doesn't match any existing dialog because it
has no To-tag value.
RFC3261 doesn't seem to describe how the TU should behave in such a situation.
(If there are written parts in RFC3261, would you let me know those?)
Please let me know if I misunderstood about this.
I think there are two ways to implement SIP UA. Such as below:
Option 1: To ignore the re-transmitted INVITE
Option 2: To handle the re-transmitted as new request INVITE assuming it is
outside of a dialog
If you choose option 2, the dialogs would be established with same Call-ID and
From-tag, but it would be established different To-tags. See the following
sequence.
Alice Bob
| |
| ini-INVITE F1 |
|------------------------------->|
| 180 F2(Packet loss) |
| X<---------------------|
| |
| 200 F3(To-tag A) |
| X<---------------------| Terminate(ServerTransaction)
| |
| INVITE F4(Retransmission) |
|------------------------------->| Make new Transaction
| 180 F5(To-tag B) |
|<-------------------------------| Establish Dialog(Early) B
| |
| 200 F6(Retransmission,F3) |
|<-------------------------------| Establish Dialog A
| ACK F7 |
|------------------------------->|
| |
| |
I think this sequence (Option 2) is not a good behavior, because a different
dialog is established when a re-transmitted INVITE received. For avoiding this
situation, I think we should consider how to distinguish the re-transmitted
INVITE.
I think it is a good idea for handling this case that TU would check From-tag +
Call-ID and branch and distinguish the re-transmitted INVITE.
Please let me know if I misunderstood about this.
And we appreciate any comments for this way of handling.
- Scenalio 2:
Next, I explain Scenalio 2.
I agree with you at the point that the call would be established nevertheless
the onhook state of SIP Phone, when it comes to be in the situation of a CANCEL
crossover.
Considering the ordinary telephone, I think this is a problem.
According to RFC3261, a UA can send BYE message after the session has been
established. So, I think it is a good idea that the UAC would send BYE
automatically just then it receives 200 OK without noticing to the user. I
would like to add the description about sending BYE message to my draft,
considering SIP Phones.
Thank you for your helpful comment.
I would like to modify the sequence as the following:
Alice Bob
| |
| INVITE F1 |
|----------------------->|
| 180 Ringing F2 |
|<-----------------------|
| |
|CANCEL F3 200 OK F4 |
|--------- ----------|
| \ / |
| X |
| / \ |
|<-------- --------->|
| |
| ACK F6 481 F5 |
|--------- ----------|
| \ / |
| X |
| / \ |
|<-------- --------->|
| |
| Both Way RTP Media |
|<======================>|
| BYE F7 |
|----------------------->|
| 200 OK F8 |
|<-----------------------|
| |
| |
If the UAC receives 2xx message to INVITE after sending CANCEL message, a
dialog would be confirmed but the session SHOULD be terminated. It would be
implemented by BYE message as described in the sequence above.
---
I would like to explain about other issues you have pointed out.
- alternative 1:
We understood that the issue you pointed out was as sequence as the following:
Alice Bob
| |
| INVITE F1 |
|----------------------->|
| 180 Ringing F2 |
|<-----------------------|
| |
|CANCEL F3 200 OK F4 |
|--------- ----------| Terminate(ServerTransaction)
| \ / |
| X |
| / \ |
| x<--- --------->|
| |
| 200 F5(CANCEL) |
|<-----------------------|
| 487 F6(INVITE) |
|<-----------------------|
| ACK F7 |
|----------------------->|
| |
| |
According to my understanding, you assume F4 200 has been lost by packet loss
or something, and you think the UAS would send 200 to CANCEL, and 487 to INVITE.
In this sequence, the UAS changes the response to 487 after sending 200 OK to
INVITE. Considering the fact that RFC3261 says server transactions would be
terminated soon after sending 200 OK, it would be difficult to choose the
option that server transactions changes the response, wouldn't it?
I don't think it would be legal that one server transaction sends different
final responses(3xx-6xx) to one request.
And Considering that the section9 of RFC3261 says that CANCELs don't affect the
final responses, I don't think it is a good idea to change 200 to 487 even
though it receives a CANCEL.
So I would like to propose such a sequence as the following:
Alice Bob
| |
| INVITE F1 |
|----------------------->|
| 180 Ringing F2 |
|<-----------------------|
| |
|CANCEL F3 200 OK F4 |
|--------- ----------|
| \ / |
| X |
| / \ |
| x<-- --------->|
| |
| 481 F5(CANCEL) |
|<-----------------------|
| 200 OK F6(INVITE) |
|<-----------------------|
| 200 OK F6(INVITE) |
|<-----------------------|
:
:
Time out
The server doesn't receive the ACK message and it re-transmits 2xx response
for 64* T1 seconds. And then, the dialog would be confirmed, but the session
SHOULD be terminated immediately.
The termination would be triggered by BYE message, but the final response to
the BYE may not get to the server. Then it is terminated with timer F.
- alternative 2:
As I have already written in Scenalio 2, I would like to add sending BYE
message to the sequence. I don't think it would become an issue that the UAC
sends BYE after the CANCEL crossover. If you think it is incorrect and we have
to deal with re-transmission, please let me know the concrete example.
Thank you, again.
Regards,
Miki Hasebe
NTT East Corporation
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
