Subject: [Sipping] Semi Regular Examples draft

From: Miki HASEBE <[email-masked]>
Date: Wed, 23 Mar 2005 17:46:41 +0900

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

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 28 Mar 2005 13:42:14 -0500

Miki,

I'll confess I haven't read the draft yet, but the examples below seem to add to the confusion rather than suppress the confusion.  I am also assuming that this is UDP-based, not TCP-based SIP.  I don't understand:

1) how you can send a 200 OK to an INVITE and then later send a 4xx response to that INVITE,

2) how you can send a CANCEL then ACK a 200 OK,
(seems like a retrans of CANCEL or a BYE would do the trick here)

3) Treat a retransmission of an INVITE as a new dialog until you have an ACK to the 200 OK with To: tag,
(retransmissions must be recognizable and handled as such, i.e. retransmit the 200 OK)

4) If you receive a CANCEL, accept that and the fact that an ACK won't be forthcoming to the 200 OK.  There is no sense trying to complete that dialog once both sides know it is going to fail.

I am having a sense of déjà vu with this thread.  Is it just me?  But agree this should be in example flows, to document the earlier conclusions.

Mike

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Miki HASEBE
>Sent: Wednesday, March 23, 2005 3:47 AM
>To: Kenneth Ho
>Cc: Cullen Jennings (fluffy); 
>[email-masked]; 'Dean Willis'; 
>[email-masked]; Gonzalo Camarillo; Hasebe Miki
>Subject: [Sipping] Semi Regular Examples draft
>
>Dear Ken Ho,
>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).
>
>3. Then the TU receives the INVITE, and the TU determines 
>whether it is the request request within a dialog. or not.
>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?)
>
>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          |
>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.
>
>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.
>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. 
>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.
>
>---
>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.
>
>   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
>
>
>This list is for NEW development of the application of SIP Use 
>[email-masked] for questions on current sip