** Hi, Your presentation would be very helpful. I think an IRC meeting with the interested parties sounds like a good idea. Regards, Peter On Wed, 2012-08-08 at 12:18 +0200, Olle E. Johansson wrote: 8 aug 2012 kl. 11:55 skrev Peter Dunkley: 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 :-) Maybe we should schedule an IRC meeting to discuss this architecture in the #sip-router room. /O _______________________________________________ sr-dev mailing listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev -- Peter Dunkley Technical Director Crocodile RCS Ltd _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

13.30 Swedish time today - in 15 minutes - in the #sip-router IRC channel? If that doesn't work, we'll just schedule another time.

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.