| Summary: | ASTERISK-27295: Contact is improperly translated after d178f497 | ||
| Reporter: | Sean Bright (seanbright) | Labels: | pjsip |
| Date Opened: | 2017-09-26 08:32:02 | Date Closed: | 2017-09-28 13:15:21 |
| Priority: | Major | Regression? | |
| Status: | Closed/Complete | Components: | |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | {noformat}
13:05 <@seanbright> what is the magic setting that makes asterisk rewrite it's own Contact? 13:05 <@seanbright> not talking about rewrite_contact 13:06 <@seanbright> is it 'domain' on transport? 13:06 <@file> local_net and external_signaling_address? 13:06 <@seanbright> hmm. those are both set. 13:09 <@seanbright> file: <url to conf> 13:09 <@seanbright> that look right-ish? 13:09 <@seanbright> asterisk behind nat, srbtest behind another nat 13:09 <@file> yes, seems right-ish 13:10 <@seanbright> k 13:11 <@gtjoseph> what happens if you bind to a specific address? 13:13 <@seanbright> gtjoseph: no change 13:14 <@gtjoseph> what are you seeing? Still local ipv4? 13:14 <@seanbright> gtjoseph: <url to debug> 13:15 <@seanbright> yes, the Contact header that asterisk sends back to the client has the local UP 13:15 <@seanbright> IP* 13:15 <@gtjoseph> ew. the filter is setting it _back_ to a local address? 13:15 <@seanbright> allegedly 13:15 <@seanbright> this is the master branch {noformat} {{pjsip.conf}}: {noformat} [transport-udp] type = transport protocol = udp bind = 0.0.0.0:5060 local_net = 10.0.0.0/24 external_media_address = 1.2.3.4 external_signaling_address = 1.2.3.4 [srbtest] type = endpoint transport = transport-udp context = from-internal allow = !all,g722,ulaw rtp_symmetric = yes force_rport = yes direct_media = no rewrite_contact = yes media_address = 1.2.3.4 auth = srbtest aors = srbtest callerid = SRB Test <1111> [srbtest] type = auth auth_type = userpass username = srbtest password = mysecret [srbtest] type = aor max_contacts = 10 qualify_frequency = 60 {noformat} | ||
| Comments: | By: Asterisk Team (asteriskteam) 2017-09-26 08:32:03.763-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. 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]. By: Friendly Automation (friendly-automation) 2017-09-28 13:15:23.133-0500 Change 6607 merged by Jenkins2: pjsip_message_filter: Fix regression causing bad contact address [https://gerrit.asterisk.org/6607|https://gerrit.asterisk.org/6607] By: Friendly Automation (friendly-automation) 2017-09-28 13:28:06.694-0500 Change 6608 merged by Jenkins2: pjsip_message_filter: Fix regression causing bad contact address [https://gerrit.asterisk.org/6608|https://gerrit.asterisk.org/6608] By: Friendly Automation (friendly-automation) 2017-09-28 13:29:09.953-0500 Change 6609 merged by Jenkins2: pjsip_message_filter: Fix regression causing bad contact address [https://gerrit.asterisk.org/6609|https://gerrit.asterisk.org/6609] By: Friendly Automation (friendly-automation) 2017-09-28 13:38:44.023-0500 Change 6610 merged by Jenkins2: pjsip_message_filter: Fix regression causing bad contact address [https://gerrit.asterisk.org/6610|https://gerrit.asterisk.org/6610] | ||