Q.1912.5 and RFC 3204 specify what you are trying to do at the body level rather than at the INFO transaction level.
Thus it sets the Content-Disposition header parameter handling to "required". (Note that Q.1912.5 mandates this setting whereas RFC3398 does not constrain it, essentially leaving it to the implementor). The response if this is set, and the receiving entity is not able to understand it, is to send a 415. While this is defined in RFC 3204, it does get a normative reference from RFC 3261 so I assume this parameter and its handling is mandatory to implement for all RFC 3261 implementations, rather than specific to ISUP/QSIG. 415 destroys the transaction only. Q.1912.5 doesn't seem to mandate anything useful with the 415 response in any case. In any case, if you are using INFO to encapsulate an ISUP message, I would assume you had already encapsulated such a body in an INVITE message earlier in the sequence, and therefore you would have performed the Content-Disposition / 415 sequence on an INVITE transaction already. Regards Keith > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Dean Willis > Sent: Tuesday, July 15, 2008 11:19 PM > To: Adam Roach > Cc: SIP IETF; Paul Kyzivat > Subject: Re: [Sip] Moving along with the INFO discussion > > > On Jul 15, 2008, at 4:52 PM, Adam Roach wrote: > > > On 7/15/08 4:42 PM, Dean Willis wrote: > >> > >> On Jul 15, 2008, at 2:48 PM, Adam Roach wrote: > >> > >>> On 7/15/08 2:22 PM, Dean Willis wrote: > >>>> Let's say that you send a 4XX error response to an > in-dialog INFO > >>>> (because you don't understand the Info-type of the dialog). What > >>>> does that do to the dialog? > >>> > >>> Depends on the 4XX. > >>> > >>> 404, 410, 416, 482, 483, and 485 destroy the dialog. 405, > 480, 481, > >>> 489 destroy the INVITE usage, which will usually destroy > the dialog. > >>> Pretty much any other 4XX only impact the transaction. > >>> > >>> See RFC 5057 for the details. > >> > >> So let's say you return the new 4xx response to an old-fashioned > >> sender who doesn't understand the 4xx response. It gets > treated as a > >> 400. This doesn't destroy the dialog or the dialog usage, > but kills > >> the INFO transaction. > >> > >> I have no idea what that does to the sender's state, and > I'm pretty > >> sure the sender doesn't either. Can we live with that? I'd > think it > >> would be better if it destroyed the dialog usage, but > AFAIK we have > >> no way of specifying such behavior in a backward-compatible manner > >> (unless we reuse 405, 480, 481, or 489). > > > > I should have chased down all the footnotes before I posted; as I > > mentioned in an earlier mail, 405 to INFO doesn't tear down > the usage. > > In addition to that, 489 to an INFO isn't defined, and 5057 > calls it > > reasonable to treat it as a 400. 480 and 481 are clearly the wrong > > answer. So there's not a reasonable way to leverage 5057 to > make the > > usage fail when an INFO type isn't recognized. > > > > However: I don't think we *want* the usage to fall down > when an INFO > > fails. That was a key decision we took during the > development of 5057. > > That's why I asked "Can we live with that?" > > Let's step through the use cases. > > Alice is an INFO sender for DTMF. She's talking to a new > voice mail system and starts sending it info-dtmf-relay. The > VM doesn't understand, so it 4xxes the INFO. Is Alice better > served by having the call drop or her DTMF attempt ignored? I > suspect here that "ignore", with its potential of a UI > indicator to Alice saying "My attempt to send info-dtmf-relay > failed", is probably better than the call dropping. > > How about the ISUP and QSIG use cases? I'm guessing they > would fail typically not with the new 4xx, but with the 415 > Unsupported as documented in RFC 3372. > > So it looks like you've convinced me; it's better for the > INFO failure to NOT drop the dialog or dialog usage. > > -- > Dean > > _______________________________________________ > Sip mailing list https://www.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://www.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
