25 Nov
2003
25 Nov
'03
12:37 p.m.
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.
--
Tristan Colgate
Inux Technologies
E-Mail: tristan(a)inuxtech.co.uk
Mobile: 07900 690 912
25 Nov
25 Nov
1:12 p.m.
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.
3:53 p.m.
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(a)inuxtech.co.uk
Mobile: 07900 690 912
4:23 p.m.
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(a)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(a)inuxtech.co.uk
Mobile: 07900 690 912
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
7:05 p.m.
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(a)inuxtech.co.uk> wrote:
--
Tristan Colgate
Inux Technologies
E-Mail: tristan(a)inuxtech.co.uk
Mobile: 07900 690 912
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(a)inuxtech.co.uk
Mobile: 07900 690 912
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
7:31 p.m.
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(a)inuxtech.co.uk> wrote:
--
Tristan Colgate
Inux Technologies
E-Mail: tristan(a)inuxtech.co.uk
Mobile: 07900 690 912
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(a)inuxtech.co.uk
Mobile: 07900 690 912
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
7668
days inactive
7668
days old
5 comments
3 participants
participants (3)
-
Gregory Sandul -
Maxim Sobolev -
Tristan Colgate