[Home]

Summary:ASTERISK-29024: pjsip: Route Header in Cancel request incorrectly set
Reporter:Flole Systems (flole@flole.de)Labels:patch
Date Opened:2020-08-07 17:45:35Date Closed:2021-01-06 18:23:22.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:pjproject/pjsip
Versions:17.6.0 Frequency of
Occurrence		Frequent
Related
Issues:
Environment:Attachments:( 0) 2.txt
( 1) patch2.diff
( 2) res_pjsip_nat.diff
Description:When I initiate a call using PJSIP and Cancel the call while it's still ringing the Route-Header seems to be sent incorrectly. It looks like it's a pointer to a memory region that got overwritten. I saw internal IP Addresses in there aswell as some other stuff like "Route: <sip:}". The "Route: <sip:" is always set properly, just the part after the sip is never set correctly and also the closing ">" is always missing.

As the memory region that it reads from can't be controlled it might happen that confidential data like a password is exposed over this.
Comments:By: Asterisk Team (asteriskteam) 2020-08-07 17:45:36.737-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.
By: Kevin Harwell (kharwell) 2020-08-10 18:01:10.204-0500

Does this happen every time?

Please enable debug and SIP tracing in the Asterisk log [1], and attach to this issue the output of an incident.

Also please attach relevant dialplan and _pjsip.conf_ (endpoint definition, etc...) configuration.

[1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

Thanks!
By: Flole Systems (flole@flole.de) 2020-08-12 12:50:14.816-0500

The content of that header is random, but it happens every time that the closing > is missing and the content is never correct. Sometimes it contains the IP address of the internal phone that initiated the call, sometimes just pure garbage but never the correct header.

The logs show this:
{noformat}
<--- Transmitting SIP request (481 bytes) to UDP:1.2.3.4:5060 --->
CANCEL sip:123456@my.provider.com:5060 SIP/2.0
Via: SIP/2.0/UDP 4.3.2.1:5060;rport;branch=XXX
From: <sip:987654321@my.provider.com>;tag=YYYYYY
To: <sip:123456@my.provider.com>
Call-ID: XXXX
CSeq: 32067 CANCEL
Route: <sip:}
{noformat}

Config looks like this
{noformat}
[myProvider]
type = endpoint
context = mycontext
dtmf_mode = rfc4733
outbound_proxy = sip:my.provider.com\;lr
direct_media = no
from_domain = my.provider.com
disallow = all
allow = g722,alaw,ulaw
sdp_session=MySession
aors = Provider-aor
rtp_symmetric = no
force_rport = no
rewrite_contact = yes
timers = yes
outbound_auth = auth_reg_my.provider.com
identify_by = ip
{noformat}
By: Kevin Harwell (kharwell) 2020-08-13 17:16:15.218-0500

I'm not seeing this behavior. I'm doing the following:

Using a similar configuration to that given in the previous comment I originate a call from Asterisk to that endpoint. While the "called" endpoint is being rung I then hangup the call (in this case via the Asterisk CLI). A SIP CANCEL is then sent from Asterisk to the endpoint.

Does that sound about right?

Could you please enable Asterisk debug logging [1] with sip trace, and attach the log here.

