[OpenSIPS-Users] Opensips + rtpproxy + SBC

[Raistlin Majere]

Hi Trevor,

Yes we have the modparam("rtpproxy", "rtpproxy_autobridge", 1) in our
configuration. Actually, I think that we "may" run on bridge(we use it
within a Firewall so I think is possible), I don't know it, in two weeks,
this was as far I could get with the protocol/OpenSIPs/Possible
configurations :(.

modparam("rtpproxy", "rtpproxy_sock", "%CONTROL_SOCKET%")
modparam("rtpproxy", "rtpproxy_disable_tout", 10)
modparam("rtpproxy", "rtpproxy_autobridge", 1)
modparam("rtpproxy", "rtpp_notify_socket", "%TIMEOUT_NOTIFY_SOCKET%")

Other point is we are actually using a "custom" solution for the rtpproxy
as we need direct interaction with the Firewall (it is proprietary and
because of GPL we couldn't just use make a patch without exposing kernel
functionality), but bassically using the unix socket specified in the
"CONTROL_SOCKET" parameter we send commands to that process. This custom
"rtpproxy" is just reading the information on the commands, creating
possible sessions based on the call-id / totag / fromtag and creating "RTP
acceptors" on the system (It should be the same as the rtpproxy, but  we
needed it proprietary).

With the current script + custom rtpproxy we are covering more than 99% of
cases in our customers, but this specific one is pretty weird and because
of my complete ignorance on this area, I face this blocking issue with one
customer (the other Engineer had more than 5 years with SIPs configurations
and I know this would be trivial for him).

If I get more information I will share it here, probably rtp commands
received by our rtpproxy would be a good start.

Kind regards,
Jose Palma

2015-09-30 17:26 GMT+02:00 Trevor Steyn <trevor at webon.co.za>:

