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:35 | Date Closed: | 2021-01-06 18:23:22.000-0600 |
Priority: | Major | Regression? | |
Status: | Closed/Complete | Components: | 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. |