[asterisk-dev] Asterisk / pjsip: Bug or feature? TCP/TLS connection is endless after unregistering the last trunk to the destination
Joshua C. Colp
jcolp at digium.com
Sun Jan 10 14:14:39 CST 2021
On Sun, Jan 10, 2021 at 4:10 PM Michael Maier <m1278468 at mailbox.org> wrote:
> On 10.01.21 at 19:56 Joshua C. Colp wrote:
> > On Sun, Jan 10, 2021 at 2:46 PM Michael Maier <m1278468 at mailbox.org>
> wrote:
> >
> >>
> >> 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
> >> 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
> >> 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.
> >>
> >
> > 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".
>
> There is no other reason (the trunk was unregistered and the pcap trace
> doesn't show any packet). And no asterisk log. The only log is from pjsip:
>
>
I don't know why or what triggered the outgoing connection then.
<snip>
>
>
> >> Register multiple numbers to one destination (Asterisk 18.0.1)
> >> --------------------------------------------------------------
> >> 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 /
> >> 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
> >> 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,
> >> it's working - maybe Asterisk can't properly handle mutliple Registers
> to
> >> the same destination via same connection).
> >>
> >
> > Connection reuse itself is a low level PJSIP thing.
>
> Is it possible to disable it?
>
The last time I checked the PJSIP documentation there wasn't, but they
could have added something.
>
> >> 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
> >> 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
> >> 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
> >> it possible to create transports w/o any listener port?
> >>
> >
> > PJSIP doesn't currently support this.
> >
> > 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.
>
> Ok, the transport without listener feature is currently not a big deal for
> me (as I'm not using them and iptables secure those useless open ports).
>
--
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20210110/174a4b2f/attachment.html>
More information about the asterisk-dev
mailing list