5 Nov
2011
5 Nov
'11
12:59 p.m.
Hey Klaus,
Thanks alot for your help, it was really helpful to understand few things.
but the situation is the same :( unfortunately. Now I've two Asterisks one
on Private and the other on Public.
The Asterisk on PublicIP works well if I don't run RTPproxy in bridged mode
!
The Asterisk on Private IP's situation remains the same. You're right about
the RTPproxy not utilising its PrivateIP but I've tried all possible
options for force_rtp_proxy() - rtp_manage() is a great relaxation but
unfortunately I'm not using devel.
I'm going to keep on trying until I finally make it work.
Any comments/suggestions from the List users is highly appreciated.
Regards,
Sammy
On Fri, Nov 4, 2011 at 7:08 PM, Klaus Darilion <klaus.mailinglists(a)pernau.at
wrote:
On 04.11.2011 10:57, Sammy Govind wrote:
SORRY for PM but this is not getting through to
the users List due to
size.
I have cc-ed the list.
---------- Forwarded message ----------
From: *Sammy Govind* <govoiper(a)gmail.com <mailto:govoiper@gmail.com>>
Date: Fri, Nov 4, 2011 at 1:55 PM
Subject: Re: [SR-Users] Kamailio as SBC / LB Media-Servers farm
To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
Users Mailing List" <sr-users(a)lists.sip-router.org
<mailto:sr-users@lists.sip-**router.org <sr-users(a)lists.sip-router.org>>>
Klaus: mhomed did work indeed - no need to force_send_socket() now :)
Thanks
I'm progressing abit.
RTP-Proxy was run in bridged mode like this.
*rtpproxy -l 109.XX.XXX.212/192.168.2.29 <http://192.168.2.29> -s
udp:localhost:22222 -F -d DBUG*
See description of i,e flag:
http://kamailio.org/docs/**modules/3.2.x/modules/**rtpproxy.html#id2535618&…
Thus in your setup 109.... is the "internal" interface and 192.... is the
"external" interface. That's mixed. Thus I advice you to switch the order
of IP addresses so that internal is 192... and external is 109...
This is essential to use the i,e flags correctly.
I'm getting RTPstats published on Kamailio/RTPproxy syslog.
I am using Echo() application in asterisk. So I've observed that my
audio went to asterisk and asterisk did indeed send audio back to the
RTPproxy assigned ports BUT the RTPproxy isn't forwarding the Audio back
to the client or may-be the audio is lost somewhere in between
RTPproxy<--->Client. /[See Wirshark Flow-Diagram taken
on-Kamailio/RTPproxy Server]/
In your trace you see, that RTP does not use the internal IP address, but
only the external IP address. Thus I suspect that the RTP packets from
Asterisk to the public rtpproxy interface do not even arrive at rtpproxy.
The # DTMF signal sent from Client phone reached
asterisk safely and
terminated the Echo() application.
I did the ip_forwarding thingie too.-- somebody mentioned to do this if
using RTPproxy in bridged mode.
This is bullshit. People seem to not understand IP at all. rtpproxy is
forwarding in user mode - it receives on a UDP socket and sends on a UDP
socket. Thus, kernel based forwarding is not involved when using rtpproxy.
You can disable IP forwarding again.
#echo "1" >> /proc/sys/net/ipv4/ip_forward
#sysctl -p
Here are the corresponding Logs from Kamailio and rtpproxy.
The thing is quite easy. Swap the IP addresses when starting rtpproxy and
then configure Kamailio to call rtpproxy with the proper i,e flags (as
described in my previous email).
For example:
if (has_body("application/sdp")) {
if ($si == "192.168.2.75") {
# message from internal to external
rtpproxy_manage("ie");
} else {
# message from external to internal
rtpproxy_manage("ei");
}
}
Put above code block in the main route block and also in a reply route
which will be activated (or in the default reply route). Put some xlog
statements around the rtpproxy calls to verify the proper command is called.
regards
Klaus