Re: [asterisk-dev] pjsip - retry handling - faulty warning message?
Hello! On 13.01.21 at 13:44 Michael Maier wrote: > > 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: Meanwhile I could proof (on base of four transports to the same destination), that the following configuration of an individual transport for each used trunk ensures, that there are no more (re)Registering problems - even if they are done at the same time: [trunk1] type=transport protocol=tls bind=0.0.0.0:0 ^ ca_list_file=/etc/pki/tls/certs/ca-bundle.crt method=tlsv1_2 verify_server=yes allow_reload=no tos=0xb8 cos=3 [trunkn] type=transport protocol=tls bind=0.0.0.0:0 ^ ca_list_file=/etc/pki/tls/certs/ca-bundle.crt method=tlsv1_2 verify_server=yes allow_reload=no tos=0xb8 cos=3 => That's a configuration for an encrypted SIP connection. You can verify if it works correctly, by checking netstat -n | grep 5061 If you get the same amount of connections as registered trunks, configuration works as expected. 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
Re: [asterisk-dev] pjsip - retry handling - faulty warning message?
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
Re: [asterisk-dev] pjsip - retry handling - faulty warning message?
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. 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
Re: [asterisk-dev] pjsip - retry handling - faulty warning message?
On 25.08.20 at 11:13 Michael Maier wrote: Yes, that's true. While it happens extremely rarely, I wouldn't know how to trace it down. It usually runs for weeks without any problems, suddenly there are one or two entries (seldom more) and afterwards, it's fine again. Maybe I get sometime the opportunity to trace it down. Ok, the last few days now, it happened quite often. I could see pretty often (5 or more times a day) retries(!) even after 0.02 seconds. But not always. Sometimes, they don't occur even after 0.1s! Therefore, I switched on debugging and verbose output now (each level 5). What happened? No more problem now since one day ... - though there were really enough cases where the delta of the answer has been slow enough to trigger a faulty resend. 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)? Strange. Regards 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
Re: [asterisk-dev] pjsip - retry handling - faulty warning message?
On Mon, Aug 24, 2020 at 16:32 George Joseph wrote: Check your timer_t1 setting in pjsip.conf. There is no entry - therefore I assume, the default should be used. That's what would control pjproject's decision on when to return back to us if there's no response to a request. It's also unclear who's doing the retry, us or pjproject. BTW: I'm using TCP - not UDP. It's odd that either one of us would wait only 27ms before retrying a request though. As Josh says below, the debug stuff would be needed for further analysis. Yes, that's true. While it happens extremely rarely, I wouldn't know how to trace it down. It usually runs for weeks without any problems, suddenly there are one or two entries (seldom more) and afterwards, it's fine again. Maybe I get sometime the opportunity to trace it down. 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
Re: [asterisk-dev] pjsip - retry handling - faulty warning message?
On Mon, Aug 17, 2020 at 12:51 PM Joshua C. Colp wrote: > On Sat, Aug 15, 2020 at 12:25 PM Michael Maier > wrote: > >> Hello! >> >> I got the following warning in the asterisk log: >> >> [2020-08-15 16:16:03] WARNING[14367] res_pjsip_outbound_registration.c: >> No response received from 'sip:tel.t-online.de' on registration attempt >> to 'sip:+49...@tel.t-online.de', retrying in '60' >> >> >> What really happened (according pcap trace): >> >> RegisterAug 15, 2020 16:16:03.946677000 CEST >> RegisterAug 15, 2020 16:16:03.97371 CEST~ >> 27 ms (Retry) >> Security agreement required Aug 15, 2020 16:16:04.066745000 CEST~ >> 92 ms >> ... >> Ok Aug 15, 2020 16:16:04.081487000 CEST~ >> 14 ms (finish) >> >> >> (Usual duration of a Register is ~ 22.8 ms) >> >> Okay, provider was a bit lazy to answer, but Register has been working >> fine after one retry 27 ms later. Therefore, I don't understand the >> warning, especially because the registration timeout is 660s and asterisk >> starts reregistration 10s before the expiry of the registration - so there >> wasn't any problem with the Registration de facto. Especially as there >> couldn't be seen any Retry after 60 s as stated in the log. Maybe the log >> entry is somewhat hasty? >> > > Check your timer_t1 setting in pjsip.conf. That's what would control pjproject's decision on when to return back to us if there's no response to a request. It's also unclear who's doing the retry, us or pjproject. It's odd that either one of us would wait only 27ms before retrying a request though. As Josh says below, the debug stuff would be needed for further analysis. > Without debug level and trace information and such it's hard to say. It > may be that the security agreement response wasn't counted for some reason > and confused the code, resulting in the transaction thinking it got no > response. > > -- > Joshua C. Colp > Asterisk Technical Lead > Sangoma Technologies > Check us out at www.sangoma.com and www.asterisk.org > -- > _ > -- 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 -- George Joseph Asterisk Software Developer direct/fax +1 256 428 6012 Check us out at www.sangoma.com and www.asterisk.org [image: image.png] -- _ -- 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
Re: [asterisk-dev] pjsip - retry handling - faulty warning message?
On Sat, Aug 15, 2020 at 12:25 PM Michael Maier wrote: > Hello! > > I got the following warning in the asterisk log: > > [2020-08-15 16:16:03] WARNING[14367] res_pjsip_outbound_registration.c: No > response received from 'sip:tel.t-online.de' on registration attempt to ' > sip:+49...@tel.t-online.de', retrying in '60' > > > What really happened (according pcap trace): > > RegisterAug 15, 2020 16:16:03.946677000 CEST > RegisterAug 15, 2020 16:16:03.97371 CEST~ > 27 ms (Retry) > Security agreement required Aug 15, 2020 16:16:04.066745000 CEST~ > 92 ms > ... > Ok Aug 15, 2020 16:16:04.081487000 CEST~ > 14 ms (finish) > > > (Usual duration of a Register is ~ 22.8 ms) > > Okay, provider was a bit lazy to answer, but Register has been working > fine after one retry 27 ms later. Therefore, I don't understand the > warning, especially because the registration timeout is 660s and asterisk > starts reregistration 10s before the expiry of the registration - so there > wasn't any problem with the Registration de facto. Especially as there > couldn't be seen any Retry after 60 s as stated in the log. Maybe the log > entry is somewhat hasty? > Without debug level and trace information and such it's hard to say. It may be that the security agreement response wasn't counted for some reason and confused the code, resulting in the transaction thinking it got no response. -- Joshua C. Colp Asterisk Technical Lead Sangoma Technologies Check us out at www.sangoma.com and www.asterisk.org -- _ -- 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
[asterisk-dev] pjsip - retry handling - faulty warning message?
Hello! I got the following warning in the asterisk log: [2020-08-15 16:16:03] WARNING[14367] res_pjsip_outbound_registration.c: No response received from 'sip:tel.t-online.de' on registration attempt to 'sip:+49...@tel.t-online.de', retrying in '60' What really happened (according pcap trace): RegisterAug 15, 2020 16:16:03.946677000 CEST RegisterAug 15, 2020 16:16:03.97371 CEST~ 27 ms (Retry) Security agreement required Aug 15, 2020 16:16:04.066745000 CEST~ 92 ms ... Ok Aug 15, 2020 16:16:04.081487000 CEST~ 14 ms (finish) (Usual duration of a Register is ~ 22.8 ms) Okay, provider was a bit lazy to answer, but Register has been working fine after one retry 27 ms later. Therefore, I don't understand the warning, especially because the registration timeout is 660s and asterisk starts reregistration 10s before the expiry of the registration - so there wasn't any problem with the Registration de facto. Especially as there couldn't be seen any Retry after 60 s as stated in the log. Maybe the log entry is somewhat hasty? 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