[1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information
By: Flole Systems (flole@flole.de) 2020-08-17 06:39:19.590-0500

Yes that sounds right. I think I figured out what's going on: My Provider doesn't send back a Route-Header, the SIP Trace looks like this and raising the debug log level didn't seem to produce any additional output:

{noformat}
INVITE sip:123456@my.provider.com:5060 SIP/2.0
Via: SIP/2.0/UDP 4.3.2.1:5060;rport;branch=XXX
From: <sip:987654321@my.provider.com>;tag=YYYYYY
To: <sip:123456@my.provider.com>
Contact: <sip:987654321@4.3.2.1:5060>
Call-ID: XXXX
CSeq: 32067 INVITE
Route: <sip:1.2.3.4:5060;lr>
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: Asterisk PBX
Proxy-Authorization: Digest username="myUser", realm="Realm", nonce="XXXX", uri="sip:123456@my.provider.com:5060", response="XXXX", algorithm=MD5
Content-Type: application/sdp
Content-Length:   283

v=0
o=- 718667999 718667999 IN IP4 4.3.2.1
s=Asterisk
c=IN IP4 4.3.2.1
t=0 0
m=audio 10734 RTP/AVP 9 8 0 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

<--- Received SIP response (739 bytes) from UDP:1.2.3.4:5060 --->
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 4.3.2.1:5060;received=4.3.2.1;branch=XXX;rport=5060
From: <sip:987654321@my.provider.com>;tag=YYYYYY
To: <sip:123456@my.provider.com>;tag=TAGTAG
Call-ID: XXXX
CSeq: 32067 INVITE
Contact: <sip:123456@1.2.3.4:5060;transport=udp>
Content-Length: 241
Content-Type: application/sdp

v=0
o=- 3038379570 718668000 IN IP4 5.4.3.1
s=-
c=IN IP4 5.4.3.1
t=0 0
m=audio 14634 RTP/AVP 9 8 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
a=ptime:20

<--- Received SIP response (739 bytes) from UDP:1.2.3.4:5060 --->
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 4.3.2.1:5060;received=4.3.2.1;branch=XXX;rport=5060
From: <sip:987654321@my.provider.com>;tag=YYYYYY
To: <sip:123456@my.provider.com>;tag=TAGTAG
Call-ID: XXXX
CSeq: 32067 INVITE
Contact: <sip:123456@1.2.3.4:5060;transport=udp>
Content-Length: 241
Content-Type: application/sdp

v=0
o=- 3038379570 718668001 IN IP4 5.4.3.1
s=-
c=IN IP4 5.4.3.1
t=0 0
m=audio 14634 RTP/AVP 9 8 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
a=ptime:20

<--- Transmitting SIP request (481 bytes) to UDP:1.2.3.4:5060 --->
CANCEL sip:123456@my.provider.com:5060 SIP/2.0
Via: SIP/2.0/UDP 4.3.2.1:5060;rport;branch=XXX
From: <sip:987654321@my.provider.com>;tag=YYYYYY
To: <sip:123456@my.provider.com>
Call-ID: XXXX
CSeq: 32067 CANCEL
Route: <sip:}

<--- Received SIP response (404 bytes) from UDP:1.2.3.4:5060 --->
SIP/2.0 400 Invalid Route
Via: SIP/2.0/UDP 4.3.2.1:5060;received=4.3.2.1;branch=XXX;rport=5060
From: <sip:987654321@my.provider.com>;tag=YYYYYY
To: <sip:123456@my.provider.com>;tag=TAGTAG
Call-ID: XXXX
CSeq: 32067 CANCEL
Resource-Priority:
{noformat}
By: Kevin Harwell (kharwell) 2020-08-17 15:43:19.224-0500

I was finally able to replicate the issue using two Asterisk instances:

Instance A (initiator) _pjsip.conf_ (substitute IP addresses where appropriate):
{noformat}
[global]
type=global
debug=yes

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

[transport_t](!)
type=transport
bind=0.0.0.0

[transport_udp](transport_t)
protocol=udp

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

[endpoint_t](!)
type=endpoint
context=default
direct_media=no
allow=!all,ulaw
rtcp_mux=yes

[aor_t](!)
type=aor
qualify_frequency=0
max_contacts=10

[auth_t](!)
type=auth
auth_type=userpass
password=0000

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; alice ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

[alice](aor_t)
contact=sip:alice@<local ip addr>:5061
mailboxes=alice@default

[alice](auth_t)
username=alice

[alice](endpoint_t)
aors=alice
;auth=alice

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; triton ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

[triton](aor_t)
contact=sip:<local ip addr>

[triton](auth_t)
username=nereid

[triton](endpoint_t)
aors=triton
from_user=nereid
allow=!all,ulaw
outbound_proxy=sip:<remote ip addr>:5060\;lr
dtmf_mode=rfc4733
from_domain=nereid
allow=!all,g722,alaw,ulaw
sdp_session=MySession
rtp_symmetric=no
force_rport=no
rewrite_contact=yes
timers=yes
outbound_auth=triton
identify_by=ip

