On Tue, Jun 27, 2023 at 6:57 PM <aster...@phreaknet.org> wrote: > On 6/27/2023 7:29 AM, Joshua C. Colp wrote: > > On Tue, Jun 27, 2023 at 8:22 AM <aster...@phreaknet.org > > <mailto:aster...@phreaknet.org>> wrote: > > > > <snip> > > > > > > Trace from an "unavailable" ATA (not working correctly): > > https://paste.interlinked.us/iz07sapwrb.txt > > > > Trace from an "available" ATA (working correctly): > > https://paste.interlinked.us/ocutyjslmg.txt > > > > > > The "unavailable" ATA no longer has a working TLS connection to > > Asterisk, resulting in OPTIONS failing, and going unreachable, and > > eventually the Contact going away. Actually examining the TLS side > > would be needed. > > Thanks, Josh. Further troubleshooting supports that as being the problem > as well. I'll have to figure out what's changed with that. > > Replying to the dev list since this is not directly related, but it > reminds me of a previous conversation we had about chan_pjsip > automatically using the transport used for registration. This is not > currently done; what would be your thoughts on perhaps adding an option > to do this automatically? Currently, the provisioning system directs > devices to the proper port based on the security options in the system > and the TLS capabilities of the device. When something registers, I keep > track of the port on which a device registers using AMI, logging it to a > database. We have one port for UDP, one for TLS 1.0, and one for TLS 1.2 > (none for plain TCP at the moment). chan_sip isn't as flexible so the > process is more straightforward there: just use the TLS 1.0 port if TLS > is enabled, but for PJSIP, the transpiler assigns a transport based on > the registration port. In theory, a client can toggle the transport for > registration (TLS vs UDP), but that alone doesn't really work since > pjsip.conf needs to be in agreement with that. It would be slightly more > seamless if it could just sync up somehow, as right now I have to > manually retranspile any time this occurs, and it seems kind of clunky > to have to do all this for transports to work properly. > > Would there be any consideration or problem with potentially doing > something like this? After all, it seems like there's a 1:1 mapping and > it should be fairly straightforward. Kind of like the "line" option for > registrations, it would help in making things "just work" more of the > time... >
I'm not sure what exactly you are referring to with "using the transport used for registration". If "rewrite_contact" is set to yes then the existing active connection should get used. If you are referring to Asterisk establishing a new outgoing connection to the registered Contact, then as long as it is optional and doesn't break other behavior fine. -- Joshua C. Colp Asterisk Project 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