[SR-Users] Fwd: Kamailio as SBC / LB Media-Servers farm

[Sammy Govind]

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 at 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 at gmail.com <mailto:govoiper at 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 at lists.sip-router.org
>> <mailto:sr-users at lists.sip-**router.org <sr-users at 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<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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20111105/35b8e034/attachment-0001.htm>