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