> HI Jose,
>
> I was not aware its running in bridge mode, Could you post your how you
> start rtpproxy?
>
> also do you have the following in your module settings
>
> modparam("rtpproxy", "rtpproxy_autobridge", 1)
>
>
>
> I have a working config of bridgemode with rtpproxy will be happy to share
> it with you just want to confirm your setup.
>
> Regards
> Trevor Steyn
>
> also you dont use rtpproxy in re-invites this would cause re-invites to
> skip rtpproxy im sure this is a mistake.
>
>
>
>
> On 30/09/2015 17:05, Raistlin Majere wrote:
>
> First of all thanks for your quick response.
>
> At the moment this is the point where we have the t_on_reply for that
> onreply_route I sent in the previous email.
>
> route[1] {
> if(!cache_fetch("local", "outerip_$var(destinationIp)", $avp(outerIp))) {
> get_outer_ip("$var(destinationIp)", "$avp(outerIp)");
> cache_store("local", "outerip_$var(destinationIp)", "$avp(outerIp)", 10);
> }
>
> $fs = $proto + ":" + $avp(outerIp);
>
> if (is_method("BYE|CANCEL")) {
> unforce_rtp_proxy();
> } else if (is_method("INVITE")){
> if (has_body("application/sdp")) {
> $var(trustconnectionip) = "%TRUSTCONNECTIONIP%";
> $var(ciptrusted) = "no";
> if ($var(trustconnectionip)=="yes") {
> $var(ciptrusted) = "yes";
> } else if ($var(trustconnectionip)=="auto") {
> $var(sdpc) = $(rb{sdp.line,c}{s.substr,9,0});
> if($td == $fd && $td != $var(sdpc)) {
> $var(ciptrusted) = "yes";
> }
> }
> if ($var(ciptrusted)=="yes") {
> rtpproxy_offer("focnr");
> } else {
> rtpproxy_offer("focn");
> }
> }
> }
>
> # Prevent $var(destinationPort) from getting default port number 5060 for
> TLS if no port specified in R-URI.
> if($(ru{uri.port})=="" && $proto=="tls" && $var(destinationPort)=="5060") {
> $var(destinationPort) = 5061;
> }
>
> # force the transport protocol to the same one the client used
> $du =
> "sip:"+$var(destinationIp)+":"+$var(destinationPort)+";transport="+$proto;
>
> t_on_reply("1");
>
> # for INVITEs enable some additional helper routes
> if (is_method("INVITE")) {
> t_on_failure("1");
> }
>
> if (!t_relay()) {
> xlog("L_INFO", "Relay error");
> sl_reply_error();
> }
> exit;
> }
>
> The route[1] is set in the main route under this conditions
>
> if (has_totag()) {
> # sequential request within a dialog should
> # take the path determined by record-routing
> if (loose_route()) {
> $var(destinationIp) = $avp(requestIp);
> $var(destinationPort) = $rp;
>
> if (is_method("INVITE")) {
> # even if in most of the cases is useless, do RR for
> # re-INVITEs alos, as some buggy clients do change route set
> # during the dialog.
> record_route();
> }
> # route it out to whatever destination was set by loose_route()
> # in $du (destination URI).
> route(1);
> ...
>        exit;
> }
> ....
>
> And if there is no REGISTER, PUBLISH, CANCEL
>
> route(1);
> }
>
> About the engage_rtp_proxy I was actually thinking about it but I'm a bit
> scared because of the bridge mode, as it is a "generic" script, I need to
> identify all this cases and create configuration cases to make scripts
> automatically for those setups.
>
> Srly, thanks for the response >.< I have only 1 week experience with this
> protocol and I'm having nightmares already.
>
> Kind regards
> Jose Palma
>
> 2015-09-30 16:51 GMT+02:00 Trevor Steyn <trevor at webon.co.za>:
>
>> HI Raistlin,
>>
>> from your script we cannot see where you are setting t_on_reply routes as
>> im sure this is where you are probably missing the rtpproxy_answer() but
>> cannot see why as that part of the script is missing
>>
>>
>> maybe you can also try use engage_rtp_proxy() and you wont have to worry
>> about the answer and you could remove the reply routes and just relay
>>
>> if ($var(ciptrusted)=="yes") {
>> engage_rtp_proxy("focnr");
>> } else {
>> engage_rtpproxy("focn");
>> }
>>
>> Regards
>> Trevor Steyn
>>
>>
>>
>>
>>
>> On 30/09/2015 14:56, Raistlin Majere wrote:
>>
>> Hi,
>>
>> Recently the maintainer of the SIPs proxy in our company quit, and well
>> I'm the new in charge of this project, the bad new is I had 0 experience
>> with SIP.  After some week I got my first case related to our "SIP proxy".
>>
>> We are using OpenSIP 1.8 within our Firewall to handle the protocol and
>> the NAT that it will imply within a Firewall. The script my ex coworker did
>> is working in 99% of cases but this specific case.
>>
>> The customer has one setup like this
>>
>>
>> PhoneA
>> PhoneB
>> PhoneC --- Call Manager --- Firewall --- SBC --- Farm of RTP Media servers
>> ....
>> PhoneN
>>
>> The opensips instance is running within the firewall. The next IPs are
>> fake but follow the "rules" of internal/external it is just to avoid
>> problems
>>
>> Call Manager: 172.17.1.1
>> Firewall: Internal Network 192.168.0.10
>> Firewall: Extenal Network 62.1.1.10
>> SBC: 210.200.100.100
>> Farm of Media Servers: 210.200.100.128/25
>>
>> So the invite works as Expected but on the 180 Ringing either 200 OK the
>> moment the messages traverse the SIP proxy, doesn't contain the "farm" IP
>> but the SBC IP.
>>
>> This are the 180 Ringing:
>>
>> From SBC to the Firewall
>>
>> SIP/2.0 180 Ringing
>> Via: SIP/2.0/UDP 62.1.1.10:5060;branch=z9hG4bKd091.937a047.0
>> Via: SIP/2.0/UDP 172.17.1.1:5060
>> ;rport=5060;received=172.17.1.1;branch=z9hG4bKac393424402
>> From: <sip:5000 at 210.200.100.100>;tag=1c393411873
>> To: <sip:5001 at 210.200.100.100;user=phone>;tag=gK08c71cc5
>> Call-ID: 39341083229920151062 at 172.17.1.1
>> CSeq: 1 INVITE
>> Record-Route: <sip:62.1.1.10:5060;r2=on;lr;did=6d8.933abaa6>
>> Record-Route: <sip:192.168.0.10:5060;r2=on;lr;did=6d8.933abaa6>
>> Contact: <sip:5001 at 210.200.100.100:5060>
>> Allow:
>> INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH
>> Require: 100rel
>> RSeq: 433990
>> Content-Length:   266
>> Content-Disposition: session; handling=required
>> Content-Type: application/sdp
>>
>> v=0
>> o=Sonus_UAC 176482 50736 IN IP4 210.200.100.100
>> s=SIP Media Capabilities
>> c=IN IP4 210.200.100.243
>> t=0 0
>> m=audio 61348 RTP/AVP 8 101
>> a=rtpmap:8 PCMA/8000
>> a=rtpmap:101 telephone-event/8000
>> a=fmtp:101 0-15
>> a=sendrecv
>> a=ptime:20
>> a=silenceSupp:off - - - -
>>
>> After the firewall + Opensips have processed this message to the call
>> center
>>
>> SIP/2.0 180 Ringing
>> Via: SIP/2.0/UDP 172.17.1.1:5060;branch=z9hG4bKac393424402
>> From: <sip:5000 at 210.200.100.100>;tag=1c393411873
>> To: <sip:5001 at 210.200.100.100;user=phone>;tag=gK08c71cc5
>> Call-ID: 39341083229920151062 at 172.17.1.1
>> CSeq: 1 INVITE
>> Record-Route: <sip::62.1.1.10:5060;r2=on;lr;did=6d8.933abaa6>
>> Record-Route: <sip:192.168.0.10:5060;r2=on;lr;did=6d8.933abaa6>
>> Contact: <sip:5001 at 210.200.100.100>
>> Allow:
>> INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH
>> Require: 100rel
>> RSeq: 433990
>> Content-Length: 295
>> Content-Disposition: session; handling=required
>> Content-Type: application/sdp
>>
>> v=0
>> o=Sonus_UAC 176482 50736 IN IP4 210.200.100.100
>> s=SIP Media Capabilities
>> t=0 0
>> m=audio 4845 RTP/AVP 8 101
>> a=rtpmap:8 PCMA/8000
>> a=rtpmap:101 telephone-event/8000
>> a=fmtp:101 0-15
>> a=sendrecv
>> a=ptime:20
>> a=silenceSupp:off - - - -
>> a=nortpproxy:yes
>> c=IN IP4 210.200.100.100
>> a=rtcp:4848
>>
>> ----
>>
>> The RTP "acceptor" is created under the IP 210.200.100.100 instead of the
>> IP 210.200.243 as the SIPproxy is changing the SDP connection information.
>>
>>
>> This is the logic we are using in our script for the INVITE and for the
>> onreply_route
>>
>> if (is_method("INVITE")){
>> if (has_body("application/sdp")) {
>> $var(trustconnectionip) = "%TRUSTCONNECTIONIP%";
>> $var(ciptrusted) = "no";
>> if ($var(trustconnectionip)=="yes") {
>> $var(ciptrusted) = "yes";
>> } else if ($var(trustconnectionip)=="auto") {
>> $var(sdpc) = $(rb{sdp.line,c}{s.substr,9,0});
>> if($td == $fd && $td != $var(sdpc)) {
>> $var(ciptrusted) = "yes";
>> }
>> }
>> if ($var(ciptrusted)=="yes") {
>> rtpproxy_offer("focnr");
>> } else {
>> rtpproxy_offer("focn");
>> }
>> }
>> }
>>
>>
>>
>> And on the onreply
>>
>> if (has_body("application/sdp")) { $var(trustconnectionip) =
>> "%TRUSTCONNECTIONIP%"; $var(ciptrusted) = "no"; if
>> ($var(trustconnectionip)=="yes") { $var(ciptrusted) = "yes"; } else if
>> ($var(trustconnectionip)=="auto") { $var(sdpc) =
>> $(rb{sdp.line,c}{s.substr,9,0}); if($td == $fd && $td != $var(sdpc)) {
>> $var(ciptrusted) = "yes"; } } if ($var(ciptrusted)=="yes") {
>> rtpproxy_answer("fr"); } else { rtpproxy_answer("f"); } }
>>
>>
>> Where TRUSTONNECTIONIP = "no" so basically we are doing
>>
>> rptproxy_offer("focn") and rtpproxy_answer("f").
>>
>> Kind regards:
>>
>> Jose Palma
>>
>>
>>
>>
>> _______________________________________________
>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20150930/da91fe8b/attachment-0001.htm>