[triton]
type=registration
server_uri=sip:nereid@<remote ip addr>
client_uri=sip:nereid@<remote ip addr>
outbound_proxy=sip:<remote ip addr>:5060\;lr
{noformat}
Instance B _pjsip.conf_ (note templates are same as on instance A):
{noformat}
[nereid](aor_t)
contact=sip:nereid

[nereid](auth_t)
username=nereid

[nereid](endpoint_t)
aors=nereid
from_user=triton
allow=!all,g722,ulaw
{noformat}
Instance B's dialplan _extensions.conf_:
{noformat}
exten => alice,1,NoOp()
   same => n,Progress()
   same => n,Wait(10)
   same => n,Answer()
   same => n,Playback(hello-world)
   same => n,Hangup()
{noformat}
Start both instances of Asterisk and wait for Instance A to register to Instance B. Once successfully registered then from Instance A's CLI initiate a call to Alice and then hangup:
{noformat}
*CLI> originate PJSIP/triton/alice application Echo
*CLI>
*CLI> hangup request all
{noformat}
Note the following SIP trace/CLI output from Asterisk Instance A:
{noformat}
*CLI> Asterisk Ready.

*CLI>
*CLI>
*CLI>
*CLI> originate PJSIP/triton/alice application Echo<--- Transmitting SIP request (581 bytes) to UDP:10.24.17.123:5060 --->
REGISTER sip:nereid@10.24.17.123 SIP/2.0
Via: SIP/2.0/UDP 10.24.249.90:5060;rport;branch=z9hG4bKPj9498b530-6305-426d-9564-977f572fd01b
Route: <sip:10.24.17.123:5060;lr>
From: <sip:nereid@10.24.17.123>;tag=dc91bb90-1a18-46c3-846d-f21fb023ff3b
To: <sip:nereid@10.24.17.123>
Call-ID: ec4245df-2e39-4ca2-8759-7b5f6b4e3b9f
CSeq: 60321 REGISTER
Contact: <sip:s@10.24.249.90:5060>
Expires: 3600
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Max-Forwards: 70
User-Agent: Asterisk PBX 17.6.0
Content-Length:  0


<--- Received SIP response (545 bytes) from UDP:10.24.17.123:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.24.249.90:5060;rport=5060;received=10.24.249.90;branch=z9hG4bKPj9498b530-6305-426d-9564-977f572fd01b
Call-ID: ec4245df-2e39-4ca2-8759-7b5f6b4e3b9f
From: <sip:nereid@10.24.17.123>;tag=dc91bb90-1a18-46c3-846d-f21fb023ff3b
To: <sip:nereid@10.24.17.123>;tag=z9hG4bKPj9498b530-6305-426d-9564-977f572fd01b
CSeq: 60321 REGISTER
Date: Mon, 17 Aug 2020 20:27:46 GMT
Contact: <sip:nereid>
Contact: <sip:s@10.24.249.90:5060>;expires=3599
Expires: 3600
Server: Asterisk PBX GIT-16-5609d00
Content-Length:  0



*CLI> <--- Transmitting SIP request (983 bytes) to UDP:10.24.17.123:5060 --->
INVITE sip:alice@127.0.0.1:5061 SIP/2.0
Via: SIP/2.0/UDP 10.24.249.90:5060;rport;branch=z9hG4bKPj0589b8de-0e05-4abe-b9e8-f470412a283c
From: "Anonymous" <sip:nereid@nereid>;tag=23cc3c64-337a-4dd1-8d64-1289f830bebd
To: <sip:alice@127.0.0.1>
Contact: <sip:nereid@10.24.249.90:5060>
Call-ID: 9438b6b2-41b3-423d-a18a-22491349fd4c
CSeq: 16411 INVITE
Route: <sip:10.24.17.123:5060;lr>
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: Asterisk PBX 17.6.0
Content-Type: application/sdp
Content-Length:   296

v=0
o=- 351831285 351831285 IN IP4 10.24.249.90
s=MySession
c=IN IP4 10.24.249.90
t=0 0
m=audio 14926 RTP/AVP 9 8 0 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
a=rtcp-mux

