< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

Re: [reSIProcate] WebSockets, Outbound and Flow tokens


...inline...

On Wed, Apr 3, 2013 at 6:06 PM, Daniel Pocock <daniel@xxxxxxxxxxxxx> wrote:


Given that WebSocket clients are largely uncontactable except via the
original connection, it really appears that there are two ways they must
work:

a) with outbound (or with the non-outbound flow token hack enabled) -
this is what the draft proposes

b) talking directly to some kind of B2BUA or SBC that keeps track of the
WebSocket client


I've been able to test case (a) quite well with repro by enabling the
flow token options in repro.config.

On the other hand, it's not quite clear how we should support case (b),
as the flow tokens don't really seem appropriate within a B2BUA.  For
example, we need to be sure that dum or resip will automatically send a
request such as BYE out to the websocket client when somebody calls
InviteSession::end().

One way to do this appears to involve making Dialog recognise when it is
instantiated for a directly connected WS peer, and keep track of the
flow, calling SipMessage::setForceTarget() when creating any new
requests that will go back on the wire.  One gotcha is that if the flow
is lost, the dialog can send no more requests to the peer.  Does this
seem like the right way to adapt DUM for this purpose, or can anybody
suggest a more desirable strategy, or should it just be avoided and all
WS peers go via a proxy?

[Scott]  I don't see a need to support b) if we can do a).  a) is also the better solution.

One additional issue that arises: repro should probably refuse to run
(and log a helpful error) if somebody enables WS but not flow tokens, or
the flow tokens should just automatically be enabled for WS peers no
matter how repro is configured.

[Scott]  I think printing an error message at startup is the best way to go.  You also need to configure the record-route URI if you enable flow tokens and you can't really do that automatically (at least for transports binding to IN_ADDRANY).

Scott
 
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel