Hi, >Dialog termination is where I see the most potential for >confusion. I would also offer these problems are not >insurmountable. However, I would be curious to find out if >solving these problems does not reconstruct RFC 3265 in its >full glory. > >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?" > >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.
In both your examples: after the dialog is terminated, all data (e.g. buffered digits) and late messages (INFO not to launch missiles) will be discarded. That is normal SIP behavior. And, if you are going to use INFO to prevent world war III I THINK you would wait for the 200 OK before sending BYE :) Regards, Christer _______________________________________________ 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
