Subject: [Sipping] About Exceptional Procedure draft

From: Miki HASEBE <[email-masked]>
Date: Wed, 26 Oct 2005 10:59:18 +0900

Folks

I update exceptional procedure draft. I would like to discuss about the
behavior of a dialog shown in the draft.

According to section 15 of RFC3261, a dialog seems to exist
until it receives a final response to a BYE or request timeout occurs.
It seems that UAs should send a 200 OK to the BYE, when BYE requests
from both sides cross each other.

However, if you receive the request like REFER, which inflences the
ongoing dialog, after you send a BYE and before the dialog terminates,
I think the request should fail and the error should be returned.
(See Exceptional Procedure draft 2.4)

These things considered, I have the following two questions.
1. When UA receives new requests (REFER or etc.) after sending a BYE and
   before receiving a final response to the BYE, may I send error responses to
   the new requests?
2. When would a dialog be terminated, A or B?
  A. At the time of receiving a final response to BYE, or a timeout of the
     BYE transaction.
  B. At the time of sending a BYE request.

(On question 1, I think UAs should send an error response to the
new request. So, UA sends an error response in the Exceptional
Procedure draft.
On question 2, a dialog is terminated on sending a BYE according to
 my interpretation. So, UA sends an error response (481) to both a
REFER or a BYE. )

Please give me your comments about this questions.
Thank you in advance.

Best 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: Kannan <[email-masked]>
Date: Wed, 26 Oct 2005 12:37:49 +0530

On question 1:

I think implementations tend to share the same dialog for multiple dialog 
usages( explicity disallowing INVITE on a dialog set up by a SUBSCRIBE 
dialog-usage).
So, it would not be prudent to sent an error response to a request when 
there is a BYE response pending. On a dialog initiated by an INVITE and 
later shared by a SUBSCRIBE usage, we could receive a NOTIFY at any point in 
time. Rejecting this may lead to an undesirable termination of the 
subscription. So IMO, the scenario is best handled by the dialog-usage.

***

Inline with the SIP architectural principles, it is compelling to see the 
dialog as a hard-wired layer, which is the final frontier as far as 'SIP' is 
concerned. Any procedures above the dialog would be dictated by the dialog 
usage. It is important  to lay down the rules with respect to dialog 
procedures unambiguously for achieving such clarity.

-Kannan
----- Original Message ----- 
From: "Miki HASEBE" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Wednesday, October 26, 2005 7:29 AM
Subject: [Sip-implementors] About Exceptional Procedure draft

> Sip-implementors mailing list
> [email-masked]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Oct 2005 11:26:20 -0400

Kannan wrote:
> On question 1:
> 
> I think implementations tend to share the same dialog for multiple 
> dialog usages( explicity disallowing INVITE on a dialog set up by a 
> SUBSCRIBE dialog-usage).
> later shared by a SUBSCRIBE usage, we could receive a NOTIFY at any 
> point in time. Rejecting this may lead to an undesirable termination of 
> the subscription. So IMO, the scenario is best handled by the dialog-usage.

Well, when I looked at the exceptional procedure draft the other day, I 
was going to make a comment about "dialog usages" and how they relate. 
But I went looking for a reference to "dialog usage" I found it only in 
Robert Sparks now expired draft. So I didn't comment on that point. But 
I did check with Robert, and today he sent out a message about his draft.

One way forward is to just consider shared dialogs out of scope for this 
exceptional procedure draft, and plan to do another one as part of, or 
in conjunction with, the dialog-usage draft.

Another way is to decide that shared dialogs are important exceptional 
procedures that should be addressed in the exceptional procedures draft. 
If so, then it needs to be enhanced to cover those cases, and progressed 
in parallel with the dialog-usage draft.

I don't have a strong preference one way or the other.

Just to close on this specific point, IMO 481 needs to be interpretted 
as "dialog usage does not exist", so that receiving one for a BYE 
doesn't affect a subscribe sharing the dialog.

	Paul

