[Spce-user] TLS support for peer registrations via sems / reg_agent.conf.tt2
nix at binaryboy.net
nix at binaryboy.net
Thu Mar 24 07:55:34 EDT 2016
I've been attempting to configure TLS registration to a 3rd party peer via sems and associated reg_agent.conf.tt2.
While I am able to register with the peer using TLS:
the problem lies in the partly hardcoded 'Contact:' field, always specifying UDP transport. I've modified the contact field but transport is always overridden with UDP (also note lb.tls.port):
contact=sip:[% sip_ext_ips.0 %]:[% kamailio.lb.tls.port %];transport=tls
So while the registration exchange itself is secure, any inbound calls from that peer are not (with the standard contact= config) or simply do not work (UDP to lb TLS port 5061).
Further, when I modify the peering server config (via admin GUI) to use TLS over port 5061, inbound calls then fail with SPCE sending "407 Proxy Authentication Required" to the peer.
I've tried adding another peering server (to same 3rd party peer) with lower priority and UDP/5060 but then the peer has two registrations, sometimes inbound calls work, often they do not.
What to do?
This is probably more a question for the dev mailing list but why not use the Kamailio UAC module for UAC registrations? The uacreg db can store all peer registrations and is automatically maintained by the kamailio process. As far as I can tell, all that is required is the glue-code/config to maintain the uacreg table and route the registration message flow - bye-bye reg_agent.conf.tt2 manual config!
I've had this working previously with a single kamailio install, but SPCE is a much bigger beast with a lb, proxy, b2bua, etc. which i'm figuring out as i go, so any pointers would be greatly appreciated. I can imagine the kamailio proxy would look after this? I have created the uacreg table (and a row in the version table for uacreg) with a single entry but no-go yet (routing issue). When that is sorted out, I hope I don't run in to issues with CSeq inc (which appears to only affect registrations, not invites if using dialog module) and from the logs I can see that qop auth is being used with this particular peer, not qop auth-int which the uac module does not support... see: http://kamailio.org/docs/modules/devel/modules/uac.html
Does this sound reasonable?
Did I miss something?
Can sems contact field actually be modified to specify ;transport=tls ?
More information about the Spce-user