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.
>
>
> On 10/18/07 1:48 PM, "Brian Stucker" <[EMAIL PROTECTED]> wrote:
>
> >> -----Original Message-----
> >> From: Eric Burger [mailto:[EMAIL PROTECTED]
> >> Sent: Thursday, October 18, 2007 10:17 AM
> >> To: Stucker, Brian (RICH1:AR00); Dean Willis
> >> Cc: sip; Christer Holmberg (JO/LMF); Audet, Francois (SC100:3055);
> >> Hadriel Kaplan
> >> Subject: Re: [Sip] INFO
> >>
> >> Got it in 1! Tagging the message with the context, also known as
> >> event in
> >> 3265 parlance, fixes the INFO application routing /
> context problem.
> >> I was one of the first to say we could fix INFO.
> >> In fact, I started revising Dean's draft of almost 5 years
> ago before
> >> I realized I was totally recreating SUBSCRIBE/NOTIFY.
> >>
> >> In particular, the requesting party MUST do something that
> looks like
> >> a SUBSCRIBE, outside of the INVITE? Why? Because the
> call will fail
> >> if the particular reporting, like DTMF, is no supported. If the
> >> argument is reporting DTMF is a rare occurrence for, e.g., H.323
> >> gateways, then failing a call to the H.323 gateway from a
> SIP Phone
> >> is not a desirable feature.
> >
> > It doesn't *have* to fail. You can define different levels of
> > requirement for something. I think this is being a bit too harsh.
> >
> >>
> >> The reason I decided not to go on that route is at best you save 2
> >> messages (the instant NOTIFY and 200 OK) over using 3265. At that
> >> point, might as well use 3265.
> >
> > Actually,
> >
> > You don't even have to get an immediate NOTIFY/200 to a SUBSCRIBE
> > anymore:
> >
> > http://tools.ietf.org/html/draft-ietf-sip-subnot-etags-01
> >
> > You can suppress the auto-NOTIFY to your SUBSCRIBE, but the
> > implication here is that you can't SUBSCRIBE (safely) until
> you have
> > at least an early dialog or you otherwise know that the
> subscription
> > isn't going to fork because you won't get NOTIFYs back from forked
> > dialogs that you can 481.
> >
> > Again, seems complex to do something outside of the INVITE
> itself even
> > if it's not the most flexible mechanism.
> >
> > Regards,
> > Brian
> >
> >>
> >>
> >> That said, I suppose, we could offer a "fast start" 3265.
> >> [If this has shades of H.323...] In this scenario the fact you
> >> advertise support or acceptance of particular
> INFO-packages is enough
> >> to enable a sender to send appropriately tagged INFO's to you.
> >
> > This is going to be super-confusing I think to people. Just
> use NOTIFY
> > if it looks, acts, and smells like NOTIFY.
> >
> >>
> >> Of course, if one of those INFO's fails, then I will bet
> 75% of the
> >> implementations will tear down the call. 25% will leave
> the call up
> >> and RTP port open forever.
> >
> > If your implementation is that broken what we do about INFO doesn't
> > seem relevant to increasing or decreasing the stability of
> the software.
> >
> >>
> >> I would also offer we give this mechanism a new method name, as it
> >> will NOT be backwards-compatible with INFO.
> >>
> >>
> >> On 10/15/07 11:26 AM, "Brian Stucker" <[EMAIL PROTECTED]> wrote:
> >>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Dean Willis [mailto:[EMAIL PROTECTED]
> >>>> On Oct 11, 2007, at 4:34 PM, Eric Burger wrote:
> >>>>
> >>>>> Right: "DTMF may not be the only information users want
> >> to send to
> >>>>> each other during a session." This is why one MUST
> >>>> establish multiple
> >>>>> subscription dialogs. How else would one keep track of the
> >>>> different
> >>>>> elements / local routing decisions? If you are proposing
> >>>> application
> >>>>> routing a'la P-Asserted-Service...
> >>>>>
> >>>>
> >>>> One of the arguments for INFO is that it happens in a
> >> dialog, not a
> >>>> session. That is, even if you have multiple event streams, they
> >>>> happen on the same dialog.
> >>>>
> >>>> The trick is demuxing the event streams, or in other
> >> words, figuring
> >>>> out the context for each event. INFO currently gives us
> >> nothing but
> >>>> the content- modifiers to figure this out.
> >>>> That's not enough, as has widely been argued.
> >>>
> >>> How does 3265 make this any better?
> >>>
> >>> We're talking about identifying a data blob using an event plus a
> >>> content-type instead of a supported plus a content-type for
> >> a period
> >>> of time to start and end in conjunction with the INVITE
> >> dialog (so the
> >>> subsciption-state header is mooted).
> >>>
> >>> So a NOTIFY with an event header or an INFO without an
> >> event header,
> >>> all other things being the same and the constrained
> >> semantics of the
> >>> NOTIFY usage being put forward here...
> >>>
> >>> Wouldn't it be equally valid to simply allow the INFO
> >> message to carry
> >>> an event header and say that INFO is the same as a NOTIFY with an
> >>> implicit subscription to an INVITE dialog? Isn't this
> >> pretty much what
> >>> it does already (minus the event header).
> >>>
> >>> Deep thought: Is all INFO is missing is simply the event header?
> >>>
> >>> Regards,
> >>> Brian
> >>>
> >>
> >>
> >>
> >> Notice: This email message, together with any attachments, may
> >> contain information of BEA Systems, Inc., its
> subsidiaries and
> >> affiliated entities, that may be confidential, proprietary,
> >> copyrighted and/or legally privileged, and is intended solely for
> >> the use of the individual or entity named in this message.
> If you are
> >> not the intended recipient, and have received this message
> in error,
> >> please immediately return this by email and then delete it.
> >>
> >
>
>
>
> Notice: This email message, together with any attachments,
> may contain information of BEA Systems, Inc., its
> subsidiaries and affiliated entities, that may be
> confidential, proprietary, copyrighted and/or legally
> privileged, and is intended solely for the use of the
> individual or entity named in this message. If you are not
> the intended recipient, and have received this message in
> error, please immediately return this by email and then delete it.
>
_______________________________________________
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
