[sr-dev] Outbound summary

[Olle E. Johansson]

9 aug 2012 kl. 16:42 skrev Peter Dunkley:

> On Thu, 2012-08-09 at 16:03 +0200, Olle E. Johansson wrote:
>> I am not in favour of a new module. Like GRUU, this is just optional behaviour based on the signalling....
>> 
> 
> My concern is just the amount of complex Kamailio configuration required for something like Outbound.  It's likely to be very messy and hard for people to use.  But if you think it is practical, I don't have a problem trying it that way.
> 
> There are going to be quite a number of (hopefully small) changes to the existing modules (path, registrar, rr, and usrloc at least) anyway.
> 	• The record_route() APIs need to be updated to make the userinfo settable from kamailio.cfg (at least you can already add parameters)

If you have a modparam for "outboundsupport" for rr this could be done automatically with the rules Iñaki showed you.

> 	• The add_path() APIs need to be updated to let parameters be added (for example ";ob" - at least you can already set the userinfo)
The same. I think it could be semi-automatic.

> 	• The logic to decide to use outbound for requests from clients should be manageable as a route
"Use outbound for requests from clients" - we get incoming requests on an existing flow. What's there to manage?

> 	• The logic to do the routing back to clients, sending the 430 etc, should be manageable as a route
Do you mean a "new route" - because then I don't follow you.

> 	• Flow token generation/decode/validation is going to be tricky as new APIs will be needed for at least base64 encode, base64 decode, HMAC-SHA1-80 - and string manipulation in kamailio.cfg is a pain.  Perhaps a set of flow-token specific APIs to wrapper all of these things (in one of the utils modules) would be better?
Why should the configuration script have to mess with generating a token. If the client indicates outbound support in a request coming in on a new flow
with no associated flow token, we can always generate one. I don't see it will ever hurt communication.

> 	• A new API will be required to determine whether a connection exists (based on input of IP address, port, and protocol) - unless trying to send the request and just catching/translating the error to a 430 is OK
COnnection management is the big thing here.

> 	• I think the new lookup(), lookup_next_dest(), managing the AVPs for this and removing bindings from the location table all do need to be new functions in the registrar module
lookup_next_flow() - it's the same destination. I agree that this has to be exposed to the routing script.

One needs to consider various cases:
- flow with UDP
- flow with TCP
- flow with TLS
- IPv4 flows
- IPv6 flows

A device could have contacts with the same instance ID registred for all of these. That set is then multiplied with the number of edge proxys used.

If the incoming request is IPv6 I might want to select an IPv6-based flow to the device and select that reg-id as the primary one.
If incoming is TLS with a SIPS uri I need to select from that criteria.

This selection could be done in the branch route if I don't like the current destination selected. Then if I get a 430 I want to be able to change and retransmit in the failure route. 



/O


> 
> Have I missed anything in that list?
> 
> -- 
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
> 
> 
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

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