Assuming an endpoint connects to Asterisk, REGISTERs and then some time later closes it’s TCP socket to Asterisk, is there any way to query for that state in the AMI?
There a few AMI actions, you can try to query the status of an endpoint
If enedpoint has a hint you can use ExtensionState
also :
https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+ManagerAction_SIPpeerstatus
https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+ManagerAction_PJSIPShowAors
Indeed. I am not finding anything specific to whether the TCP socket for an endpoint is still open or not though.
My extensions don’t have hints. It’s not clear that adding them will help.
This is not a valid command on my Asterisk instance.
I see nothing in either of those that indicates whether an endpoint’s TCP socket is still open or not.
On Asterisk side I dont think there is an option to check TCP connection, in this case you need to use Linux netstat command
There is no such thing from a TCP level in Asterisk. Only whether an endpoint is reachable or not.
Is an endpoint still considered reachable if it’s closed it’s TCP socket to Asterisk? If Asterisk needs to INVITE such an endpoint, does it open a new TCP socket to the endpoint?
The Contact should be removed if the connection is being reused (by setting rewrite_contact) and PJSIP determines that the socket has been disconnected. The endpoint would then become unreachable if there are no other contacts on it. Calling the endpoint would then fail.
I can sort of see that it is unlikely that a reciprocal TCP set up will work in the cases for which rewrite contact is intended, but I don’t see where the OP has indicated tht such a case applies, and I thought the standard SIP behaviour was to use the existing connection if it existed, otherwise try and start one to the contact address.
I wouldn’t say it’s standard. There is an RFC in the area, but you’re supposed to connect back to what is provided in the Contact - in the case of TLS it lets you do some extra verification. Many implementations just adopted the approach of reusing it, to work around NAT.
It’s a bit stronger than that:
For requests, it is recommended: RFC 3261 - SIP: Session Initiation Protocol
If a request is destined to an IP address, port, and transport to
which an existing connection is open, it is RECOMMENDED that this
connection be used to send the request, but another connection MAY be
opened and used.
And for responses it is a qualified MUST: RFC 3261 - SIP: Session Initiation Protocol
If the “sent-protocol” is a reliable transport protocol such as
TCP or SCTP, or TLS over those, the response MUST be sent using
the existing connection to the source of the original request
that created the transaction, if that connection is still open.
Correct, and PJSIP behaves that way in both regards. It will reuse existing connections for requests to the same IP address, port, and transport. It will also use the same transport for sending responses. However for a registration the Contact may or may not be the ephemeral TCP port - if it isn’t then you probably don’t have an existing connection to that IP address, port, and transport.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.