<--- Received SIP response (375 bytes) from UDP:10.24.17.123:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.24.249.90:5060;rport=5060;received=10.24.249.90;branch=z9hG4bKPj0589b8de-0e05-4abe-b9e8-f470412a283c
Call-ID: 9438b6b2-41b3-423d-a18a-22491349fd4c
From: "Anonymous" <sip:nereid@nereid>;tag=23cc3c64-337a-4dd1-8d64-1289f830bebd
To: <sip:alice@127.0.0.1>
CSeq: 16411 INVITE
Server: Asterisk PBX GIT-16-5609d00
Content-Length:  0


<--- Received SIP response (876 bytes) from UDP:10.24.17.123:5060 --->
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 10.24.249.90:5060;rport=5060;received=10.24.249.90;branch=z9hG4bKPj0589b8de-0e05-4abe-b9e8-f470412a283c
Call-ID: 9438b6b2-41b3-423d-a18a-22491349fd4c
From: "Anonymous" <sip:nereid@nereid>;tag=23cc3c64-337a-4dd1-8d64-1289f830bebd
To: <sip:alice@127.0.0.1>;tag=588b8700-7a5d-4169-96d6-8bc7121d35aa
CSeq: 16411 INVITE
Server: Asterisk PBX GIT-16-5609d00
Contact: <sip:10.24.17.123:5060>
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Content-Type: application/sdp
Content-Length:   271

v=0
o=- 351831285 351831287 IN IP4 10.24.17.123
s=Asterisk
c=IN IP4 10.24.17.123
t=0 0
m=audio 11872 RTP/AVP 9 0 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
a=rtcp-mux


*CLI>
*CLI>
*CLI>
*CLI> hangup request all
Requested Hangup on channel 'PJSIP/triton-00000000'
*CLI> <--- Transmitting SIP request (441 bytes) to UDP:10.24.17.123:5060 --->
CANCEL sip:alice@127.0.0.1:5061 SIP/2.0
Via: SIP/2.0/UDP 10.24.249.90:5060;rport;branch=z9hG4bKPj0589b8de-0e05-4abe-b9e8-f470412a283c
From: "Anonymous" <sip:nereid@nereid>;tag=23cc3c64-337a-4dd1-8d64-1289f830bebd
To: <sip:alice@127.0.0.1>
Call-ID: 9438b6b2-41b3-423d-a18a-22491349fd4c
CSeq: 16411 CANCEL
Route: <sip:
<--- Transmitting SIP request (441 bytes) to UDP:10.24.17.123:5060 --->
CANCEL sip:alice@127.0.0.1:5061 SIP/2.0
Via: SIP/2.0/UDP 10.24.249.90:5060;rport;branch=z9hG4bKPj0589b8de-0e05-4abe-b9e8-f470412a283c
From: "Anonymous" <sip:nereid@nereid>;tag=23cc3c64-337a-4dd1-8d64-1289f830bebd
To: <sip:alice@127.0.0.1>
Call-ID: 9438b6b2-41b3-423d-a18a-22491349fd4c
CSeq: 16411 CANCEL
Route: <sip:

*CLI>
*CLI> <--- Transmitting SIP request (441 bytes) to UDP:10.24.17.123:5060 --->
CANCEL sip:alice@127.0.0.1:5061 SIP/2.0
Via: SIP/2.0/UDP 10.24.249.90:5060;rport;branch=z9hG4bKPj0589b8de-0e05-4abe-b9e8-f470412a283c
From: "Anonymous" <sip:nereid@nereid>;tag=23cc3c64-337a-4dd1-8d64-1289f830bebd
To: <sip:alice@127.0.0.1>
Call-ID: 9438b6b2-41b3-423d-a18a-22491349fd4c
CSeq: 16411 CANCEL
Route: <sip:
{noformat}
By: Kevin Harwell (kharwell) 2020-08-17 15:48:40.176-0500

Also as a note at first I tried setting the scenario up using SIPp. Using a basic endpoint config Asterisk I used the same CLI commands, and setup SIPp to respond appropriately (with progress, etc..) but while the SIP trace looked very similar the Route header was not corrupted.

So maybe something in the stored state of a registered endpoint and interactions between that and a call? Just some thoughts.
By: Flole Systems (flole@flole.de) 2020-10-06 08:36:55.516-0500