> ***
> 
> Inline with the SIP architectural principles, it is compelling to see 
> the dialog as a hard-wired layer, which is the final frontier as far as 
> 'SIP' is concerned. Any procedures above the dialog would be dictated by 
> the dialog usage. It is important  to lay down the rules with respect to 
> dialog procedures unambiguously for achieving such clarity.
> 
> -Kannan
> ----- Original Message ----- From: "Miki HASEBE" 
> <[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Oct 2005 11:52:56 -0400

I made one reply specifically about the way this relates to shared 
dialogs. The following ignores that issue and responds to the questions 
below assuming there is no shared use of a dialog.

	Paul

> until it receives a final response to a BYE or request timeout occurs.

I don't see that. Section 15 says:

                              The caller's UA MAY send a BYE for either
    confirmed or early dialogs, and the callee's UA MAY send a BYE on
    confirmed dialogs, but MUST NOT send a BYE on early dialogs.
    However, the callee's UA MUST NOT send a BYE on a confirmed dialog
    until it has received an ACK for its 2xx response or until the server
    transaction times out.  If no SIP extensions have defined other
    application layer states associated with the dialog, the BYE also
    terminates the dialog.

This only talks about the BYE, not the response to the BYE.

Section 15.1.1 says:

    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.

This is a little more confusing since it talks about certain responses 
that do result in terminating the 'session and dialog'. If leaves open 
the question of what should happen in the case of other responses. Is 
there *any* response for which it would make sense to retain the 
session? I think not.

The answer may be different for session and dialog, but only if you 
consider them to be distinct, which gets into multiple usages of 
dialogs. If we ignore that for the moment, then the dialog should go 
away when the session does.

> from both sides cross each other.

I conclude otherwise - that you have things right in the draft now.

>    before receiving a final response to the BYE, may I send error responses to

IMO you SHOULD send an error response.

>   B. At the time of sending a BYE request.

In the absence of shared dialogs, I say (B).

	Paul

---

From: Kannan <[email-masked]>
Date: Thu, 27 Oct 2005 12:13:26 +0530

Paul,

    It would be ugly and messy to incorporate dialog-usages into the 
exceptional procedures draft.

    Current implementations notwithstanding, an ideal solution would be a 
solid, "sealed" dialog layer, in which, irrespective of the dialog-usage, 
the dialog shows deterministic behaviour. This would be possible by 
discouraging implementations that share dialogs across usages. Robert's 
dialog-usage draft in this respect is important, where it would lend clarity 
to implementations and also serve as a guideline to future extensions.

    We could make assertions on the exceptional procedures draft based on 
the dialog-usage draft.

Regards,
Kannan
----- Original Message ----- 
From: "Paul Kyzivat" <[email-masked]>

> exceptional procedure draft, and plan to do another one as part of, or in 
> conjunction with, the dialog-usage draft.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Oct 2005 09:42:50 -0400

> exceptional procedures draft.

OK. As I said, I have no preference for whether that is included in your 
draft or not. Since you have a preference, that seems settled.

> solid, "sealed" dialog layer, in which, irrespective of the 
> dialog-usage, the dialog shows deterministic behaviour.

I think it is essential that there is deterministic behavior, even in 
the presence of multiple dialog usages. (Up to a point. In many places 
we explicitly tolerate a certain amount of non-determinism, together 
with rules for how to resolve the non-determinism.)

> This would be 
> possible by discouraging implementations that share dialogs across 
> usages.

*Discouraging* them solves nothing. Only outright *banning* them would 
help. But I don't think we can do that. It is too late.

In retrospect, dialog sharing should never have been introduced. But 
since it was, I think it is no good to ignore it. Instead, we should be 
firming up the specifications where they are ambiguous, so that we have 
deterministic behavior.

The current situation is bad. If an INVITE and a SUBSCRIBE are sharing a 
dialog, in some implementations a BYE will take down the whole dialog, 
while in others it will take down only the invite dialog usage and leave 
the subscribe alone.

> Robert's dialog-usage draft in this respect is important, where 
> it would lend clarity to implementations and also serve as a guideline 
> to future extensions.

Yes, I agree on that.

>    We could make assertions on the exceptional procedures draft based on 

Yes. Just using the terminology you could assert that in your examples 
there is only one usage for each dialog.

	Paul

> Regards,
> Kannan
> ----- Original Message ----- From: "Paul Kyzivat" <[email-masked]>
> 
> 
>> One way forward is to just consider shared dialogs out of scope for 
>> this exceptional procedure draft, and plan to do another one as part 
>> of, or in conjunction with, the dialog-usage draft.
>>
>> procedures that should be addressed in the exceptional procedures 
>> draft. If so, then it needs to be enhanced to cover those cases, and 
>> progressed in parallel with the dialog-usage draft.
>>