Re: [asterisk-dev] Issue with PJSIP contacts being "unavailable"

[Joshua C. Colp]

On Tue, Jun 27, 2023 at 7:33 PM  wrote:




> 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?
>

If the transport goes down in that scenario, then the Contact should get
removed because it is an ephemeral port and you can't establish an outbound
connection to it.


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

The scenario where this would only work is if rewrite_contact is set to no,
and a Contact is bound from a REGISTER.


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


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

Re: [asterisk-dev] Issue with PJSIP contacts being "unavailable"

[asterisk]

On 6/27/2023 6:22 PM, Joshua C. Colp wrote:
On Tue, Jun 27, 2023 at 7:18 PM > 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

Re: [asterisk-dev] Issue with PJSIP contacts being "unavailable"

[Joshua C. Colp]

On Tue, Jun 27, 2023 at 7:18 PM  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.

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

Re: [asterisk-dev] Issue with PJSIP contacts being "unavailable"

[asterisk]

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.


--
_
-- 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] [asterisk-users] Issue with PJSIP contacts being "unavailable"

[Joshua C. Colp]

On Tue, Jun 27, 2023 at 6:57 PM  wrote:

> On 6/27/2023 7:29 AM, Joshua C. Colp wrote:
> > On Tue, Jun 27, 2023 at 8:22 AM  > > wrote:
> >
> > 
> >
> >
> > 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

Re: [asterisk-dev] [asterisk-users] Issue with PJSIP contacts being "unavailable"

[asterisk]

On 6/27/2023 7:29 AM, Joshua C. Colp wrote:
On Tue, Jun 27, 2023 at 8:22 AM > wrote:





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