<div dir="ltr"><div>On Sun, Jan 10, 2021 at 2:46 PM Michael Maier <<a href="mailto:m1278468@mailbox.org" target="_blank">m1278468@mailbox.org</a>> wrote:</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>
That's a pretty problematic behavior. ISPs (especially Deutsche Telekom e.g.) want to tear down a tls connection if it isn't used any more (why should a connection be hold active if <br>
nobody uses it?). Therefore, after each unregister of a number, the connection is teared down after 10s by ISP. Now, asterisk or probably pjsip, reopens this connection again after <br>
about 12s. Therefore, the ISP disconnects the connection automatically after 30s again. And Asterisk reopens it again after 1 minute - and so on. That's pretty broken.<br></blockquote><div><br></div><div>Without specific information or debug I can't really say why it would be doing that. The PJSIP layer should only open a new connection when a request is actually made. For example, if qualify is enabled then that would trigger a new connection as it establishes a connection to test viability. There is no ability to state "only ever attempt a connection when an outbound registration is being performed".</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
Register multiple numbers to one destination (Asterisk 18.0.1)<br>
--------------------------------------------------------------<br>
If you register more than one number to the same destination, asterisk handles all registers through the same connection. This doesn't work (well) with all ISPs. Deutsche Telekom / <br>
AllIP e.g. supports it partly - means, you can register more than one number - but if you deregister one of it, the complete connection is dropped (because normally, they want to <br>
have for each register an own connection). Besides that, there are problems during reRegistration, if they are reRegistered all at the same time (if they are reRegistered serially, <br>
it's working - maybe Asterisk can't properly handle mutliple Registers to the same destination via same connection).<br></blockquote><div><br></div><div>Connection reuse itself is a low level PJSIP thing.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
To work around this problem, that asterisk handles all Registers to one destination through the same connection, I added dedicated transports - for each trunk an own transport (each <br>
getting an own listener port). Therefore my transports now looks like:<br>
<br>
myfw*CLI> pjsip show transports<br>
<br>
Transport: <TransportId........> <Type> <cos> <tos> <BindAddress....................><br>
==========================================================================================<br>
<br>
Transport: 0.0.0.0-tls tls 3 184 <a href="http://0.0.0.0:5061" rel="noreferrer" target="_blank">0.0.0.0:5061</a><br>
Transport: 0.0.0.0-tls2 tls 3 184 <a href="http://0.0.0.0:5062" rel="noreferrer" target="_blank">0.0.0.0:5062</a><br>
Transport: 0.0.0.0-tls3 tls 3 184 <a href="http://0.0.0.0:5063" rel="noreferrer" target="_blank">0.0.0.0:5063</a><br>
Transport: 0.0.0.0-udp udp 3 184 <a href="http://0.0.0.0:5060" rel="noreferrer" target="_blank">0.0.0.0:5060</a><br>
<br>
I'm running 4 trunks - the following 2 as example for the next problem:<br>
<br>
myfw*CLI> pjsip show registration telekomPJSIP-001<br>
<br>
<Registration/ServerURI..............................> <Auth..........> <Status.......><br>
==========================================================================================<br>
<br>
telekomPJSIP-001/sip:<a href="http://tel.t-online.de" rel="noreferrer" target="_blank">tel.t-online.de</a> telekomPJSIP-001 Registered<br>
<br>
ParameterName : ParameterValue<br>
============================================================<br>
auth_rejection_permanent : true<br>
client_uri : <a href="mailto:sip%3A%2B49...@tel.t-online.de" target="_blank">sip:+49...@tel.t-online.de</a><br>
contact_header_params :<br>
contact_user : +49...<br>
endpoint : telekomPJSIP-001<br>
expiration : 660<br>
fatal_retry_interval : 0<br>
forbidden_retry_interval : 10<br>
line : true<br>
max_retries : 10000<br>
outbound_auth : telekomPJSIP-001<br>
outbound_proxy :<br>
retry_interval : 60<br>
server_uri : sip:<a href="http://tel.t-online.de" rel="noreferrer" target="_blank">tel.t-online.de</a><br>
support_mediasec : true<br>
support_outbound : no<br>
support_path : false<br>
transport : 0.0.0.0-tls<br>
<br>
<br>
myfw*CLI> pjsip show registration telekomPJSIP-002<br>
<br>
<Registration/ServerURI..............................> <Auth..........> <Status.......><br>
==========================================================================================<br>
<br>
telekomPJSIP-002/sip:<a href="http://tel.t-online.de" rel="noreferrer" target="_blank">tel.t-online.de</a> telekomPJSIP-002 Registered<br>
<br>
ParameterName : ParameterValue<br>
=============================================================<br>
auth_rejection_permanent : true<br>
client_uri : ...<br>
contact_header_params :<br>
contact_user : ...<br>
endpoint : telekomPJSIP-002<br>
expiration : 660<br>
fatal_retry_interval : 0<br>
forbidden_retry_interval : 10<br>
line : true<br>
max_retries : 10000<br>
outbound_auth : telekomPJSIP-002<br>
outbound_proxy :<br>
retry_interval : 60<br>
server_uri : sip:<a href="http://tel.t-online.de" rel="noreferrer" target="_blank">tel.t-online.de</a><br>
support_mediasec : true<br>
support_outbound : no<br>
support_path : false<br>
transport : 0.0.0.0-tls2<br>
<br>
<br>
<br>
myfw*CLI> pjsip show endpoint telekomPJSIP-001<br>
<br>
Endpoint: telekomPJSIP-001 Not in use 0 of inf<br>
OutAuth: telekomPJSIP-001/+49...<br>
Aor: telekomPJSIP-001 0<br>
Contact: telekomPJSIP-001/sip:+49...@tel.t-o 88c72b9045 Avail 13.944<br>
Transport: 0.0.0.0-tls tls 3 184 <a href="http://0.0.0.0:5061" rel="noreferrer" target="_blank">0.0.0.0:5061</a><br>
Identify: telekomPJSIP-001/telekomPJSIP-001<br>
Match: <a href="http://127.0.0.10/32" rel="noreferrer" target="_blank">127.0.0.10/32</a><br>
<br>
<br>
myfw*CLI> pjsip show endpoint telekomPJSIP-002<br>
<br>
Endpoint: telekomPJSIP-002 Not in use 0 of inf<br>
OutAuth: telekomPJSIP-002/+49...<br>
Aor: telekomPJSIP-002 0<br>
Contact: telekomPJSIP-002/sip:+49...@tel.t- 7f03d717f5 Avail 13.425<br>
Transport: 0.0.0.0-tls2 tls 3 184 <a href="http://0.0.0.0:5062" rel="noreferrer" target="_blank">0.0.0.0:5062</a><br>
Identify: telekomPJSIP-002/telekomPJSIP-002<br>
Match: <a href="http://127.0.0.10/32" rel="noreferrer" target="_blank">127.0.0.10/32</a><br>
<br>
<br>
[root@myfw ~]# netstat -n | grep 506<br>
tcp 0 0 <a href="http://3.2.1.5:53527" rel="noreferrer" target="_blank">3.2.1.5:53527</a> <a href="http://217.0.20.195:5061" rel="noreferrer" target="_blank">217.0.20.195:5061</a> ESTABLISHED<br>
tcp 0 0 <a href="http://3.2.1.5:49161" rel="noreferrer" target="_blank">3.2.1.5:49161</a> <a href="http://217.0.20.195:5061" rel="noreferrer" target="_blank">217.0.20.195:5061</a> ESTABLISHED<br>
tcp 0 0 <a href="http://3.2.1.5:56727" rel="noreferrer" target="_blank">3.2.1.5:56727</a> <a href="http://217.0.20.195:5061" rel="noreferrer" target="_blank">217.0.20.195:5061</a> ESTABLISHED<br>
<br>
I verified via tcpdump, that each Register now uses its own connection.<br>
<br>
Next, I checked the Register packets - to telekomPJSIP-001, e.g:<br>
<br>
Via: SIP/2.0/TLS 3.2.1.5:5062;rport;branch=...<br>
^^^^<br>
Contact: <<a href="http://sip:+49...@3.2.1.5:5062" target="_blank">sip:+49...@3.2.1.5:5062</a>;transport=TLS;line=...><br>
^^^^<br>
<br>
=> this should be 5061 (because of transport 0.0.0.0-tls which refers to 5061) - not 5062 ...<br>
=> It turns out, that *all* Registers of all trunks are using port 5062 now. Why that? 5061 and 5063 is ignored completely.<br>
<br>
It doesn't change anything if rewrite_contact is on or off.<br></blockquote><div><br></div><div>The rewrite_contact option is strictly for incoming traffic. It has no bearing on outgoing traffic.</div><div><br></div><div>Conceptually it should work as you say, so it's either a bug in Asterisk or in the PJSIP transport selection code.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
<br>
There is one more point I don't understand at the moment. Each configured transport opens a listener port (you can't configure a transport w/o a listener), like 5061 e.g. Each <br>
configured trunk needs a transport. For a trunk, which only registers to an ISP, you never need this listener, because the complete signaling in both directions (in- and outbound <br>
calls) is handled through the existing connection from asterisk / random local port -> ISP / 5061 (that's why it's working anyway though the Via-entry is totally broken). Why isn't <br>
it possible to create transports w/o any listener port?<br></blockquote><div><br></div><div>PJSIP doesn't currently support this.</div><div><br></div><div>A lot of your issues come down to it being the way PJSIP currently works, as we rely on it to do such things or to support such things. Any changes as such would likely need changes in PJSIP, and then in Asterisk to use them.</div></div><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-family:tahoma,sans-serif"><div><font color="#073763">Joshua C. Colp</font></div><div><font color="#073763">Asterisk Technical Lead</font></div><div><font color="#073763">Sangoma Technologies</font></div><div><font color="#073763">Check us out at <a href="http://www.sangoma.com/" target="_blank">www.sangoma.com</a> and <a href="http://www.asterisk.org/" target="_blank">www.asterisk.org</a></font></div></div></div></div></div></div></div></div></div></div></div></div>