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...
--
_____________________________________________________________________
-- 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
