| Summary: | ASTERISK-14788: Recent change to peer_iphash_cb breaks peer matching | ||
| Reporter: | nick_lewis (nick_lewis) | Labels: | |
| Date Opened: | 2009-09-08 04:05:46 | Date Closed: | 2011-06-07 14:01:00 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_sip/Interoperability |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | A change has been made to the chan_sip.c function peer_iphash_cb to remove hashing on the port number. It is not clear why this change was made but it may be indirectly related to a tcp/tls matching issue. However the change breaks udp peer matching. ****** ADDITIONAL INFORMATION ****** Any peers that differ only in port number will be ignored so for example if there are udp peers trunk1, trunk2 and trunk3 at myitsp.net:5060, myitsp.net:5061 and myitsp.net:5062 respectively, they will be hashed as only trunk1. Depending whether insecure=port is configured this will either lead to calls from trunk2 and trunk3 failing to match at all or lead to calls from trunk2 and trunk3 incorrectly matching to trunk1. | ||
| Comments: | By: Russell Bryant (russell) 2009-09-08 09:29:31 The issue was that hashing on the port number was problematic when it was only sometimes going to be used in matching. For example, when matching with TCP, the port will not be used. So, it was better to remove it from the hash function. The hash function doesn't change matching directly. However, it will affect layout in the hash table. If you're seeing a difference in behavior now, then you were relying on behavior that was just luck. You can't rely on peers ending up in a different hash bucket. For UDP peer matching, if you're matching on both IP and port, then you'll still get the correct match. If you're not matching with port, then just as you have configured, you're going for a less exact match, and you will match the first peer with that IP address that the search comes across. By: David Vossel (dvossel) 2009-09-08 09:56:34 "...Depending whether insecure=port is configured this will either lead to calls from trunk2 and trunk3 failing to match at all or ..." With 'insecure=port' disabled, no change in behavior should be present. Can you please verify this? With what settings are calls from trunk2 and trunk3 failing to match at all? By: nick_lewis (nick_lewis) 2009-09-08 10:00:44 >The hash function doesn't change matching directly. Sorry, I was misunderstanding the implications of a duplicate hash. I will study ao2_t_link/find until I understand it correctly. Please close this issue | ||