Subject: [BLISS] Shared Appearances Open Issue: Server Mode of Operation

From: Alan Johnston <[email-masked]>
Date: Wed, 19 Nov 2008 13:26:47 -0600

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-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: Jason Fischl <[email-masked]>
Date: Wed, 19 Nov 2008 13:39:39 -0600

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  
> 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.

---

From: [email-masked]
Date: Wed, 19 Nov 2008 20:22:26 -0500 (EST)

From: Alan Johnston <[email-masked]>

I haven't read the recent drafts, though I saw the presentation at
IETF 73.  From that, it appears to me that the only functional
difference is that in server mode, the UAs need not send the PUBLISH
requests.  Of course, we could allow the server to respond 200 to the
PUBLISHes but otherwise ignore them, but that seems a waste of network
bandwidth.  It seems that we want a way for the server to signal to
the UAs to not bother sending the PUBLISHes.

A simple way for the server to communicate this is to reject the
PUBLISHes with an appropriate error code, giving a Retry-After header
telling how long the UA should suppress PUBLISHes (for that AOR).  (I
suppose to allow changing modes of operation, we should specify that
if the phone is restarted or reconfigured, it should resume
PUBLISHes.)

Dale

---

From: [email-masked]
Date: Thu, 20 Nov 2008 14:22:39 -0500 (EST)

From: Jason Fischl <[email-masked]>

Clearly 2 is the best, if a suitable mechanism can be defined.

3 is totally unworkable in a system that has a classic (that is,
non-call-stateful, or "RFC 3261") proxy.  Since sipX has a
non-call-stateful proxy, I find it undesirable.

Dale