PJSIP TCP , method not supported

Hello I have a situation.

If in my transport-tcp its set allow_reload=no

Some calls can’t send invite, The asterisk response with error 500.

res_pjsip_endpoint_identifier_user.c auth_username_identify: Endpoint found for ‘21060000’ but ‘auth_username’ method not supported

INVITE

2021/06/02 18:55:39.786540 177.53.246.169:35122 → XXX.XXX.XXX.XXX:7048
INVITE sip:21060000@mypbx.com.br:7048;transport=tcp SIP/2.0
Allow: INVITE,BYE,REGISTER,ACK,OPTIONS,CANCEL,INFO,PRACK,SUBSCRIBE,NOTIFY,REFER,UPDATE
Authorization: Digest username=“21060000”,realm=“asterisk”,nonce=“1622670939/653314d736fab74f1a813dd2e8969783”,uri=“sip:21060000@mypbx.
m.br”,response=“1c1470ce108f06176eae01e62bba274e”,algorithm=MD5,cnonce=“E6F85C45”,opaque=“21ef5c9b598b4e42”,qop=auth,nc=00000001
Call-ID: lbPS6jcM-tfUX:5f@mypbx.com.br
Contact: sip:21060000@192.168.15.2:7048;transport=tcp
Content-Type: application/sdp
CSeq: 175 INVITE
From: sip:21060000@mypbx.com.br:7048;transport=tcp;tag=1-5A738C31
Max-Forwards: 70
P-Asserted-Identity: sip:30033003@mypbx.com.br:7048;transport=tcp
Session-Expires: 1800;refresher=uas
Session-ID: 22688a9345e20ee07b216f8a73ecbcf4
Supported: 100rel,timer,replaces,histinfo
To: sip:21060000@mypbx.com.br:7048;transport=tcp
Via: SIP/2.0/TCP 192.168.15.2:7048;rport;branch=z9hG4bK95203C65
Content-Length: 235

v=0
o=- 15 0 IN IP4 192.168.15.2
s=-
c=IN IP4 192.168.15.2
t=0 0
m=audio 12028 RTP/AVP 8 0 100
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=ptime:20
a=sendrecv
a=rtcp:12029

Configuration ENDPOINT
[21060000]
type=aor
max_contacts=1
remove_existing=yes

[21060000]
type = auth
realm=asterisk
username = 21060000
password = 21060000@@

[21060000]
type = endpoint
context=tronco
disallow=all
inband_progress=yes
use_ptime=yes
language=pt_BR
rtp_timeout=300

direct_media=no
subscribe_context=hint-asterisk
allow_subscribe=yes
outbound_auth=21060000
aors=21060000
allow=alaw
allow=ulaw
dtmf_mode=rfc4733
t38_udptl=yes
t38_udptl_ec=redundancy
t38_udptl_maxdatagram=400
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes

contact_user=21060000
auth=21060000
transport = transport-tcp

What version of Asterisk? I ask because of this[1].

[1] [ASTERISK-29441] Core reload making TCP endpoints go offline - Digium/Asterisk JIRA

My Version is 18.4.0

I will try apply this patch for tests

This patch fixes the problem I already mentioned here. It finally fixes this change, which has been allegedly additionally reviewed by two more peoples (according gerrit).

I’m really wondering why obviously nobody did a pretty simple test to finally verify if the goal of a change is really reached …

I tested but not the case where a transport is specified on an endpoint, because that is generally not required and is not something often done. As well we did release candidates (which we do to allow more people to find stuff like this) and seemingly no one in the community either tested that situation or reported back.

Testing release candidates is a great way to contribute to the community and help prevent things like this from being released.

It is documented here (line 244 at the moment) and it’s default in FreePBX if you have a mulithomed system and want to be sure the correct interface and protocol is used. Further more it’s necessary to explicitly add transports to an endpoint because it’s the only way (I know of) to force asterisk / pjsip to use dedicated connections for each trunk if you have to register more than one trunk to the same destination.

Regarding release candidates: True, but my experience is, that problems in general are not seldom ignored and therefore I meanwhile mostly gave up and therefore I’m only sometimes sending problems to the mailing list - as referenced above. This link b.t.w. contains more problems - not just this one in question here.

Right, your usage requires it and it can certainly be used. Most usage I’ve seen and supported does not use it when using Asterisk standalone. I was unaware that FreePBX operates that way, but will take it into account in the future. We will also see if we can add test coverage for this.

In general if there’s problems with release candidates then they should be reported on the issue tracker, those are triaged and tracked. The mailing list is not and if something is determined to be a regression on the issue tracker, then we make it a blocker and fix it and release new release candidates for testing.

@jcolp Can I apply this patch in Asterisk 18.4.0?

I haven’t tested it to apply against 18.4.0, but using the 18 branch review it should - I wouldn’t expect things have diverged.

I will try, and post results here

Yes you can.

Michael

With this patch Work.