On 6/27/2023 6:22 PM, Joshua C. Colp wrote:
On Tue, Jun 27, 2023 at 7:18 PM <aster...@phreaknet.org
<mailto:aster...@phreaknet.org>> wrote:
On 6/27/2023 6:07 PM, Joshua C. Colp wrote:
>
> 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.
Basically, suppose a device registers on a port, associated with some
configured transport.
The reason I'm doing this now is that initially, calls out *to*
devices
would just use the default transport (the first one configured, or
something like that). Specifying a transport= in the endpoint
explicitly
ensured they'd only use the appropriate one. The problem still
remains
though that we don't necessarily know what transport a device is
going
to use in advance, and it could also change at any time.
I don't know if this would be a "new" outgoing connection to the
contact or not... I was noticing this issue with outbound calls to
devices using the wrong transport (e.g. an ATA registered using
TLS, and
Asterisk would call the device using UDP, on a different port). The
description for "rewrite_contact" says "Allow Contact header to be
rewritten with the source IP address-port" which doesn't really
clarify
that, but if that means it'll always use the same transport out to
the
device that the device initiated a connection on, no matter what,
then I
think that will do the trick. I just want Asterisk to go along with
whatever the device wants to do. If there's a gap with
"rewrite_contact"
then I guess a new option is still needed to do the other half.
The source IP address, port, and transport type become the Contact.
The Contact target is used for requests, and PJSIP looks for an
existing active connection meeting that criteria. If such a connection
is found then it is reused.
Thanks - just to clarify, if such a connection *isn't* found, this won't
help me right now? It would still use the default transport even with
rewrite_contact=yes?
In that case, I'm thinking the new option would add on to this by
extending that behavior to if there isn't an active connection and it
needs to set up a new one. Basically "use the contact to determine the
transport, unconditionally" is essentially what it would do.
I guess for devices that don't register, you wouldn't necessarily have a
contact so maybe that's why this isn't done all the time? But those are
probably the cases where specifying a transport explicitly would
probably make more sense anyways, and I'm not concerned about those,
only things that register and as such a contact would always be available.
--
_____________________________________________________________________
-- 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