Hi,
mhomed did the trick nicely for ser, but force_rtp_proxy is putting the wrong interface in the c= bit of the outgoing INVITE. c= is getting the IP address of the internal interface, not the external. There doesn't seem to be any way of working around this at the moment, or am I missing something?
Unless someone has something lying around to solve this I don't mind working on it myself, unless I am missing something and this is a particularly hard thing to sort out.
I suspect there are ways round this by masqerading on the ser box but I don't want to do that and would much rather not have to enable ip forwarding on the box at all.
In such situations binding both RTP proxy and SER to some specific IP address (option -l <IP>) can help.
-Maxim
Tristan Colgate wrote:
Hi,
mhomed did the trick nicely for ser, but force_rtp_proxy is putting the wrong interface in the c= bit of the outgoing INVITE. c= is getting the IP address of the internal interface, not the external. There doesn't seem to be any way of working around this at the moment, or am I missing something?
Unless someone has something lying around to solve this I don't mind working on it myself, unless I am missing something and this is a particularly hard thing to sort out.
I suspect there are ways round this by masqerading on the ser box but I don't want to do that and would much rather not have to enable ip forwarding on the box at all.
Sorry to reply to myself,
OK, I've started looking at this but there seems to be a basic, pretty much unsovelable problem. In the case of an invite we don't actually know for sure where the other end of the conversation is going to be, since we havent seen the sdp in the OK by that stage.
The only thing I can think of, is to listen on the interface that the INVITE request itself will go out on, this isn't the same thing obviously. It will work for the setup I have, infact I already make similar assumptions when deciding whether or not to rtp proxy in the first place.
Any thaughts?
Tristian, When INVIVE arrives to you try to modify SIP body - SDP "c=" with means of "replace" function of textopt.so module. The decision to modify body may be taken based of source IP and uri. On reply to route you will need to modify "c=" again and put another NIC's IP. I've tryed to do it today but with some errors. I'll try tomorow again. It will be the best if force_rtp_proxy() funtion have optional parameter - IP address which it will put in SDP body when function is called.
Regards, Greg.
--- Tristan Colgate tristan@inuxtech.co.uk wrote:
Sorry to reply to myself,
OK, I've started looking at this but there seems to be a basic, pretty much unsovelable problem. In the case of an invite we don't actually know for sure where the other end of the conversation is going to be, since we havent seen the sdp in the OK by that stage.
The only thing I can think of, is to listen on the interface that the INVITE request itself will go out on, this isn't the same thing obviously. It will work for the setup I have, infact I already make similar assumptions when deciding whether or not to rtp proxy in the first place.
Any thaughts?
-- Tristan Colgate Inux Technologies
E-Mail: tristan@inuxtech.co.uk Mobile: 07900 690 912
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
__________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
Hi,
I tried using the textops approach since it seemed the most sensible (wish I had thaught of it), shame it didn't actually work :( HOWEVER, I've done a rough cut of a force_rtp_proxy_from and it seems to work, atleast it correctly munges the rtp traffic and I see it appearing on my lan (This stuff would be impossible to work with without ethereal!!).
Neither of the SIP ua's are behaving themselves though, kphone sees the ack and says it is connected but I don;t hear the audio, a grandstream budget one doesn't even pick up on the ack (it see's the Ringing status from the other end though).
I'll tidy up the code and pass it to the relevant people.
On Tue, Nov 25, 2003 at 06:23:35AM -0800, Gregory Sandul wrote:
Tristian, When INVIVE arrives to you try to modify SIP body - SDP "c=" with means of "replace" function of textopt.so module. The decision to modify body may be taken based of source IP and uri. On reply to route you will need to modify "c=" again and put another NIC's IP. I've tryed to do it today but with some errors. I'll try tomorow again. It will be the best if force_rtp_proxy() funtion have optional parameter - IP address which it will put in SDP body when function is called.
Regards, Greg.
--- Tristan Colgate tristan@inuxtech.co.uk wrote:
Sorry to reply to myself,
OK, I've started looking at this but there seems to be a basic, pretty much unsovelable problem. In the case of an invite we don't actually know for sure where the other end of the conversation is going to be, since we havent seen the sdp in the OK by that stage.
The only thing I can think of, is to listen on the interface that the INVITE request itself will go out on, this isn't the same thing obviously. It will work for the setup I have, infact I already make similar assumptions when deciding whether or not to rtp proxy in the first place.
Any thaughts?
-- Tristan Colgate Inux Technologies
E-Mail: tristan@inuxtech.co.uk Mobile: 07900 690 912
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
SRATCH THAT!!! it only bloomin' works!!! I upgraded asterisk on the target box and the grandstream now works, kphone is still not playing ball, I'm not entirely sure why there, but getting the grandstream going is a big step forward.
On Tue, Nov 25, 2003 at 06:23:35AM -0800, Gregory Sandul wrote:
Tristian, When INVIVE arrives to you try to modify SIP body - SDP "c=" with means of "replace" function of textopt.so module. The decision to modify body may be taken based of source IP and uri. On reply to route you will need to modify "c=" again and put another NIC's IP. I've tryed to do it today but with some errors. I'll try tomorow again. It will be the best if force_rtp_proxy() funtion have optional parameter - IP address which it will put in SDP body when function is called.
Regards, Greg.
--- Tristan Colgate tristan@inuxtech.co.uk wrote:
Sorry to reply to myself,
OK, I've started looking at this but there seems to be a basic, pretty much unsovelable problem. In the case of an invite we don't actually know for sure where the other end of the conversation is going to be, since we havent seen the sdp in the OK by that stage.
The only thing I can think of, is to listen on the interface that the INVITE request itself will go out on, this isn't the same thing obviously. It will work for the setup I have, infact I already make similar assumptions when deciding whether or not to rtp proxy in the first place.
Any thaughts?
-- Tristan Colgate Inux Technologies
E-Mail: tristan@inuxtech.co.uk Mobile: 07900 690 912
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
-
Gregory Sandul -
Maxim Sobolev -
Tristan Colgate