I resolved the issue, but I not quite sure why is worked. Rather than
sending the REGISTER with t_reply(), I changed it to call route(RELAY)
which does this:
route[RELAY] {
xlog("L_NOTICE","route[RELAY] ($rm)\n");
if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) {
if (!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH");
}
if (is_method("INVITE|SUBSCRIBE|UPDATE")) {
if (!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY");
}
if (is_method("INVITE")) {
if (!t_is_set("failure_route")) t_on_failure("MANAGE_FAILURE");
}
xlog("L_NOTICE","t_relay()'ing ($rm)\n");
if (!t_relay()) {
sl_reply_error();
}
exit;
}
I thought that maybe the issue was that I was getting a 100 TRYING right
before the 401, and maybe I needed to setup a reply route as well.
However, as you can see above, MANAGE_REPLY isn't set for REGISTERs. Why
did this fix the problem?
Marc
On Mon, Mar 3, 2014 at 11:52 AM, Daniel-Constantin Mierla <mico...@gmail.com
> wrote:
> Are you sure you have set t_on_failure() for the respective transaction?
>
> Cheers,
> Daniel
>
>
> On 03/03/14 17:44, Marc Soda wrote:
>
> So I've found out that NAT has nothing to do with it. The bit about
> things working when the NAT device is removed was wrong.
>
> So my question becomes: Why would Kamailio ignore a 401 rather sending
> it to a failure route?
>
> Thanks in advance,
> Marc
>
>
> On Mon, Mar 3, 2014 at 9:10 AM, Marc Soda <ms...@coredial.com> wrote:
>
>> I forget to mention, the nat device is in front of the Kamailio servers,
>> not the endpoints.
>>
>>
>> On Fri, Feb 28, 2014 at 6:22 PM, Marc Soda <ms...@coredial.com> wrote:
>>
>>> I have a Kamailio server setup which is registers to a back end server
>>> on behalf of endpoints. The endpoints can register to Kamailio but
>>> Kamailio is failing to register to the server when I put a NAT device in
>>> front of it. Without the NAT device it works fine.
>>>
>>> The problem is the 401 that comes back seems to be ignored by
>>> Kamailio. I have a failure route setup to auth, but it is never hit. I
>>> see the 401 in onrely_route, but not the failure_route. I'm assuming it's
>>> a NAT issue because removing the device fixes the issue.
>>>
>>> Anyone have any ideas?
>>>
>>> The 401 being ignored:
>>>
>>> SIP/2.0 401 Unauthorized
>>> Via: SIP/2.0/UDP
>>> 10.0.10.11;branch=z9hG4bKe5d6.178378f7.0;received=198.XXX.XXX.XXX
>>> Via: SIP/2.0/UDP 127.0.0.1:12354
>>> ;rport=6545;received=198.XXX.YYY.YYY;branch=z9hG4bK-1879-1-3
>>> From: <sip:sip7878_s...@64.yyy.yyy.yyy>;tag=1
>>> To: <sip:sip7878_s...@64.yyy.yyy.yyy>;tag=as00e32130
>>> Call-ID: 1-1879@127.0.0.1
>>> CSeq: 2 REGISTER
>>> User-Agent: CoreDialPBX
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>> Supported: replaces
>>> WWW-Authenticate: Digest algorithm=MD5, realm="fe-c7c5-9o.domain.com",
>>> nonce="151e4f60"
>>> Content-Length: 0
>>>
>>> Thanks,
>>> Marc
>>>
>>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
> listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda
> - http://www.linkedin.com/in/miconda
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