I saw something similar today with an ACK to a "407 Proxy Authentication Required" aswell (not sure if the cause is the same though).

Wireshark shows in the ACK:
{noformat}
...
Route: <sip:\000\000\000\000\000\000\000\000\000\000\000\000\000\000:5060;lr>
...
{noformat}

I have never seen that before and about a minute later on a similar 407 the ACK-Route was containing the proper IP, no Idea what went wrong there but it seems to be some kind of Route-Header-Corruption aswell.
By: Ralf Kubis (ralf.kubis) 2020-10-08 09:03:16.232-0500

I've experienced a similar, if not the same issue, and was able to identify the defective code after some debugging.

The symptom in my case was uninitialized data in the host-part of the URI of the CANCEL request.

Null-bytes in the string led to ISP-triggered hangups of the TCP-connection to a trunk of "Deutsche Telekom", and thereby a loss of my registration.
In other cases, without null-bytes, but other garbage, the CANCEL-request was ignored with an error reply, leading to continuous ringing on the called side.

Nevermind. The issue is to be found in *<src_root>\res\res_pjsip_nat.c* in function {{rewrite_uri(...)}}

There is the call
{{pj_cstr(&uri->host, rdata->pkt_info.src_name);}}    
which produces a shallow copy. {{uri->host}} then 'points' to the same memory as {{rdata->pkt_info.src_name}}.
   
Later, in the defective case, {{uri->host}} gets evaluated after {{rdata->pkt_info.src_name[]}} was released from the pool (and the memory got re-assigned and used for other stuff).

As a fix, I've changed the signature of {{rewrite_uri()}} to

{{static void rewrite_uri(pjsip_rx_data *rdata, pjsip_sip_uri *uri, pj_pool_t *pool)}}
   
and in its body calling

{{pj_strdup2(pool, &uri->host, rdata->pkt_info.src_name);}}

to produce a deep-copy.
I think you've got the idea.

After short inspection I've identified a similar spot in {{websocket_on_rx_msg()}}.

In general I'd propose to review all other calls to {{pj_cstr()}} for this issue.

The current master still has this issue.

In case you need more details of how to reproduce and debug this, don't hesitate to contact me by email.

Thanks guys for your effort
By: Ralf Kubis (ralf.kubis) 2020-10-08 09:38:07.624-0500

I forgot,

there is this other issue in *<src_root>\third-party\pjproject\source\pjsip\src\pjsip\sip_util.c*.
This is probably to be fixed in PJSIP.

In function {{pjsip_endpt_create_cancel(...)}}


{code:title=<src_root>/third-party/pjproject/source/pjsip/src/pjsip/sip_util.c|borderStyle=solid}
   /* Copy the destination host name from the original request */
   pj_strdup(
           cancel_tdata->pool
       ,   &cancel_tdata->dest_info.name
       ,   &req_tdata->dest_info.name
       );

   /* Finally copy the destination info from the original request */
   pj_memcpy(
           &cancel_tdata->dest_info
       ,   &req_tdata->dest_info
       ,   sizeof(req_tdata->dest_info)
       );
{code}

Here, {{cancel_tdata->dest_info.name}} received a deep-copy.
But the subsequent call to {{pj_memcpy()}} makes it shallow again.

My intermediate Hack around this:

{code:title=<src_root>/third-party/pjproject/source/pjsip/src/pjsip/sip_util.c|borderStyle=solid}
   pj_memcpy(
           &cancel_tdata->dest_info
       ,   &req_tdata->dest_info
       ,   sizeof(req_tdata->dest_info)
       );

   cancel_tdata->dest_info.name.ptr  = 0;
   cancel_tdata->dest_info.name.slen = 0;

   /* Copy the destination host name from the original request */
   pj_strdup(
           cancel_tdata->pool
       ,   &cancel_tdata->dest_info.name
       ,   &req_tdata->dest_info.name
       );

{code}
By: Kevin Harwell (kharwell) 2020-10-08 12:54:14.527-0500

[~ralf.kubis],

Thank you for the extra information and analysis!

I believe you are correct in your findings. It currently appears no one is working this issue at this time. If you'd like to hasten the process you can submit a patch [1] [2] for code review.

