Summary:	ASTERISK-01013: [patch] Binding RTP to a specific interface
Reporter:	ncruz (ncruz)	Labels:
Date Opened:	2004-02-09 12:01:21.000-0600	Date Closed:	2011-06-07 14:04:45
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) add_bindaddr_to_rtp.patch ( 1) asterisk-0.7.2-rtp-bind.patch ( 2) rtp-bindaddr-patch-cvs20040325.txt
Description:	This patch allows to bind RTP flows to a specific interface, additionally the SDP session descriptor get's coherent with the same address that is used for RTP traffic, this includes sip<->sip and sip<->voicemail and others(not tested, but should work). Maybe some problems with NAT appear, if anyone notices any bug just tell me :) The patch applies fine to the CVS version at the time of writing this message.
Comments:	By: ncruz (ncruz) 2004-02-09 12:06:16.000-0600 Just forgot to say to add to [general] in rtp.conf "bindaddr=yo.u.r.ip" By: gcc (gcc) 2004-02-20 11:03:25.000-0600 I've attached another patch which I've just developed, which is slightly different (asterisk-0.7.2-rtp-bind.patch) It doesn't require any extra configuration, since instead of specifying one IP address to bind to in rtp.conf, this patch binds the RTP socket to the same IP as the calling module's socket. Tested and works for me, doesn't require any extra config. By: ncruz (ncruz) 2004-02-20 16:19:01.000-0600 Mine is a little more generic, it allows you to have a different interface for rtp flows... Have you tried to dial voicemail and check if that works? For sip<->sip this problem is already resolved by current cvs version, it only has problems with voicemail, and maybe some other applications (meetme? i haven't tested it)... By: gcc (gcc) 2004-02-23 05:38:01.000-0600 But your patch doesn't allow one to use different interfaces for, say, SIP and MGCP. Why would you want to use a different interface for RTP than the one where the request from the phone came in on? After all, how else do you deliver packets to the phone? I haven't tested voicemail as I don't use it, sorry. How is this problem resolved by CVS? I haven't noticed any patches which might make a difference. By: mh720 (mh720) 2004-02-28 12:50:32.000-0600 I use only sip, no mgcp,h323,skinny. I started off using the patch by gcc, but have been seeing sip peer registrations to ser stop after about a day on multiple asterisk servers, and I've been getting these warnings to /var/log/asterisk/messages: Feb 27 14:33:28 WARNING[49156]: Unexpected bind error: Invalid argument Feb 27 14:33:28 WARNING[49156]: Unable to create RTP session: Inappropriate ioctl for device Feb 27 14:33:28 WARNING[49156]: Unable to allocate registration call I've patched using patch and also have patched each file manually with the same results after about a day. I'm testing ncruz's patch now, working so far.  ncruz, want to update chan_h323/mgcp/skinny too? By: ncruz (ncruz) 2004-02-28 13:33:37.000-0600 Sure! i'll try! just got to check how those protocols work :), i don't use any of them also.. By: mh720 (mh720) 2004-03-08 00:10:52.000-0600 I've moved ncruz's patch onto our production servers for about a week now and have had no problems. By: mh720 (mh720) 2004-03-25 13:57:17.000-0600 Just updated ncruz's rtp patch to cvs 3-25-2004, basically just adding: struct timeval dtmfmute; to ast_rtp in rtp.h this patch still needs to be applied to the other channels, currently only works for chan_sip By: ncruz (ncruz) 2004-03-26 06:32:41.000-0600 Sorry, haven't got the time to do it :( By: slepp (slepp) 2004-04-02 02:50:29.000-0600 Another implementation of this can be found at bug ASTERISK-1316. By: twisted (twisted) 2004-04-02 23:49:16.000-0600 So are we going to use mine and close this one out?  I'm seeing double, and know it's my fault, but I'd like to see one of these applied, and both closed. By: ncruz (ncruz) 2004-04-03 07:19:44.000-0600 Yours only work if bindaddr in rtp conf is equal to bindaddr in sip conf, your patch doesn't work if you would want to use a different interface for ip traffic. Mine only does this for sip, i didn't have the time to port it to other channels, as requested, tough. edited on: 04-03-04 06:35 By: Olle Johansson (oej) 2004-04-17 17:20:41 Gentlemen, I would really like to see an agreement on which patch to move forward. I can't see that we have that now. Two patches is one to many. Work to solve this. By: twisted (twisted) 2004-04-19 19:15:34 Actually, I'm going to reopen this one and close mine, as It is correct that I do not compare to sip.conf, nor do i check getbyhostname to return results, or even check validity of the IP entered.  Mine was a quick fix that works if rtp.c tries to bind to a master interface of a multi-homed system, and that's it.   Keep this one one open and let's run here. By: mh720 (mh720) 2004-04-20 14:59:18 Having implemented all 3 patches, I believe twisted is correct, ncruz's patch seems the most likely candidate as it does the proper validation and works reliably as tested by me.  The bindaddr line is also optional, so will bind to 0.0.0.0 if omitted (as functions without this patch).   The only problem I forsee with moving it into cvs head is that rtp.conf then has an optional bindaddr line that only applies to SIP.   Could we consider adding this to head and adding a comment in rtp.conf bindaddr=x.x.x.x ; currently only used for sip until someone steps up and writes chan_h323/mgcp/skinny to take advantage of the config option?  This is a much requested feature as service providers (such as me) deploy multiple copies of asterisk per box. By: Olle Johansson (oej) 2004-04-24 14:44:37 I think we should have a rtpbindaddr=x.x.x.x in sip.conf if it only applies to sip. On the other hand, if the binding applies to all channels that use RTP, it should stay in rtp.conf. Please enlighten me! Since thte H323 channels is undergoing a major rewrite, we need to inform Jeremy about this. By: ncruz (ncruz) 2004-04-24 15:00:20 In the other channels, you just have to check if the ast_rtp struct returned has a us.sin_addr.s_addr different from INADDR_ANY, if this happens you just have to use that address for the "sdp body" (or wathever that channel uses). By: Olle Johansson (oej) 2004-04-26 16:40:54 Do we break anything in the other channels meaning they have to change their code if this patch is applied? ----------- Also need more positive test reports. If you are using this patch, add your comments to the bug tracker. Show your support of moving this patch forward to be integrated into Asterisk - the greatest Open Source PBX out there :-) By: mh720 (mh720) 2004-04-27 16:38:07 No, all other channels ignore the bindaddr configuration option in rtp.conf.  They will bind to 0.0.0.0 By: Mark Spencer (markster) 2004-05-01 18:27:04 Out of curiosity, what is the advantage of using this patch? By: ncruz (ncruz) 2004-05-01 19:01:32 The same advantage of having bindaddr in sip for example. By: twisted (twisted) 2004-05-01 19:55:20 Well, i'm assuming this does the same functionality as mine did, but it just allows you to bind your rtp to a specific interface for a multi-homed or multi-nic system, especially fixes things with virtual servers, I've been able to prove this theory with someone from IRC.. By: Mark Spencer (markster) 2004-05-03 00:00:43 Why don't we just add a parameter struct inaddr *addr to ast_rtp_new, and if it's NULL we do what we do now, and if it's not NULL then we use it. Then we can just use the ouraddr field in sip or whatever to populate it. By: Mark Spencer (markster) 2004-05-03 00:01:21 Let me clarify i don't want the rtp structure exposed outside of rtp.c By: ncruz (ncruz) 2004-05-03 03:06:56 Ok, i don't see any problem with that, you could also create another function for example ast_rtp_get_bindaddr like the one used to get the peer or just use ast_rtp_get_us and do the checking afterwards... By: Mark Spencer (markster) 2004-05-03 09:15:29 Sure, that's fine. By: flavour (flavour) 2004-05-18 10:15:06 Another implmentation is in: ASTERISK-1643 By: Brian West (bkw918) 2004-05-18 22:47:45 look at the latest one