On 19.12.20 at 21:10 Michael Maier wrote:
On 19.12.20 at 07:45 Michael Maier wrote:
Maybe there is a problem with registering 3 numbers to the same
destination, which are handled by asterisk through the exactly same
connection (tls/tcp)?
After evaluation lots of faulty retries, I could see, that this problem
only could be seen as long as there are all 3 numbers (re)-registered at
the same time (maybe chance).
I could even find an example, where suddenly all numbers are registered
at the same time though they have been reregistered before serially (the
third number was 1:20 minutes before the other two numbers).
But suddenly, the third number was reregistered at the same time as the
other 2 numbers. Exactly at this moment, the faulty retries are
beginning. I think, there could be a problem to distinguish registration
more than two numbers to the same destination.
At the moment now, they are registering at different times (ok, 2 at the
same time, but the 3. number is registered 3 seconds later). I couldn't
see any problem right now. I'll wait and see if this assumption can be
verified.
After long time of debugging and testing, things seem to be clear now:
Asterisk / pjsip doesn't like to process more than one Register in the same
connection to the ISP. If they are not at the same time trying to reRegister, it
*seems* to work - as long as there aren't any (network) problems coming up.
But this still isn't a good idea, because it turned out, that the ISP cancels a
TCP connection after 10 seconds, if one of the numbers is unregistered (and
therefore the remaining numbers handled on this connection are broken, too).
The solution is, to use for each registered number (= trunk / endpoint) an own
transport. This seems to ensure, that each number is handled through an *own* TCP
connection. You can add several "equal" transports, which only differ in their
name (the listener port is always the same or even 0 instead of 5061, e.g. - but
the configured listener port is never used, because you don't need any listener
port as such for tcp registering to a trunk, because the complete signaling for in
and outbound calls is handled through this "dedicated line" using a random local
port from the beginning (= first Register) of the connection).
This night, by chance, there was a network problem reaching the ISP's server - and
first time, I saw a correct retry handling! The 3 sent reRegisters for the 3
numbers timed out (after ~30s) and were correctly retried 60s after the
corresponding "No response received" warning. That's how it is supposed to work I
think.
Hope that this is really the solution now.
Thanks
Michael
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