As far as the pjproject portion goes a patch would need to be submitted to pjproject for that [3]. However, that patch can then be included in Asterisk "pjproject bundled" patches directory (see _<src root>/third-party/pjproject/patches_) for inclusion with Asterisk until a version of pjproject is released with that patch (and when Asterisk "pjproject bundled" version is upgraded).

[1] https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process
[2] https://wiki.asterisk.org/wiki/display/AST/Gerrit+Usage
[3] https://github.com/pjsip/pjproject/issues

Thanks!
By: Ralf Kubis (ralf.kubis) 2020-10-10 14:16:05.555-0500

Kevin Harvell,

due to a very limited time budget also on my side, and the fair amount of debugging time I've already invested, I sadly have to inform You that I'm unable to further participate in resolving this issue.
In fact, I strongly believe that the extra effort to prepare an adequate pull request will be for me, a guy with a very limited unterstanding of Your framework and programming techniques, ... challenging.
Even if I would try this, someone with a deep understanding of the code base will receive the task to review and, in case, fix my code - hopefully. I hardly see any benefit but just more overhead.

Thanks again and fingers crossed

ps. I've filed https://github.com/pjsip/pjproject/issues/2544
By: nappsoft (nappsoft) 2020-12-07 01:16:15.448-0600

This simple one-liner fixes the issue.

However, what I observed in ASTERISK-29197 is that if a record-route Header is present, rewrite_uri will be called twice (I assume that dlg->route_set contains the Record-Route heade as well)... is this really intended or could one do an if (rr) { }else if(...)?
By: nappsoft (nappsoft) 2020-12-07 10:22:15.209-0600

the change in res_pjsip_nat.c is exactly the same like my patch => so I've alredy tested this
the change in the pjsip library I'd already applied (forgot to mention that) => so I've already tested this part of your patch as well
the change in res_pjsip_transport_websocket.c shouldn't influence anything in our environment... so it makes no sense for me to check that

So in short: I guess that your patch should give exactly the same results as mine (at least for the cases I was testing)

By: Sean Bright (seanbright) 2020-12-07 10:37:40.878-0600

I'm just putting together a patch for review & inclusion I want to make sure it applies, compiles, and works. Thanks for your feedback.
By: nappsoft (nappsoft) 2020-12-08 04:00:03.811-0600

got the following crash twice yesterday while testing. However this only ever happened with the current patch for ASTERISK-29022 applied. (However I can't say for sure that it could not possibly happen as well without the mentioned patch. But I've let run my testcase for about 30 hours without the mentioned patch without any crash and got 3 crashes during about 8 hours of testing with the mentioned patch... but of course, we all know how it is with race conditions/memory corruption: a small change in the environment can let the issue pop up frequently or let it vanish...).

Could the patch for ASTERISK-29022 somehow have an influence on the lifetime of rdata->tp_info.pool? Or is rdata->tp_info.pool the wrong pool to use anyway? However the strange thing is that this always happens on the second call to rewrite_uri (so not in the if (rr) case, but afterwards for the route_set).
By: nappsoft (nappsoft) 2020-12-08 04:25:36.300-0600

Could it be the case that the first call to rewrite_uri (the one for pjsip_rr_hdr) makes the pjsip_routing_hdr in dlg->route_set invalid as the structs are pointing to the same memory location first (like I've written: in my case rewrite_uri is called twice even though the message only has a Record-Route and no route header, so dlg->route_set.next seems to point to the rr header) but the pointer to route->name_addr in the route set is not updated properly?
By: nappsoft (nappsoft) 2020-12-08 04:42:41.647-0600

When looking at sip_dialog.c in pjsip it seems like route_set would be filled with headers of type PJSIP_H_RECORD_ROUTE anyway (no PJSIP_H_ROUTE headers). So wouldn't the following patch avoid the redundancy? (And avoid the described behavior)?
By: Sean Bright (seanbright) 2020-12-08 08:13:15.574-0600

Feel free to [submit your patches to Gerrit for review|https://wiki.asterisk.org/wiki/display/AST/Gerrit+Usage]. I have removed the patches I created from this issue.