thanks for prompt reply. Please see
%%%%%> my reply in-line.
Chris Boulton wrote:
Comments in-line
-----Original Message----- From: Kirill Bolshakov [mailto:[EMAIL PROTECTED] Sent: Tue 15/07/2003 13:04 To: [EMAIL PROTECTED] Cc: Subject: [Sip-implementors] Setting on Hold simultaneously
Hi, Are there any normative documents regarding the following situation: 1. The session is succesfully established between UA A and UA B. 2. Both UAs are UI-constrained hardware devices, and very similar to traditional hardware phones. 3. Users of A and B "simultaneously" (within those 100ms that are introduced by network delay) set their party on hold. Thus, from the point of view of processing SDP Offer/Answer, they both can use their copies of offers as corresponding answers (except, may be, fixing version numbers in "o"). But what from the point of view of the UI? Which one is then given the ability to take the party off hold?
>>>> This seems to be an issue for local policy at the UI. The phone might have a policy that does not
allow the other side to carry out such actions once the call is placed on hold, as it has requested a 'sendonly' SDP attribute - so might reject the request for hold (so the first one to complete - wins).
%%%%%> The issue is that both UAs (or other kind of termination equipment) will be issued UI command "Set on Hold" (by the human user) and will send out corresponding INVITEs and will receive them "simultaneously". Thus, one can't say that one UA will complete the transaction earlier or later than the other, because their clocks are not related (due to random asymmetrical network delays).
If they were in a master/slave configuration, then the situation would be manageable. And in the SIP situation, where being the caller/callee _after_ the session has been established is not equivalent to master/slave relationship, we need explicit resolution of this situation. IMHO, there seems to be a flaw.
Looks like a typical deadlock from parallel systems theory point of view. Should we go through all the standards/drafts on SIP and check? Comments are welcome!
Respectfully yours, Kirill
Chris.
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
