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).
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.
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 PROTECTED]>
To: <[email protected]>; <[email protected]>
Sent: Wednesday, October 26, 2005 7:29 AM
Subject: [Sip-implementors] About Exceptional Procedure draft
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
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email protected] for questions on current sip
Use [email protected] for new developments of core SIP
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
