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

From: Rohan Mahy <[email-masked]>
Date: Wed, 10 Nov 2004 09:43:38 -0500

Hi,

If you want to propose specific language for a change to RFC 3261 that 
would get incorporated if we do an errata, please send a short note to 
the SIP list with the current text and the proposed text.

many thanks,
-rohan

On Nov 10, 2004, at 3:33, Tan Ya-Ching wrote:
> Hi,
>
> Thanks for your answer. My further comments below :
>
>>>   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.
>
>> 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.
>
> If that is so, why doesn't RFC 3261 quoted above simply state that
> "the dialog terminates" instead of "the UAC SHOULD terminate the 
> dialog",
> and as I pointed above, it further clarifies that "terminating the
> dialog consists of sending a BYE".
>
> For similar situation in RFC 3265 :
>
> "If a NOTIFY request receives a 481 response, the notifier MUST
> remove the corresponding subscription..."  and
> "If a subscription's destruction leaves no other application state
> associated with the dialog, the dialog terminates".
>
> There it is clear that the dialog simply terminates, with no
> further action required from the UAC.
>
> 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: Wed, 10 Nov 2004 10:33:40 -0500

Hi,

After a 481 is received on a mid-dialog request, the *local* state of 
the dialog package is that the dialog is terminated. I think the 
current language in RFC3261 is sufficiently clear to convey this.  If 
you disagree, then feel free to suggest some text.  If you don't wish 
to, don't send text. Sending a BYE or not sending a BYE at this point 
does not affect this *local* state.  The dialog package only deals with 
the local view of this state and does not comment on any other protocol 
requirements.  For example, the dialog package does not (and should 
not) comment on what happens when (for example) a 401 response to a 
mid-dialog request is received, because this does not affect the 
*local* state.

thanks,
-rohan

On Nov 10, 2004, at 10:20, Tan Ya-Ching wrote:
> Hi,
>
> Why should I do an errata when I don't think there is any error or 
> ambiquity in RFC 3261 regarding this. It says "the UAC SHOULD 
> terminate the dialog" and "terminating the dialog consists of sending 
> a BYE".
>
> The problem is that the dialog package implies that a dialog simply 
> terminates when a mid-dialog request generates a 481 or 408 response. 
> If that is the way you think it should be, perhaps you should do an 
> errata for RFC 3261.
>
> The same is with the "replace". The draft states that :
>
> "If the UAC (why not UAS?) receives a new invitation (with a Replace 
> header) which replaces the current Early or Confirmed dialog, all 
> INVITE transactions(you probably mean INVITE dialogs here) spawned 
> from the replaced invitation transition to the "terminated" state"
>
> RFC 3891 does not state that Early or Confirmed dialogs simply 
> terminate on reception of the new invitation, but the UAS has to 
> terminate the dialogs with CANCEL or BYE, as appropriate. So as far as 
> these dialogs are concerned, they are terminated by the event 
> "cancelled" or "BYE", even though the trigger for the CANCEL or BYE 
> may be "replaced".
>
> Ya-Ching
>
>
> -----Ursprüngliche Nachricht-----
> Von: Rohan Mahy [mailto:[email-masked]]
> Gesendet: Mittwoch, 10. November 2004 15:44
> An: Tan Ya-Ching
> Cc: [email-masked]; 'Jonathan Rosenberg'; [email-masked]
> Betreff: Re: AW: [Sipping] Comments on the FSM in dialog package -05
>
>
> Hi,
>

---

From: Tan Ya-Ching <[email-masked]>
Date: Thu, 11 Nov 2004 10:57:34 +0100

Hi,

If the dialog state is only maintained in the user agents, you may be right in saying that sending a BYE or not sending a BYE does not affect the state. But what if there is a state agent (eg. network agent) which is not the UA, but knows the state of the dialogs because it acts as a call-stateful proxy ? If it strictly follows RFC 3261, it cannot assume that a dialog terminates until the dialog is terminated with a BYE, and this is especially true in the case of "replace". 

Thanks,
Ya-Ching

-----Ursprüngliche Nachricht-----
Von: Rohan Mahy [mailto:[email-masked]] 
Gesendet: Mittwoch, 10. November 2004 16:34
An: Tan Ya-Ching
Cc: [email-masked]; 'Jonathan Rosenberg'; [email-masked]
Betreff: Re: AW: AW: [Sipping] Comments on the FSM in dialog package -05 

Hi,

thanks,
-rohan

---

From: "Paul D.Smith" <[email-masked]>
Date: Thu, 25 Nov 2004 09:17:27 -0000

Rohan,

I have to disagree with your response below.  RFC3261 clearly distinguishes
a BYE, which terminates an INVITE initiated dialog, from other SIP requests.
In particular, Section 12.2.1.2 is clear that a failed OPTIONS does not
terminate a dialog although it should cause the UA to terminate the dialog
by sending a BYE.

Comparisons with RFC3265 should take account of the fact that in some
respects a NOTIFY is like a BYE and _not_ like an OPTIONS.  RFC3265 and
RFC3261 are then consistent in that, if the dialog ending request (NOTIFY
or BYE) fails with 408/481, then the dialog is assumed terminated.

In conclusion, I believe that the dialog is _not_ terminated until the
BYE has completed (2XX response or 408/481) and the dialog package state 
must reflect this.

Paul D Smith
Network Protocols Group 
Data Connection Ltd (DCL)
Tel: +44 20 8366 1177  Email: [email-masked] 
Fax: +44 20 8363 1039  Web:   http://www.dataconnection.com

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]]
Sent: 10 November 2004 15:02
To: SIP Public Folder (E-mail)
Subject: Re: AW: [Sipping] Comments on the FSM in dialog package -05 

Hi,

many thanks,
-rohan