8 Aug
2012
8 Aug
'12
1:35 p.m.
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:
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
Hi,
I would really like to get the required Outbound support into Kamailio. There has been a
lot of discussion on Outbound recently, and I have been left a little confused as to what
is actually needed for WebSockets.
I am happy to devote a few evenings and weekends to implementing this, but I could use a
little help. If there is anyone who understands Outbound (and what Kamailio does and
doesn't support with regards to Outbound) a short (bullet-point?) list of what is
currently missing would be great.
Also, if anyone can point me to some clients (both WebSockets and TCP) that support
Outbound so I have something to test with, that'd be a great help too.
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 list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev