That is fine for this particular case.
- Exact procedure for termination as per the proposal is left to the
container vendor. Wont that create non-portability? For example, early dialogs
may be terminated by CANCEL or BYE. That gives the container the freedom
to use any of those methods. But the actual call flow will be different for
Good point. For this particular case, RFC 5407 sec 2 says UAC MAY send BYE, but not recommended. So I think we should mandate sending CANCEL. If the app wishes to use BYE, it can send BYE and then call terminateDialog.
I agree that detailing exact call flow would be difficult. However, it will be
In general, this API is intended to address the majority of use cases where the apps do not care the exact call flow, but just want to terminate the dialog. If an exact call flow is desired the app can do what it does in JSR289 and handle everything itself, and not use new API.
I propose we include some interesting call flows in the main document (e.g. in an appendix), the formal model, and also test cases in the TCK so we can ascertain a certain level of consistency across container implementations. But I think it will be hard to mandate (at least in english) and test for behavior for all possible message sequences.
Re: SIP Dialog termination proposal