<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">Le 19/01/2020 à 00:31, Joshua C. Colp a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAM0A2Z39-B1BgCMZYLJ_wt9WGKOKtXJMALEs2Fw-gYn2gsixiw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">On Sat, Jan 18, 2020 at 1:14 PM Administrator
<<a href="mailto:admin@tootai.net" moz-do-not-send="true">admin@tootai.net</a>>
wrote:<br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"><br>
Le 17/01/2020 à 11:54, Administrator a écrit :<br>
><br>
> Le 15/01/2020 à 19:24, Administrator a écrit :<br>
>> Hi all,<br>
>><br>
>> we face a strange behavior while connecting an
Asterisk16 instance <br>
>> with PJSIP to 2 providers: we receive error 401
Unauthorized, both of <br>
>> them having Kamailio as front-end. With other
providers -we don't <br>
>> know if they run kamailio- registration is just
fine.<br>
>><br>
>> One of the provider took a pcap and told us that
expiration was set <br>
>> to 0 that's why they don't accept the registration.
We took a pcap on <br>
>> our side when SIP packet goes out of our server and
we see that the <br>
>> expiration parameter is setted to 3600 !<br>
>><br>
>> Asterisk version is Asterisk 16.2.1~dfsg-1+deb10u1
on Debian 10 up to <br>
>> date. We also installed 16.7 from scratch, same
problem. I have to <br>
>> mention that our test asterisk is also a Debian 10
with Asterisk <br>
>> stock 16.7 and _does_ register normally against the
same provider :(<br>
>><br>
>> If someone had a clue on this, welcome.<br>
><br>
> We went a step further: when Asterisk is receiving the
401 <br>
> Unauthorized it doesn't send the Authorization back,
insteed it send <br>
> the Register back with the *same* CSeq which it
shoudn't. Pjsip is<br>
><br>
> pabx16*CLI> pjsip show version<br>
> PJPROJECT version currently running against: 2.8<br>
<br>
We removed the debian asterisk deb package and compiled from
16.7.0 <br>
source. Problem stays, still ni CSeq increment. Pjsip is<br>
<br>
pabx16*CLI> pjsip show version<br>
PJPROJECT version currently running against: 2.9<br>
<br>
Anyone on this ?<br>
</blockquote>
<div><br>
</div>
<div>Is the response actually getting to Asterisk? Does it
show up in "pjsip set logger on"? Is the REGISTER a
retransmission and thus expected to be the same?</div>
</div>
</div>
</blockquote>
<p>It become stranger and stranger: on one of the register peer we
receive in asterisk:</p>
<p>*CLI> [2020-01-19 15:23:18] WARNING[17469]:
res_pjsip_outbound_registration.c:1021
handle_registration_response: Fatal response '401' received from
'sip:<myprovider>' on registration attempt to
'sip:<myuser>@<myprovider>', stopping outbound
registration</p>
<p>On the other one:</p>
<p>[2020-01-19 15:23:46] WARNING[17469]:
res_pjsip_outbound_registration.c:801 schedule_retry: No response
received from 'sip:<other provider>' on registration attempt
to 'sip:<other user@other provider>', retrying in '60'</p>
<p>*BUT*</p>
<p>IP <other provider IP>.5060 10.1.58.14.64777: UDP, length
497<br>
E...e...6....2N$<br>
.:.... ..RQSIP/2.0 401 Unauthorized<br>
Via: SIP/2.0/UDP <our public
IP>:5060;rport=64777;branch=z9hG4bKPjdfb1d5d6-efbd-4e43-a932-252cfa0e7a9b
<br>
From: <sip:<otheruser@other
provider>;tag=743c09d7-bdf9-4579-b7be-b087b0f19a46
<br>
To: <sip:<other user@<other
provider>;tag=a4993fce1db28f0d818901aca45fc7e1-39af
<br>
Call-ID: fadecc03-31e1-50ef-b686-d1a6b7ea0eda<br>
CSeq: 49518 REGISTER<br>
WWW-Authenticate: Digest realm="<other provider>",
nonce="XiRnoo5Qbfr8xRP1yNPD+Piy/eKORSub",
qop="auth" <br>
Content-Length: 0</p>
<p>So the answer is coming back to the server but not to asterisk.
With the debian package of asterisk-16 the 401 response was
received by asterisk.</p>
<p>We now have 2 problems:</p>
<p>- why asterisk doesn't get the answer of one of the provider</p>
<p>- why when receiving the 401 from the other provider it doesn't
then the Authorization back</p>
<p>If it matter, server is a VM using ipv4 and ipv6, we have mtu
setted to 1492 and use nft for FW rules.<br>
</p>
<pre class="moz-signature" cols="72">--
Daniel</pre>
</body>
</html>