9 Aug
2012
9 Aug
'12
6:20 p.m.
9 aug 2012 kl. 16:42 skrev Peter Dunkley:
On Thu, 2012-08-09 at 16:03 +0200, Olle E. Johansson
wrote:
If you have a modparam for "outboundsupport" for rr this could be done
automatically with the rules Iñaki showed you.
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) • 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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
---
* Olle E Johansson - oej(a)edvina.net
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden