Subject: [Sipping] Semi Regular Examples draft

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

Hi Malleswara,

Comments are inline.

>  Can add other cross-overs like Re-INVITE-Re-INVITE (especially when 
> both dont  carry any SDP), Re-INVITE-UPDATE

Thank you for your comments. I would like to consider to add these examples.
Please give me some time to think about this. I want to think this over.

>  Some thoughts:
>   In Section 2.1, CANCEL cross over can result in a subsequent BYE from
>   the UAC. 

In the situation of the CANCEL crossover, 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 situation is a problem. According to RFC3261, 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.

>   In Section 2.2, for BYE cross over, I think that either of the UAs 
> can still respond
>   with a 200ok assuming that the BYE it had sent was lost and then can stop
>   waiting for a response to its BYE (cuz it doesnot make any more sense to even
>   retry the BYE)

I understood that the issue you pointed out. 
I explain clearly by using a following sequence diagram.

    Alice                     Bob
      |                        |
      | BYE                BYE |
      |---------     ----------|
      |          \ /           |
      |           X            |
      |          / \           |
      |<--------     ----> X   |
      |                        |
      |         200OK          |
      |----------------------->|
      |                        |

I think the dialog has been terminated when the server sends the BYE message, so a 200 OK message cannot be sent. It would come to be the sequence flow as the following:

    Alice                     Bob
      |                        |
      | BYE                BYE |
      |---------     ----------|
      |          \ /           |
      |           X            |
      |          / \           |
      |<--------     ----> X   |
      |                        |
      |          481           |
      |----------------------->|
      |                        |
      |       BYE              |
      |------------------> X   |
      |                        |
      |       BYE              |
      |------------------> X   |
      |        :               |
      |        :               |

I think sending BYEs repeatedly is unavoidable, because the client follows the rule of non-INVITE client transaction described in RFC3261.

Thank you, again.
Regards,
Miki Hasebe

_______________________________________________
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: Malleswara Rao Ankem <[email-masked]>
Date: Wed, 23 Mar 2005 15:02:29 +0530

Hi Hasebe,
 plz go thru the following,
Section from 3261
"15.1.1 UAC Behavior

   A BYE request is constructed as would any other request within a
   dialog, as described in Section 12.

   Once the BYE is constructed, the UAC core creates a new non-INVITE
   client transaction, and passes it the BYE request.  The UAC MUST
   consider the session terminated (and therefore stop sending or
   listening for media) as soon as the BYE request is passed to the
   client transaction.  If the response for the BYE is a 481
   (Call/Transaction Does Not Exist) or a 408 (Request Timeout) or no
   response at all is received for the BYE (that is, a timeout is
   returned by the client transaction), the UAC MUST consider the
   session and the dialog terminated."

 As i understand from the above paragraph that 
 a) its only the session that gets immediately terminated when a BYE
request is sent out by the UAC.
 b) So if the dialog still exists should not the receiver of a BYE be
able to respond it with a 200ok (even though it was waiting for a
response to a BYE that it has sent out) ???

regds
Mallesh

---

From: Miki HASEBE <[email-masked]>
Date: Mon, 28 Mar 2005 17:12:39 +0900

Hi Malleswara,

Thank you for the comment.
I understood the meaning which you pointed out and I think my understanding
is same of you.
These are my understandings from section 15.1.1 of RFC3261.
1) The session is terminated by the BYE message sending out.
2) The dialog is terminated by receiving the response to the BYE message
   or a timeout
I explain with a figure, such as below:

   Alice                     Bob
     |                        |
     |   Both Way RTP Media   |
     |<======================>|
     |                        |
     |         BYE F1         |
     |<-----------------------| Session is terminated
     |                        |
     |         200 F2         |
     |----------------------->| Dialog is terminated. BYE-transaction is 
     |                        | "Completed" , timer K starts.
     |                        |

According to this general sequence, after BYE transmission,a client is
considered to hold a dialog until it receives response message or
timer K expires.

When once BYE message is sent, the dialog must be terminated finally.
In other words, from description of RFC3261, I think that the end of a 
dialog is promised to terminate by transmission of BYE message.
But it is thought that the dialog does not terminate immediately, the
dialog terminate by receiving a response message or timer K expires.

Therefore we should need a consideration about the case when a client
receives any messages after a dialog complited. is reserved by BYE
message until a dialog is completed.

For example, the sequence which is needed consideration is reception
of the REFER signal.
It is shown in 2.4 of a semi-regular draft.
When receiving signals, such as REFER which effects on a dialog, after
a BYE message transmitted, I think it reasonable to answer so that a
dialog may not exist.

I want to add a description as discussed above about disappearance of a
dialog to a description of section 2.4 of a semi-regular draft.

Please point out, if I misunderstood RFC3261.
Let me know if you have any other comments to this proposal.

Thank you very much for your cooperaqtions.

Miki Hasebe,

---------------------------------------------------------
Miki HASEBE
Research and Development Center
NTT-east Corporation

Telephone  +81 3 5359 5104
Facsimile  +81 3 5359 4768
E-mail: [email-masked]
19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan
---------------------------------------------------------