<div class="gmail_quote">2012/8/8 Olle E. Johansson <span dir="ltr"><<a href="mailto:oej@edvina.net" target="_blank">oej@edvina.net</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":6mj">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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Summary:<br>
1) Support multiple regs over different "flows" as one contact - only send one request in a forked request<br>
2) If a flow fails, switch to secondary flow<br>
<br>
<br>
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.<br>
<br>
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 :-) )<br>
<br>
I have a presentation on outbound I could upload to slideshare if that would help.<br>
<br>
Pretty sure that Iñaki can add or correct me on this information :-)<br></div></blockquote><div><br></div><div><br></div><div>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).</div>
<div><br></div><div>My code is documented (somehow) and perhaps could help a bit. Basically:</div><div><br></div><div><br></div><div>1) OverSIP loose_route() method, which is called on the "request" instance:</div>
<div><br></div><div> request.loose_route()</div><div><br></div><div> <a href="https://github.com/versatica/OverSIP/blob/master/lib/oversip/sip/modules/core.rb#L36">https://github.com/versatica/OverSIP/blob/master/lib/oversip/sip/modules/core.rb#L36</a></div>
<div><br></div><div><br></div><div>2) OverSIP proxy.route() method:</div><div><br></div><div> <a href="https://github.com/versatica/OverSIP/blob/master/lib/oversip/sip/proxy.rb#L44">https://github.com/versatica/OverSIP/blob/master/lib/oversip/sip/proxy.rb#L44</a></div>
<div><br></div><div><br></div><div>And here the default script file which shows its basic usage:</div><div><br></div><div> <a href="https://github.com/versatica/OverSIP/blob/master/etc/server.rb#L64">https://github.com/versatica/OverSIP/blob/master/etc/server.rb#L64</a></div>
<div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":6mj">
Maybe we should schedule an IRC meeting to discuss this architecture in the #sip-router room.</div></blockquote></div><br>Sure, when? :)<div><br clear="all"><div><br></div><div>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.</div>
<div><br></div><div><br></div>-- <br>Iñaki Baz Castillo<br><<a href="mailto:ibc@aliax.net">ibc@aliax.net</a>><br>
</div>