Subject: [Sipping] Comments on the FSM in dialog package -05

From: Tan Ya-Ching <[email-masked]>
Date: Tue, 9 Nov 2004 14:54:28 +0100

Section 3.7.1 of draft-ietf-sipping_dialog-package-05:

1) 'If the UAC should send a CANCEL, and then subsequently receive a 487
   to its INVITE transaction, all FSMs spawned from that INVITE
   transition to the "terminated" state with the event "cancelled".'

   Surely you mean only the Proceeding or Early dialogs.

2) 'Once in the confirmed state, the call is active.  It can transition
   to the terminated state if the UAC sends a BYE or receives a BYE
   (corresponding to the "local-bye" and "remote-bye" events as
   appropriate), if a mid-dialog request generates a 481 or 408 response
   (corresponding to the "error" event), or a mid-dialog request
   generates no response (corresponding to the "timeout" event).'

   But RFC 3261 (12.2.1.2 Processing the Responses) states that :

   "If the response for a request within a dialog is a 481
   (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC
   SHOULD terminate the dialog.  A UAC SHOULD also terminate a dialog if
   no response at all is received for the request (the client
   transaction would inform the TU about the timeout.)

      For INVITE initiated dialogs, terminating the dialog consists of
      sending a BYE."

   It is stated specifically that terminating the dialog consists of
   sending a BYE. Therefore, the "error" event and "timeout"
   event in the FSM should not directly lead to the terminated
   state. Only the "local-bye" and "remote-bye" events could lead to
   the terminated state.

   To be precise, perhaps it should even be stated that :

   "If a UAC sends a BYE, and receives a 2xx response for the BYE, or
    if the BYE generates a 481 or 408 response, or if it generates no
    response, the dialog transitions to the terminated state. This
    correspond to the "local-bye" event.  If a UAS receives a BYE,
    and responds with a 2xx or 481 response, or does not respond to 
    the BYE and the BYE times out, the dialog transitions to the
    terminated state. This correspond to the "remote-bye" event."

   I think it is necessary to be precise because RFC 3261 (8.2 UAS
   Behavior) states that :

   "Note that request processing is atomic.  If a request is accepted,
    all state changes associated with it MUST be performed.  If it is
    rejected, all state changes MUST NOT be performed."

Regards,
Ya-Ching

_______________________________________________
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: Rohan Mahy <[email-masked]>
Date: Tue, 9 Nov 2004 20:19:59 -0500

Hi,

Thanks for reviewing the dialog package.  I believe that the two 
specific sections you mention are actually correct.  Please see my 
comments inline.

>    Surely you mean only the Proceeding or Early dialogs.

Yes, you are correct, but stating this is redundant, since you can only 
receive a 487 to an INVITE if all the dialogs are in Proceeding or 
Early (by definition).

>    state. Only the "local-bye" and "remote-bye" events could lead to

No, according to RFC 3261 section 12.2.1.2 which you quote above, if I 
send a reINVITE, OPTIONS, PRACK, INFO, UPDATE, or other in-dialog 
request and get a 408, timeout, or 481, then the state of the dialog 
moves to terminated.

thanks,
-rohan