[Home]

Summary:ASTERISK-25316: PJSIP qualify in mutlihomed system sent from wrong transport
Reporter:Alex Sinitsyn (xelas)Labels:
Date Opened:2015-08-12 00:54:21Date Closed:2016-04-07 10:43:39
Priority:MajorRegression?
Status:Closed/CompleteComponents: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/LinuxAttachments:( 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