Re: [Sip] INFO

[Adam Roach <[e-mail]>]

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:[e-mail]] 
>> 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip