RE: [Sip] INFO

["Brian Stucker" <[e-mail]>]

Duh. I knew I was forgetting something. I wouldn't say 2976 is a bastion
example of specificity so I figured it must be coming from somewhere
else.

However, this usecase seems to also be true of NOTIFY usage within an
INVITE dialog in the specific case of a 410 response if I read tables
1/2 correctly from the dialogusage draft. 

Why are we talking about 410 anyway? I don't think I've ever seen one
generated in the wild.

It still seems to be boiling down to whether or not you want to force
folks to explicitly SUBSCRIBE to usages within the INVITE dialog. If you
use a SUBSCRIBE you can support directionality and that's about it. I
don't think you get a cleaner idea of whether or not the dialog should
exist or not than you have over INFO+event, or an implicit subscription.


Even for DTMF digits, if you setup the call, and then made your
subscription to KPML or whatever, within the dialog, and got back a 489
it seems somewhat uncertain to me what the correct behavior at the UA
should be.

If the UA was accessing a service that required SIP signaling level
awareness of DTMF digits, it may be perfectly reasonable to kill the
call. If it instead assumes 2833 support because 2833 was accepted in
the SDP it may continue on with the call but be broken because the thing
that needs the digits isn't on the media path, etc. Or if it tried for
KPML and 2833 and killed the call because KPML was rejected, the call
may have worked fine because the KPML was being rejected in favor of
2833 by a gateway, etc.

I just don't see how you can always figure out that the application is
broken (especially with something like DTMF which has a couple ways of
doing it) and the dialog needs to end from one reporting failure. I can
definitely envision cases where you could tell, but I can also come up
with usecases (like DTMF) where it's not so clear.

Regards,
Brian 

> -----Original Message-----
> From: Adam Roach [mailto:[e-mail]] 
> Sent: Thursday, October 18, 2007 6:02 PM
> To: Stucker, Brian (RICH1:AR00)
> Cc: Eric Burger; sip
> Subject: Re: [Sip] INFO
> 
> 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