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
Miki HASEBE wrote:
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.
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.
It seems that UAs should send a 200 OK to the BYE, when BYE requests
from both sides cross each other.
I conclude otherwise - that you have things right in the draft now.
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?
IMO you SHOULD send an error response.
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.
In the absence of shared dialogs, I say (B).
Paul
(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 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
