Re: [Sip] INFO

[Paul Kyzivat <[e-mail]>]

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:[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
> 


_______________________________________________
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