[OpenSIPS-Users] RTPproxy + Opensips 1.7.0

Razvan Crainea razvancrainea at opensips.org
Tue Nov 8 12:39:50 CET 2011


Hi Sebastien,

I think I found out what is your problem. As you noted, there are two 
"select_rtpp_node" functions calls for only one INVITE. The problem is 
that the first time OpenSIPS sends a command to RTPProxy, it receives an 
error. If OpenSIPS detecs the error, it automatically disables the node 
for a while (exactly for rn_recheck_ticks seconds, your second question) 
and tries a new node. As you don't have any different node in the set, 
no RTPProxy can be used and an error is triggered.
You should try to see why RTPProxy returns an error to OpenSIPS 
requests. You can check RTPProxy logs, or try to trace the communication 
between them. I'd be happy to help you if you can provide me any of this 
information.

Regards,

--
Ra(zvan Crainea
OpenSIPS Developer


On 11/08/2011 01:22 PM, Sebastien CRUAUX wrote:
> Hi Razvan,
>
> Actually we don't even enter in the rtpp_test function. I added some 
> other traces in the select_rtpp_node function :
>
>         if (selected_rtpp_set->rtpp_node_count == 1) {
>                 LM_INFO("rtpproxy node count = 1\n");
>                 node = selected_rtpp_set->rn_first;
>                 LM_INFO("node->rn_disabled = %d, 
> node->rn_recheck_ticks = %d, get_ticks = 
> %d\n",node->rn_disabled,node->rn_recheck_ticks,get_ticks());
>                 if (node->rn_disabled && node->rn_recheck_ticks <= 
> get_ticks())
>                         node->rn_disabled = rtpp_test(node, 1, 0);
>                 LM_INFO("result rtpp_test = %d\n", node->rn_disabled);
>                 return node->rn_disabled ? NULL : node;
>         }
>
> and here is what I get when an INVITE is received :
>
> Nov  8 11:19:01 WWW_64Bits ./opensips[24317]: INFO :: (INVITE) 
> rtpproxy set 1
> Nov  8 11:19:01 WWW_64Bits ./opensips[24317]: 
> INFO:rtpproxy:select_rtpp_node: entering select_rtpp_node
> Nov  8 11:19:01 WWW_64Bits ./opensips[24317]: 
> INFO:rtpproxy:select_rtpp_node: rtpproxy node count = 1
> Nov  8 11:19:01 WWW_64Bits ./opensips[24317]: 
> INFO:rtpproxy:select_rtpp_node: node->rn_disabled = 0, 
> node->rn_recheck_ticks = 0, get_ticks = 121
> Nov  8 11:19:01 WWW_64Bits ./opensips[24317]: 
> INFO:rtpproxy:select_rtpp_node: result rtpp_test = 0
> Nov  8 11:19:01 WWW_64Bits ./opensips[24317]: 
> INFO:rtpproxy:select_rtpp_node: entering select_rtpp_node
> Nov  8 11:19:01 WWW_64Bits ./opensips[24317]: 
> INFO:rtpproxy:select_rtpp_node: rtpproxy node count = 1
> Nov  8 11:19:01 WWW_64Bits ./opensips[24317]: 
> INFO:rtpproxy:select_rtpp_node: node->rn_disabled = 1, 
> node->rn_recheck_ticks = 181, get_ticks = 121
> Nov  8 11:19:01 WWW_64Bits ./opensips[24317]: 
> INFO:rtpproxy:select_rtpp_node: result rtpp_test = 1
> Nov  8 11:19:01 WWW_64Bits ./opensips[24317]: 
> ERROR:rtpproxy:force_rtp_proxy_body: no available proxies
>
> You can see we never enter in the "if" :(
> Consequently, I have several questions :
> - why do we see 2 calls to select_rtpp_node while we have chosen only 
> the rtpproxy set 1 ?
> - what does the node->rn_recheck_ticks parameter means ?
> - do you think the bug is in my opensips.cfg or in the rtpproxy module ?
>
> Thanks a lot for your help.
>
> Best regards,
>
> Sebastien
>
> Le 08/11/2011 12:10, Razvan Crainea a écrit :
>> Hi Sebastien,
>>
>> No, if rtpp_test returns 1, it means that the chosen rtpproxy node 
>> should be disabled for a while. You should try to see why OpenSIPS 
>> detects the node as disabled.
>>
>> Regards,
>> --
>> Ra(zvan Crainea
>> OpenSIPS Developer
>>
>> On 11/07/2011 04:31 PM, Sebastien CRUAUX wrote:
>>> Hi Razvan,
>>>
>>> I added some INFO traces in the select_rtpp_node function in order 
>>> to get some clues about what happens (see enclosed file).
>>> Here is what is displayed in my /var/log/messages when an INVITE is 
>>> received :
>>>
>>> Nov  7 15:21:38 WWW_64Bits ./opensips[19884]: INFO :: (INVITE) 
>>> rtpproxy set 1
>>> Nov  7 15:21:38 WWW_64Bits ./opensips[19884]: 
>>> INFO:rtpproxy:select_rtpp_node: entering select_rtpp_node
>>> Nov  7 15:21:38 WWW_64Bits ./opensips[19884]: 
>>> INFO:rtpproxy:select_rtpp_node: rtpproxy node count = 1
>>> Nov  7 15:21:38 WWW_64Bits ./opensips[19884]: 
>>> INFO:rtpproxy:select_rtpp_node: result rtpp_test = 0
>>> Nov  7 15:21:38 WWW_64Bits ./opensips[19884]: 
>>> INFO:rtpproxy:select_rtpp_node: entering select_rtpp_node
>>> Nov  7 15:21:38 WWW_64Bits ./opensips[19884]: 
>>> INFO:rtpproxy:select_rtpp_node: rtpproxy node count = 1
>>> Nov  7 15:21:38 WWW_64Bits ./opensips[19884]: 
>>> INFO:rtpproxy:select_rtpp_node: result rtpp_test = 1
>>> Nov  7 15:21:38 WWW_64Bits ./opensips[19884]: 
>>> ERROR:rtpproxy:force_rtp_proxy_body: no available proxies
>>>
>>> This is really weird, if rtpp_test returns 1, it should mean that 
>>> the rtpproxy socket was found right ? Then why do we have an error 
>>> message saying that there are no available proxies ? I'm confused...
>>>
>>> Best regards,
>>>
>>> Sebastien
>>>
>>> Le 04/11/2011 15:23, Razvan Crainea a écrit :
>>>> Hi Sebastien,
>>>>
>>>> I will try to replicate this scenario and see if I am getting the 
>>>> same behaviour. I will get back to you later.
>>>>
>>>> Regards,
>>>> --
>>>> Ra(zvan Crainea
>>>> OpenSIPS Developer
>>>>
>>>> On 11/04/2011 04:20 PM, Sebastien CRUAUX wrote:
>>>>> I also tried to enter the rtpproxy_sock parameters and the set IDs 
>>>>> in the nh_sockets table and to load the rtpproxy sets from the 
>>>>> database but it did not work either :(
>>>>>
>>>>> Sebastien
>>>>>
>>>>> Le 04/11/2011 11:52, Sebastien CRUAUX a écrit :
>>>>>> Hi Razvan,
>>>>>>
>>>>>> Yes I think I declared the rtpproxy sets correctly, unless there 
>>>>>> is some new parameter in the new rtpproxy module that I forgot :
>>>>>>
>>>>>> # ----- rtpproxy params -----
>>>>>> modparam("rtpproxy", "rtpproxy_sock", "1 == udp:localhost:12221")
>>>>>> modparam("rtpproxy", "rtpproxy_sock", "2 == udp:localhost:12222")
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Sebastien
>>>>>>
>>>>>> Le 04/11/2011 11:44, Razvan Crainea a écrit :
>>>>>>> Hi Sebastien,
>>>>>>>
>>>>>>> Are you sure that when you declare the RTPProxy sets you 
>>>>>>> allocate them the set identifiers (1 and 2)? Can you send us the 
>>>>>>> rtpproxy_sock parameters declaration?
>>>>>>>
>>>>>>> Regards,
>>>>>>> --
>>>>>>> Ra(zvan Crainea
>>>>>>> OpenSIPS Developer
>>>>>>>
>>>>>>> On 11/04/2011 12:27 PM, Sebastien CRUAUX wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I am currently migrating my old Opensips 1.6.2 to the new 
>>>>>>>> Opensips 1.7.0 but I am facing some issues with the 
>>>>>>>> configuration of rtpproxy.
>>>>>>>> The version of rtpproxy I am using is the commit 
>>>>>>>> 6b82ff914543d21ff9ddbb797b40a77516348308.
>>>>>>>>
>>>>>>>> When I start Opensips, the two sets of rtpproxies I configured 
>>>>>>>> are detected :
>>>>>>>>
>>>>>>>> INFO:rtpproxy:rtpp_test: rtp proxy <udp:localhost:12221> found, 
>>>>>>>> support for it enabled
>>>>>>>> INFO:rtpproxy:rtpp_test: rtp proxy <udp:localhost:12222> found, 
>>>>>>>> support for it enabled
>>>>>>>>
>>>>>>>> However, when an INVITE is received by Opensips it seems 
>>>>>>>> rtpproxy is not found, consequently the SDP body is not rewritten :
>>>>>>>>
>>>>>>>> INFO :: (INVITE) rtpproxy set 1
>>>>>>>> ERROR:rtpproxy:force_rtp_proxy_body: no available proxies
>>>>>>>>
>>>>>>>> More information about my configuration :
>>>>>>>> - my Opensips/rtpproxy server has 2 IP addresses, one opened on 
>>>>>>>> the internet, one internal used to communicate with my 
>>>>>>>> VoIP/PSTN gateway
>>>>>>>> - I have 2 sets of rtpproxies : the 1st one is in bridge mode 
>>>>>>>> for VoIP to PSTN or PSTN to VoIP calls, the 2nd one only 
>>>>>>>> listens on the external IP and is used for SIP to SIP calls
>>>>>>>>
>>>>>>>>     ./rtpproxy -u seb -l 172.17.1.126 172.17.1.131 -s 
>>>>>>>> udp:localhost 12221 -m 18000 -M 18020
>>>>>>>>     ./rtpproxy -u seb -l 172.17.1.131 -s udp:localhost 12222 -m 
>>>>>>>> 18021 -M 18030
>>>>>>>>
>>>>>>>> - below is the part of my opensips.cfg file which handles the 
>>>>>>>> INVITE requests (I just replaced my public IP address with 
>>>>>>>> xx.xx.xx.xx) :
>>>>>>>>
>>>>>>>>         if (is_method("INVITE")) {
>>>>>>>>                 if (registered("location","$fu") && 
>>>>>>>> registered("location")) {      # if From and To are SIP 
>>>>>>>> registered : we use rtpproxy 2 (external IP)
>>>>>>>>                         setflag(22);
>>>>>>>>                         xlog("INFO :: (INVITE) rtpproxy set 2");
>>>>>>>>                 }
>>>>>>>>                 else 
>>>>>>>> {                                                             # 
>>>>>>>> otherwise, SIP to ISUP or ISUP to SIP call : we use rtpproxy 1 
>>>>>>>> (bridge mode)
>>>>>>>>                         xlog("INFO :: (INVITE) rtpproxy set 1");
>>>>>>>>                 }
>>>>>>>>                 if (has_body("application/sdp")) {
>>>>>>>>                         if (isflagset(22)) {
>>>>>>>>                                 set_rtp_proxy_set("2");
>>>>>>>>                                 if 
>>>>>>>> (rtpproxy_offer("","xx.xx.xx.xx")) {
>>>>>>>>                                         t_on_reply("1");
>>>>>>>>                                 }
>>>>>>>>                         }
>>>>>>>>                         else {
>>>>>>>>                                 set_rtp_proxy_set("1");
>>>>>>>>                                 if (dst_ip == 172.17.1.131) 
>>>>>>>> {                      # my IP address opened to the internet 
>>>>>>>> (external IP)
>>>>>>>>                                         if 
>>>>>>>> (rtpproxy_offer("ei","xx.xx.xx.xx")) {
>>>>>>>>                                                 t_on_reply("1");
>>>>>>>>                                         }
>>>>>>>>                                 }
>>>>>>>>                                 if (dst_ip == 172.17.1.126) 
>>>>>>>> {                      # my internal IP address
>>>>>>>>                                         if 
>>>>>>>> (rtpproxy_offer("ie","xx.xx.xx.xx")) {
>>>>>>>>                                                 t_on_reply("1");
>>>>>>>>                                         }
>>>>>>>>                                 }
>>>>>>>>                         }
>>>>>>>>
>>>>>>>>                 }
>>>>>>>>                 else {
>>>>>>>>                         t_on_reply("2");
>>>>>>>>                 }
>>>>>>>>         }
>>>>>>>>
>>>>>>>>
>>>>>>>> Any idea ? I have been stuck on this issue for a few days, this 
>>>>>>>> configuration worked fine with my previous versions of Opensips 
>>>>>>>> and rtpproxy.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> Sebastien
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Users mailing list
>>>>>>>> Users at lists.opensips.org
>>>>>>>> http://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 list
>>>>>> Users at lists.opensips.org
>>>>>> http://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 list
>>>> Users at lists.opensips.org
>>>> http://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 list
>> Users at lists.opensips.org
>> http://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/20111108/11c5dad9/attachment-0001.htm>


More information about the Users mailing list