On 17 September 2013 14:23, Daniel-Constantin Mierla <miconda(a)gmail.com>wrote;wrote:
For the received field, you should call
fix_nated_register() when you get
the REGISTER (not for the reply). Or build the value for received_avp (
http://kamailio.org/docs/modules/stable/modules/registrar.html#idp84696)
manually in config from source ip, source port and transport.
I already have and call this route block: (WITH_NAT is defined)
# Caller NAT detection route
route[NATDETECT] {
#!ifdef WITH_NAT
force_rport();
if (nat_uac_test("19")) {
if (is_method("REGISTER")) {
fix_nated_register();
} else {
add_contact_alias();
}
setflag(FLT_NATS);
}
#!ifdef WITH_RTPBRIDGING
if (!is_method("BYE")) {
setflag(FLT_NATS);
}
#!endif
#!endif
return;
}
But there is no NAT between the phone and Kamailio, so fix_nated_register
isn't called. And there is nothing to fix about the incoming register.
But the register goes out on a different interface with a different
address. And the reply comes back on that interface.
So I presume the issue with the received/socket is that save() derived them
off the reply.
With the socket is a bit more complex in this case, with multiple network
interfaces, it can be set via a header, but msg_apply_changes() works on
reply only with development version. Practically is about using the two
parameters of registrar module:
-
http://kamailio.org/docs/modules/stable/modules/registrar.html#idp115832
It might me easier to make a patch to provide custom socket value via an
avp (like for received value), instead of header (this with header was
added long time ago for replicated registrations).
Is the subscriber having more than one phone? Or is restricted to have
only one device? IIRC, with some (old?) versions of asterisk, only one
phone was used. If it is only for one phone, you can try a different
approach:
The subscriber is not restricted to only having one phone - they can
register more than one. The downstream service supports that fine.
Kamailio can support it and I don't want to introduce a restriction since
customers often have a desk phone and also want to use a soft client on
mobile phone or similar.
- use save() with no reply flag for REGISTER
- forward the register downstream
- in failure route, if it is a reply received from downstream, use
unregister()
There will be a short time window that the phone is registered locally.
You can optimize it to call save() only when Authorization header is
present in REGISTER, as you know downstream is always authenticating.
So apart from dealing with the multiple registrations this seems like a
promising approach.
Another idea: can I do "append_branch" for a register? If so, can I turn a
register to the downstream service into a register for both the downstream
service and my local registrar?
Thanks,
Steve