[Home]

Summary:ASTERISK-00849: RTP does not get bound to a designated IP in a multi IP linux box
Reporter:sw (sw)Labels:
Date Opened:2004-01-15 11:25:31.000-0600Date Closed:2011-06-07 14:10:42
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:When there are two (or more) IP addresses assigned to a singel LAN port, we can bind SIP messages to any IP we select using bindaddress in sip.conf file. However RTP will alwyas set it's source address to the ip address, which is in the same subnet of the 'host route', or the gateway.

We should have the flexibility to select the source IP for the RTP packets as well. An entry in the rtp.conf or simply following the bindaddress in sip channels would be a solution
NOTE :The solution given below at least solves the problem for SIP (I have not tested for the other channels)

****** ADDITIONAL INFORMATION ******

Date: Mon, 12 Jan 2004 14:03:14 -0800 (PST)
Subject: Re: [Asterisk-Users] How to bind RTP when IP alias are configured
From: "Robert Hajime Lanning" <lanning+asterisk@monsoonwind.com>
To: asterisk-users@lists.digium.com
Reply-To: asterisk-users@lists.digium.com


<quote who="SW">
> Hi Folks,
>
> I have a situation where my Colo insists on a particular IP setup for my *
> server box. They allocate two blocks of IPs to my colo >server. One set as my own (ex 20.20.20.20.4/30 - 4 ips) >and the other as a transit lan (ex 10.10.10.0/29). These >are all public IP addresses and there is no NAT involved >in. So essentially I have to set-up IP aliases in my Linux >box as follows;
>
> Example:
>
> TRANSIT LAN: 10.10.10.0/29
> CUSTOMER LAN: 20.20.20.20.4/30
>
> RedHat LINUX
>
> FILE: /etc/sysconfig/network-scripts/ifcfg-eth0
>
> DEVICE=eth0
> IPADDR=20.20.20.20.4
> NETMASK=255.255.255.255
> ONBOOT=yes
>
> FILE: /etc/sysconfig/network-scripts/ifcfg-eth0:99
>
> ####################################
> ## TRANSIT IP: DO NOT UNCONFIGURE ##
> ####################################
> DEVICE=eth0:99
> IPADDR=10.10.10.4
> NETMASK=255.255.255.248
> NETWORK=10.10.10.0
> BROADCAST=10.10.10.3
> GATEWAY=10.10.10.1
> ONBOOT=0
>
> ----------------------------
> First of all. I can ping to customer lan and telnet to >it, therefore IP routing (at least for unicast traffic) >works fine. Now question arises when asterisk start to >work on this box. Since the IP that I am supposed to use >is 20.20.20.4, I set that as bindaddress in my
> sip.conf file. As far as SIP messages are concern * users >that IP address, no problem. However for RTP stream * >users 10.10.10.4 as it's source address. Because of this >obviously calls will not go through asterisk, as
> the ip phone is expecting RTP packets from the SIP server >which is bound to IP 20.20.20.4.

>Is there a way to tell * to use the same bind address in >SIP.conf (h323.conf, iax.conf) for RTP ?????
>
> I read rtp.conf file but that does not show any bind >address.
>
> It seems like LINUX always select it's src address as the >interface (alias)which has the gateway tied to it unless >otherwise an application specifically asks Linux to use a >particular ip address.

rtp.c uses 0.0.0.0 (hardcoded, well kindof, the whole struct is initialized to zeros, so, it is just not set)

Since, to get around NAT issues, I have a host route on my firewall (Linux IPTables), I have the same problem.

In rtp.c -> function ast_rtp_new()...
       rtp->us.sin_family = AF_INET;
       /* the next line was added to fix host route hack instead of NATing */
       inet_aton("20.20.20.4",&rtp->us.sin_addr);
       rtp->s = socket(AF_INET, SOCK_DGRAM, 0);

Sorry, no context diffs.  When I get around to adding an rtp.conf keyword, I will provide context diffs to bugtrack.
Comments:By: Brian West (bkw918) 2004-01-15 14:17:22.000-0600

check externip setting in sip.conf.sample
By: Brian West (bkw918) 2004-01-15 20:06:46.000-0600

Does the externip solve your problem?
By: sw (sw) 2004-01-15 20:55:31.000-0600

Unfortunately I cant test it now. It is a production system so need to find a specific time for that. For now I've solved my issue by deleting one IP. I created this bug note as JT and Philipp von Klitzing asked me to do so. Please read the comments from Robert Hajime Lanning by the end of the bug note. Aparently he too has the same issue, wonder with externip would solve this issue. I will ask him whether he tried externip.
By: Brian West (bkw918) 2004-01-15 23:16:46.000-0600

I think externip was created to solve this so we know what ip to tag on the packets.
By: sw (sw) 2004-01-15 23:49:35.000-0600

Then could you close it (or leave it at a lower priority). If externip does not solve, I will reopen another bug note.
By: jrollyson (jrollyson) 2004-01-19 06:26:03.000-0600

Closing as requested by submitter, please reopen if its still an issue.
By: jrollyson (jrollyson) 2004-01-19 06:26:40.000-0600

Closing. Appears to be fixed by externip
By: gcc (gcc) 2004-02-20 11:22:38.000-0600

Reminder sent to bkw918, jrollyson, sw

Hi all,

Sorry for sending a reminder, since the bug is "closed" I apparently can't comment on it.

externip doesn't properly solve this problem since it doesn't cause the RTP stream to be bound to a specific address. It might allow you to tell an external server what IP to expect the SIP packets from, but on a multihomed host this isn't enough since the RTP address might still be invalid on that network. Hence the need for bindaddr in SIP, IAX, etc.

This bug is closely related to (perhaps the same as) 1019, fpr which I just posted a patch.
By: zoa (zoa) 2004-02-25 07:54:53.000-0600

Reminder sent to gcc, sw

that patch you wrote for 1019, does that resolve this bug also ?
(can i close this bug again ?)
By: gcc (gcc) 2004-02-25 07:58:58.000-0600

I believe from the bug report that my patch for 1019 would fix this issue, and that this issue could be marked as a duplicate of 1019. Neither patch for 1019 has been applied, so I would say that this issue is not actually fixed yet, and shouldn't be closed.
By: Brian West (bkw918) 2004-02-25 14:49:03.000-0600

Yes this bug note can be closed for the sake of trying to clean up the bug tracker.  1019 fixes it.  NEXT!!!