[sr-dev] Kamailio WebSockets and Outbound

[Iñaki Baz Castillo]

2012/8/8 Olle E. Johansson <oej at edvina.net>

> Outbound in general is based on having at least two edge proxys in front
> of your location server. The client opens connections (TCP/TLS/UDP) to both
> and is responsible for maintaining it. If it fails, the client needs to
> re-open the connection.
>
> Client sends Contact with parameters instance-id being the same and reg-id
> being different. The location server/registrar needs to recognize that this
> registration is the same registration over two different paths. The edge
> proxys adds a flow-token and a path header to the registration.
>
> Now, for outbound requests only one flow is used. If that fails, we should
> failover to the other flow. The spec is a bit unclear on how to handle
> in-dialog situations, but this apply to out of dialog requests and
> dialog-creating requests.
>
> Summary:
> 1) Support multiple regs over different "flows" as one contact - only send
> one request in a forked request
> 2) If a flow fails, switch to secondary flow
>
>
> In Kamailio terms we would need a new view on destination set with a
> hierarchy - say a call forks to two AORs and they have two registrations
> over two flows, ending up with four contacts should in this case mean that
> t_relay creates two branches with a "failover" set. We need to discuss how
> to get this into our architecture without breaking serial forking with
> q-values and stuff like "forwarding to voicemail". t_relay and forward
> needs a new failure code for "failed outbound flow" so we can check if
> there's an alternative flow active before failing to voicemail or sending
> congestion. Like in your websockets code we may also want to be able to
> check states of connections in the config script and react upon those
> states, maybe be able to check over the RPC interface as well for
> management.
>
> With dual stack we could have four contacts over four flows - two per
> address family - for the same instance-id, i.e. the same device. (just had
> to add a comment about IPv6 :-) )
>
> I have a presentation on outbound I could upload to slideshare if that
> would help.
>
> Pretty sure that Iñaki can add or correct me on this information :-)
>


Hi, I think that it's also important the way in which Outbound requries a
flow token being added to the Record-Route / Path header (even more than
the failover registration mechanism defined in Outbound).

My code is documented (somehow) and perhaps could help a bit. Basically:


1) OverSIP loose_route() method, which is called on the "request" instance:

      request.loose_route()


https://github.com/versatica/OverSIP/blob/master/lib/oversip/sip/modules/core.rb#L36


2) OverSIP proxy.route() method:


https://github.com/versatica/OverSIP/blob/master/lib/oversip/sip/proxy.rb#L44


And here the default script file which shows its basic usage:

  https://github.com/versatica/OverSIP/blob/master/etc/server.rb#L64




> Maybe we should schedule an IRC meeting to discuss this architecture in
> the #sip-router room.
>

Sure, when? :)


PS: I will open a new thread asking about Path support in Kamailio (I mean
Kamailio *adding* a Path header). If it's not implemented it should be VERY
easy to implement.


-- 
Iñaki Baz Castillo
<ibc at aliax.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20120808/c834f80e/attachment.htm>