> -----Original Message----- > From: Eric Burger [mailto:[EMAIL PROTECTED] > > Let us take two scenarios for the easy case of transporting user stimulus. > In the first case, the user presses a button and hangs up. Because of > normal Internet routing, the INFO (Invite-based Notification Function > Output > ;-) message arrives after the BYE arrives. What to do? What if the > button > pressed was "don't launch missiles?"
And what happens if the Bye gets to the far end before a 2833 event? Improbable but not impossible. I would expect an application providing a "don't launch missiles" type user input to provide a "missile launch order confirmed" that the user would wait to hear before hanging up. ;) > In the second case, the application is using digit maps, because the > application developer realizes that 1100 bytes of SIP headers to transport > one byte of user stimulus information is stupid. The device buffers some > digits, but the user hangs up. What does the endpoint do? Does it send > the > collected digits? Does it eat the collected digits? Any argument other > than an explicit negotiation (like KPML does) is not going to work in the > general case. This is because if we say, for DTMF, "always send buffered > digits," then what we are really saying is, "always send what you have > before the dialog terminates." I could easily envision packages that > would > have tons of state that is immediately irrelevant at dialog termination. > Dumping tons of bytes on the network again totally defeats the "We want > this > because it is lightweight" argument. I'm not sure whether whomever writes a info-dtmf event package someday would define it to support digit maps or not... my guess is they would not. But even if they did, I would assume the digits would be discarded in such a case, and defined to do so. So what? The user hung up, without pressing a sequence of digits that matched a map. What's wrong with discarding the digits? -hadriel _______________________________________________ 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
