Hi, >>There are already problems which 199 CAN solve, without any >>other work. > >And those are? > >They should be clearly described. All I hear is examples of things where >199 is not sufficient (e.g., Media choosing, HERFP).
I have tried to describe examples not related to media choosing. One example is related to in-band procedures (e.g. ICE, in-band security negotiations). At least in the mobile world those can consume radio- and battery resources, so it is good to be informed about terminated dialogs as soon as possible, without having to detect it using re-transmission failures etc. Another example in the mobile world is related to codecs and DSP resources. If you have negotiated codec X only for one early dialog, and that dialog is terminated, you know that you can free the codec X resources (you can do that without having to be able to associate media with dialogs) and e.g .. allow reservation of other codecs needed for other dialogs. Especially when we move into the world of multimedia, using video etc, this kind of functionality becomes important. Another example in the mobile world is radio resources. In case of forking and multiple stream there may not be possible to allow early media on all dialogs, so some dialogs may e.g. be set to "inactive". It is then very useful to know when a dialog is terminated, so that media can be allowed on other dialogs. How those inactive decissions are made is based on local policy etc, but 199 provides a tool which is useful for taking those decissions. Due to the cases above, and others, terminals may restrict the number of accepted SIP dialogs, so by knowing when one dialog has been terminated it can accept another dialog. These are not theoretical issues, but problems that exist today. Maybe not in your PC with unlimited memory, connected to fixed access with unlimited bandwidth, but in some other places :) >If SRTP actually solves the problem for media choosing, then let's state it in >the >document. Sure, I can do that. Regards, Christer _______________________________________________ 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
