[asterisk-dev] pjsip - retry handling - faulty warning message?

[Michael Maier]

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