There was another comment made by Jonathan that we should consider
whether to only support the server-mode and to pull the scenario where
clients PUBLISH normal dialog state information from the draft.
To summarize, there are 3 options:
1) client publishes all state changes only
2) optimization for servers that maintain call state and clients only
need to publish when seizing a line. This requires a mechanism for the
server to signal to the client that it does not need to do publish all
state changes.
3) clients only publish for line seize.
Please comment on these 3 options. The current draft describes option 2.
Jason
On Nov 19, 2008, at 1:26 PM, Alan Johnston wrote:
The draft mentions a server mode of operation, where UAs do not need
to publish normal dialog state information since the server (a call
stateful proxy or B2BUA) already knows all the dialog information.
The open issue was whether this server mode should be discussed in
the draft. All current implementations of this feature use this
mode, although the new mechanisms in the draft allow an alternative
mode without a call stateful server. As such, it is clear that we
must describe this mode in the draft.
If we are going to include both modes of operation, we need to make
sure we are not going to cause interop failures or add complexity to
the solution.
Feedback on this is most welcome.
Thanks,
Alan
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
