8 Aug
2012
8 Aug
'12
1:50 p.m.
2012/8/8 Olle E. Johansson <oej(a)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/co…
2) OverSIP proxy.route() method:
https://github.com/versatica/OverSIP/blob/master/lib/oversip/sip/proxy.rb#L…
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(a)aliax.net>