| Summary: | ASTERISK-06889: [patch] invalid OLC/faststart with bindaddr=0.0.0.0 | ||
| Reporter: | Pash (opa__) | Labels: | |
| Date Opened: | 2006-05-03 06:54:32 | Date Closed: | 2011-06-07 14:07:54 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_h323 |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) olc.patch ( 1) olc2.patch | |
| Description: | when bindaddr=0.0.0.0 or disabled invalid OLC/faststart local IP generated: May 3 18:27:38 DEBUG[9906]: chan_h323.c:1164 external_rtp_create: Sending RTP 'US' 0.0.0.0:19420 -- Started logical channel: receiving G.711-ALaw-64k -- channelsOpen = 2 External RTP Session Starting RTP channel id 1 parameters: -- remoteIpAddress: 192.168.111.109 -- remotePort: 30010 -- ExternalIpAddress: 0.0.0.0 -- ExternalPort: 19420 ****** ADDITIONAL INFORMATION ****** i think TRUNK is same. see olc.patch. | ||
| Comments: | By: Pash (opa__) 2006-05-03 06:58:40 it is right patch excepting NAT traversal (STUNS) By: Andrey S Pankov (casper) 2006-05-19 14:51:45 Formatting review - FAILED Code review - FAILED By: Serge Vecher (serge-v) 2006-05-19 14:57:05 casper: care to elaborate / provide better fix? By: Serge Vecher (serge-v) 2006-06-12 19:29:05 It seems like everybody has lost interest in this issue. Please feel free to reopen or ask the bug-marshall to do it for you if the interest arises again. Thanks By: Pash (opa__) 2006-12-10 11:38:48.000-0600 nice. 1.2.13 is on now. So new version of patch for any 1.2.4-13 I hope formatting is ok. If code still be bad not so quiet please. By: Serge Vecher (serge-v) 2006-12-11 09:01:29.000-0600 opa: PCAdach has done major rework of chan_h322 for 1.4 branch and trunk. Does the issue exist in 1.4 or trunk? By: Pash (opa__) 2006-12-12 00:49:35.000-0600 Yes. It is. It still actual for multihomed hosts. By: Paul Cadach (pcadach) 2006-12-12 02:07:58.000-0600 chan_h323 isn't able to handle bindaddr=0.0.0.0, and it is pointed in documentation. You cannot rely on information provided by H.323 stack to open RTP connection, because of many different types of connection possible (direct, GK signalling, GK proxy, etc.). By: Pash (opa__) 2006-12-15 02:01:27.000-0600 >chan_h323 isn't able to handle bindaddr=0.0.0.0, and it is pointed in documentation. My patch enables bindaddr=0.0.0.0 for some cases for beginning. Do you don't need such functionality like chan_sip do? By: Anthony LaMantia (alamantia) 2006-12-15 19:15:35.000-0600 PCadach, is it possible to add this patch to the channel from your previous comment this seems to be somewhat of a impossiblity. By: Paul Cadach (pcadach) 2006-12-22 14:27:59.000-0600 I'm just not sure it will not provide additional misoperability in complex single-homed environments (mostly GK-signalling and GK-proxy operations). By: Paul Cadach (pcadach) 2007-01-22 14:06:05.000-0600 One more or less solution I can see is to add per-user/per-peer options like: 1) externip - to set local IP address for both H.245 and RTP; 2) externrtpip - to set IP address for RTP only; 3) externh245ip - to set IP address for H.245 only. At least this should give ability to flexible change those values. After those options will be implemented, "default behavior" could be added too to handle most common cases which can be overridden by options described above. Because H.323 have many different proxying schemes, this is not possible to provide some sort of local address verification like it already done for SIP (probably it is not fully correct for SIP too). For example, your all signalling (H.323, H.245) traffic could go through GK placed somewhere in DMZ while RTP traffic goes directly between endpoints. In this case, you will know "gray" addresses while you should use your external address for RTP. BTW, Cisco gateways not allow to be multi-homed - you should specify exactly one "gateway" interface and binding address per gateway. All traffic will come from this address and not depends on which address was used by remote side. So, I think it is very complex question to have correct algorithm to choose local address on multi-homed systems. By: Paul Cadach (pcadach) 2007-02-10 03:55:25.000-0600 The patch olc2.patch is unacceptible: localIpAddr = info->addr; localPort = info->port; You took address and port of RTP stream opened for us by Asterisk + const H323Transport & transport = connection.GetControlChannel(); + transport.GetLocalAddress().GetIpAddress(localIpAddr); You unconditionally replaced address part of RTP stream with address of transport stream. No feedback from reporter for more than one month. Feel free to re-open bug if you have more correct solution. | ||