I mostly agree with Adam. The place where I take exception is INFO. It
is my impression that INFO was designed for use with INVITE, and so
should be considered to be part of an invite-dialog-usage. And Robert
specified it that way in the dialogusage draft.
Paul
Adam Roach wrote:
The interaction between errors and dialog termination wasn't crystal
clear in 3261; and multiple usages within a dialog makes it even more
messy. That's why Robert has poured so much effort into
draft-ietf-sipping-dialogusage. It's an incredibly useful document the
puts crystal clarity around exactly these kinds of issues. If we had the
critical corrections process in place when it was progressing, it would
have probably been part of that process. As it is, it forms an important
adjunct to 3261.
I can't completely back out whether Eric meant to talk about two usages
in a single dialog or two different dialogs. In any case, if you get a
410 in response to a request -- including an INFO request -- the whole
dialog goes away, including all of its usages (not just the usage the
INFO was associated with -- although that's kind of a nebulous concept,
since INFO isn't inherently associated with a *usage*, merely with a
*dialog*. This is another place where INFO is underspecified; to be
fair, though, the concept of usages developed after INFO was published).
So, to be clear: if you send an INFO and get any of 404, 410, 416,
482-485, 502, or 604, then the dialog goes away. Period.
If INFO causes a 480 or 481, then the INVITE usage goes away. If the
INVITE was the last usage in the dialog, then the dialog goes away.
/a
Brian Stucker wrote:
Eric,
Where did you find the requirement that a 4xx to an INFO kills the call?
I just re-read RFC-2976, there's nothing in there that says anything
about an error response to an INFO killing the call dialog at all.
Section 2.2:
"A 481 Call Leg/Transaction Does Not Exist message MUST be sent by
a UAS if the INFO request does not match any existing call leg."
(No requirement to kill the call dialog, although it would seem
appropriate to do so)
"Other request failure (4xx), Server Failure (5xx) and Global Failure
(6xx) responses MAY be sent for the INFO Request."
(No requirement to kill the call dialog)
Sction 2.4:
"...the INFO message MUST NOT change the state of the SIP call,
or the sessions initiated by SIP."
Regards,
Brian
-----Original Message-----
From: Eric Burger [mailto:[EMAIL PROTECTED] Sent: Thursday, October
18, 2007 3:02 PM
To: Stucker, Brian (RICH1:AR00)
Cc: sip
Subject: Re: [Sip] INFO
Missing the point.
If, for some reason, a NOTIFY gets a, for example, 410 response
(instead of 200 OK), the *subscription* dialog terminates.
If an INFO gets a 410, the *call dialog* terminates.
Probably not the behavior people expect.
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
