Summary: | ASTERISK-25316: PJSIP qualify in mutlihomed system sent from wrong transport | ||
Reporter: | Alex Sinitsyn (xelas) | Labels: | |
Date Opened: | 2015-08-12 00:54:21 | Date Closed: | 2016-04-07 10:43:39 |
Priority: | Major | Regression? | |
Status: | Closed/Complete | Components: | Channels/chan_pjsip |
Versions: | 13.2.0 13.5.0 | Frequency of Occurrence | |
Related Issues: | |||
Environment: | Centos 6.6 Linux telegk12.6.32-504.8.1.el6.x86_64 #1 SMP Wed Jan 28 21:11:36 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux | Attachments: | ( 0) debuissu |
Description: | If qualify for endpoint enabled, chan_pjsip sent OPTIONS request to endpoint from last registered transport, but not from transport associated with endpoint.
{noformat} telegk1*CLI> pjsip show transports Transport: <TransportId........> <Type> <cos> <tos> <BindAddress....................> ========================================================================================= Transport: system-tcp-wan tcp 0 0 195.XX.XXX.194:5060 Transport: system-udp-lan udp 0 0 10.123.190.2:5060 Transport: system-udp-wan udp 0 0 195.XXX.XXX.194:5060 Transport: zettatrans udp 0 0 10.123.190.2:5061 {noformat} zettatrans -- last transport in config. 1106d endpoint use system-udp-wan transport. {noformat} telegk1*CLI> pjsip show endpoint 1106d <skip header> Endpoint: 1106d/1106 Unavailable 0 of inf InAuth: 1106dauth/1106d Aor: 1106d 1 Contact: 1106d/sip:1106d@109.197.29.XXX:5060 Unavail 0.000 Transport: system-udp-wan udp 0 0 195.XXX.XXX.194:5060 {noformat} vlan800 -- interface with address 195.XXX.XXX.194. vlan800 Link encap:Ethernet HWaddr 00:1E:0B:DD:00:0C inet addr:195.XXX.XXX.194 Bcast:0.0.0.0 Mask:255.255.255.252 I see, with tcpdump -pni vlan800 -vvvv, that OPTIONS request sent from zettatrans transport: {noformat} 08:26:41.948013 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 516) 10.123.190.2.5061 > 109.197.29.XXX.5060: [bad udp cksum 5218!] SIP, length: 488 OPTIONS sip:1106d@109.197.29.XXX:5060 SIP/2.0 {noformat} | ||
Comments: | By: Asterisk Team (asteriskteam) 2015-08-12 00:54:23.525-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: Rusty Newton (rnewton) 2015-08-13 09:16:51.997-0500 [~xelas] please provide an Asterisk debug log demonstrating the behavior. Please follow the instructions we have on the wiki to provide a log including 'debug' and 'verbose' log channels. https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Alex Sinitsyn (xelas) 2015-08-13 22:12:52.629-0500 debug log attached By: Alexei Gradinari (alexei gradinari) 2016-04-04 12:15:43.150-0500 It seems this patch https://github.com/asterisk/asterisk/commit/e1fdb0a6da0287452837c25b1295baa30b5866ed fixes this bug. By: Alexei Gradinari (alexei gradinari) 2016-04-07 10:35:55.439-0500 Can confirm the patch https://github.com/asterisk/asterisk/commit/e1fdb0a6da0287452837c25b1295baa30b5866ed fixed this bug. Tested on 13.8.0 |