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:

...

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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

8 aug 2012 kl. 12:35 skrev Peter Dunkley:

Hi,

Your presentation would be very helpful.

http://www.slideshare.net/oej/sip2012-outbound

I think an IRC meeting with the interested parties sounds like a good idea.

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.

/O

Regards,

Peter

On Wed, 2012-08-08 at 12:18 +0200, Olle E. Johansson wrote:

...

8 aug 2012 kl. 11:55 skrev Peter Dunkley:

...

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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

-- Peter Dunkley Technical Director Crocodile RCS Ltd

---

sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

--- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden

2012/8/8 Olle E. Johansson oej@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/cor...

2) OverSIP proxy.route() method:

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

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.