[OpenSIPS-Users] ERROR:rtpproxy:force_rtp_proxy: Unable to parse body

Bogdan-Andrei Iancu bogdan at opensips.org
Wed Aug 19 20:15:40 CEST 2015


That breaks the SIP syntax according to RFC3261.

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 19.08.2015 20:32, Nabeel wrote:
>
> The port just seems to have '-1' attached to it for some reason; maybe 
> it has some meaning to it in some context:
>
> "46032:-1"
>
> I'll report it on the SIP client mailing list,  but I still think 
> OpenSIPS should be able to ignore such unconventional port formats.   
> As long as the calls work, that's what matters at the end of the day.
>
> On 19 Aug 2015 18:23, "Bogdan-Andrei Iancu" <bogdan at opensips.org 
> <mailto:bogdan at opensips.org>> wrote:
>
>     Nabeel,
>
>     What is broken is broken and cannot be unbroken :)
>
>     Regards,
>
>     Bogdan-Andrei Iancu
>     OpenSIPS Founder and Developer
>     http://www.opensips-solutions.com
>
>     On 19.08.2015 18:48, Nabeel wrote:
>>
>>     Well, at least the call connects when the other SIP server
>>     accepts the port.  But OpenSIPS fails to connect.    Is there a 
>>     way to relax the port criteria in OpenSIPS to accept such ports? 
>>     Even if the port is in a 'bogus' format?
>>
>>     On 19 Aug 2015 16:17, "Bogdan-Andrei Iancu" <bogdan at opensips.org
>>     <mailto:bogdan at opensips.org>> wrote:
>>
>>         Make a network capture - if the incoming CANCEL has that
>>         broken VIA port, simply report it to the vendor. The fact the
>>         bogus port is accepted by other SIP server implementations is
>>         not really relevant.
>>
>>         Regards,
>>
>>         Bogdan-Andrei Iancu
>>         OpenSIPS Founder and Developer
>>         http://www.opensips-solutions.com
>>
>>         On 19.08.2015 17:49, Nabeel wrote:
>>>
>>>         I used that same client 'Lumicall' (lumicall.org
>>>         <http://lumicall.org>) with Repro SIP server and the calls
>>>         worked, so I'm not sure how to fix it.
>>>
>>>         On 19 Aug 2015 15:24, "Bogdan-Andrei Iancu"
>>>         <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>>>
>>>             Fix the SIP client sending you the bogus SIP messages
>>>             :). You cannot fix anything on OpenSIPS side.
>>>
>>>             Regards,
>>>
>>>             Bogdan-Andrei Iancu
>>>             OpenSIPS Founder and Developer
>>>             http://www.opensips-solutions.com
>>>
>>>             On 19.08.2015 17:16, Nabeel wrote:
>>>>
>>>>             Okay, so what caused the bogus port nunber and how can
>>>>             I fix it?
>>>>
>>>>             On 19 Aug 2015 14:54, "Bogdan-Andrei Iancu"
>>>>             <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>>>>
>>>>                 Hi Nabeel,
>>>>
>>>>                 This error has nothing to do with the rtpproxy . It
>>>>                 is a parsing error of an incoming SIP request. The
>>>>                 VIA header in the received CANCEL has a bogus port
>>>>                 number:
>>>>                     Via: <SIP/2.0/TCP 10.61.208.143
>>>>                 <http://10.61.208.143>:*46032:-1*;rport;branch=z9hG4bK78006
>>>>
>>>>                 Regards,
>>>>
>>>>                 Bogdan-Andrei Iancu
>>>>                 OpenSIPS Founder and Developer
>>>>                 http://www.opensips-solutions.com
>>>>
>>>>                 On 19.08.2015 09:02, Nabeel wrote:
>>>>>
>>>>>                 I'm using port 12221 for rtpproxy (from default
>>>>>                 script) and port 12223 for OpenSIPS.  Are those
>>>>>                 'bad ports' like the error says?
>>>>>
>>>>>                 On 19 Aug 2015 06:48, "Nabeel"
>>>>>                 <nabeelshikder at gmail.com
>>>>>                 <mailto:nabeelshikder at gmail.com>> wrote:
>>>>>
>>>>>                     Hi,
>>>>>
>>>>>                     The rtpproxy error is resolved with your
>>>>>                     suggestion, but I still get the 'bad port'
>>>>>                     errors in the log followed by CANCEL of the call:
>>>>>
>>>>>                         ERROR:core:parse_via: bad port
>>>>>                         ERROR:core:parse_via:  <SIP/2.0/TCP
>>>>>                         10.61.208.143:46032:-1;rport;branch=z9hG4bK78006#015#012Max-Forwards:
>>>>>                         70#015#012To:
>>>>>                         <sip:+447984977774 at sipdomain.com
>>>>>                         <mailto:sip%3A%2B447984977774 at sipdomain.com>;transport=tcp>#015#012From:
>>>>>                         <sip:+447479189410 at sipdomain.com
>>>>>                         <mailto:sip%3A%2B447479189410 at sipdomain.com>>;tag=z9hG4bK93013084#015#012Call-ID:
>>>>>                         358919227046 at 10.61.208.143#015#012CSeq
>>>>>                         <http://358919227046@10.61.208.143#015%23012CSeq>:
>>>>>                         1 CANCEL#015#012Contact:
>>>>>                         <sip:+447479189410
>>>>>                         <tel:%2B447479189410>@10.61.208.143:46032;transport=tcp>#015#012Expires:
>>>>>                         3600#015#012User-Agent:
>>>>>                         Agent/1.3.4/MP-S168#015#012Content-Length:
>>>>>                         0#015#012#015#012>
>>>>>                         ERROR:core:parse_via: parsed so
>>>>>                         far:<SIP/2.0/TCP 10.61.208.143:46032
>>>>>                         <http://10.61.208.143:46032>>
>>>>>                         ERROR:core:get_hdr_field: bad via
>>>>>                         DBG:core:set_err_info: ec: 1, el: 3, ei:
>>>>>                         'error parsing Via'
>>>>>                         DBG:core:get_hdr_field: error exit
>>>>>                         INFO:core:parse_headers: bad header field
>>>>>                         ERROR:core:parse_msg: message=<CANCEL
>>>>>                         sip:+447984977774 at sipdomain.com
>>>>>                         <mailto:sip%3A%2B447984977774 at sipdomain.com>;transport=tcp
>>>>>                         SIP/2.0#015#012Via: SIP/2.0/TCP
>>>>>                         10.61.208.143:46032:-1;rport;branch=z9hG4bK78006#015#012Max-Forwards:
>>>>>                         70#015#012To:
>>>>>                         <sip:+447984977774 at sipdomain.com
>>>>>                         <mailto:sip%3A%2B447984977774 at sipdomain.com>;transport=tcp>#015#012From:
>>>>>                         <sip:+447479189410 at sipdomain.com
>>>>>                         <mailto:sip%3A%2B447479189410 at sipdomain.com>>;tag=z9hG4bK93013084#015#012Call-ID:
>>>>>                         358919227046 at 10.61.208.143#015#012CSeq
>>>>>                         <http://358919227046@10.61.208.143#015%23012CSeq>:
>>>>>                         1 CANCEL#015#012Contact:
>>>>>                         <sip:+447479189410
>>>>>                         <tel:%2B447479189410>@10.61.208.143:46032;transport=tcp>#015#012Expires:
>>>>>                         3600#015#012User-Agent:
>>>>>                         Agent/1.3.4/MP-S168#015#012Content-Length:
>>>>>                         0#015#012#015#012>
>>>>>                         ERROR:core:receive_msg: Unable to parse
>>>>>                         msg received from [188.29.165.141:46315
>>>>>                         <http://188.29.165.141:46315>]
>>>>>                         ERROR:core:tcp_handle_req: receive_msg failed
>>>>>
>>>>>
>>>>>
>>>>>                     The SIP trace of the call is here:
>>>>>
>>>>>                     http://pastebin.com/dNpau6GT
>>>>>
>>>>>                     I am using the default config scripts. Please
>>>>>                     advise how to fix this.
>>>>>
>>>>>
>>>>>
>>>>>                     On 14 August 2015 at 18:36, Bogdan-Andrei
>>>>>                     Iancu <bogdan at opensips.org
>>>>>                     <mailto:bogdan at opensips.org>> wrote:
>>>>>
>>>>>                         yes, you should.
>>>>>
>>>>>                         Regards,
>>>>>
>>>>>                         Bogdan-Andrei Iancu
>>>>>                         OpenSIPS Founder and Developer
>>>>>                         http://www.opensips-solutions.com
>>>>>
>>>>>                         On 14.08.2015 18:06, Nabeel wrote:
>>>>>>
>>>>>>                         Should I make the same change to
>>>>>>                         rtpproxy_offer?
>>>>>>
>>>>>>                         if (is_method("INVITE")) {
>>>>>>                         if (isflagset(NAT)) {
>>>>>>                         rtpproxy_offer("ro");
>>>>>>                         }
>>>>>>
>>>>>>                         On 14 Aug 2015 13:09, "Bogdan-Andrei
>>>>>>                         Iancu" <bogdan at opensips.org
>>>>>>                         <mailto:bogdan at opensips.org>> wrote:
>>>>>>
>>>>>>                             I see....you have a
>>>>>>                             onreply_route[handle_nat] in your
>>>>>>                             script, doing:
>>>>>>
>>>>>>                             if ( isflagset(NAT) )
>>>>>>                             rtpproxy_answer("ro");
>>>>>>
>>>>>>                             Change that to :
>>>>>>
>>>>>>                             if ( isflagset(NAT) &&
>>>>>>                             has_body("application/sdp") )
>>>>>>                             rtpproxy_answer("ro");
>>>>>>
>>>>>>                             Regards,
>>>>>>
>>>>>>                             Bogdan-Andrei Iancu
>>>>>>                             OpenSIPS Founder and Developer
>>>>>>                             http://www.opensips-solutions.com
>>>>>>
>>>>>>                             On 14.08.2015 15:04, Nabeel wrote:
>>>>>>>
>>>>>>>                             The 'ringing' stage of a call is
>>>>>>>                             when the error occurs.  Why should
>>>>>>>                             180 Ringing lead to an error?
>>>>>>>
>>>>>>>                             On 14 Aug 2015 12:47, "Bogdan-Andrei
>>>>>>>                             Iancu" <bogdan at opensips.org
>>>>>>>                             <mailto:bogdan at opensips.org>> wrote:
>>>>>>>
>>>>>>>                                 Hi,
>>>>>>>
>>>>>>>                                 ACK request or 180 ringing reply
>>>>>>>                                 are part of a call and they do
>>>>>>>                                 not have a body.
>>>>>>>
>>>>>>>                                 It depends on your scripting to
>>>>>>>                                 see when the rtpproxy are called
>>>>>>>                                 (for what sip message).
>>>>>>>
>>>>>>>                                 You may use the script_trace()
>>>>>>>                                 function :
>>>>>>>                                 http://www.opensips.org/Documentation/Script-CoreFunctions-1-11#toc42
>>>>>>>                                 to see which sip messages to
>>>>>>>                                 generate the err log.
>>>>>>>
>>>>>>>                                 Regards,
>>>>>>>
>>>>>>>                                 Bogdan-Andrei Iancu
>>>>>>>                                 OpenSIPS Founder and Developer
>>>>>>>                                 http://www.opensips-solutions.com
>>>>>>>
>>>>>>>                                 On 14.08.2015 14:15, Nabeel wrote:
>>>>>>>>
>>>>>>>>                                 Hi Bogdan,
>>>>>>>>
>>>>>>>>                                 Thanks, but I had no intentions
>>>>>>>>                                 of using a SIP message without
>>>>>>>>                                 a body; all I'm trying to do is
>>>>>>>>                                 make a normal call with OpenSIPS.
>>>>>>>>
>>>>>>>>                                 Please explain why I'm getting
>>>>>>>>                                 a SIP message without a body
>>>>>>>>                                 and how do I fix it?
>>>>>>>>
>>>>>>>>                                 On 14 Aug 2015 11:12,
>>>>>>>>                                 "Bogdan-Andrei Iancu"
>>>>>>>>                                 <bogdan at opensips.org
>>>>>>>>                                 <mailto:bogdan at opensips.org>>
>>>>>>>>                                 wrote:
>>>>>>>>
>>>>>>>>                                     Hi Nabeel,
>>>>>>>>
>>>>>>>>                                     You may get this error when
>>>>>>>>                                     calling the rtpproxy
>>>>>>>>                                     functions for a SIP message
>>>>>>>>                                     without a body.
>>>>>>>>
>>>>>>>>                                     Regards,
>>>>>>>>
>>>>>>>>                                     Bogdan-Andrei Iancu
>>>>>>>>                                     OpenSIPS Founder and Developer
>>>>>>>>                                     http://www.opensips-solutions.com
>>>>>>>>
>>>>>>>>                                     On 14.08.2015 09:58, Nabeel
>>>>>>>>                                     wrote:
>>>>>>>>>                                     Hi,
>>>>>>>>>
>>>>>>>>>                                     I am getting this error
>>>>>>>>>                                     when making some calls:
>>>>>>>>>
>>>>>>>>>                                     ERROR:rtpproxy:force_rtp_proxy:
>>>>>>>>>                                     Unable to parse body
>>>>>>>>>
>>>>>>>>>                                     I think this may be
>>>>>>>>>                                     related to
>>>>>>>>>                                     'rtpproxy_offer' and
>>>>>>>>>                                     'rtpproxy_answer' in the
>>>>>>>>>                                     config file but I don't
>>>>>>>>>                                     know how to fix it.  I am
>>>>>>>>>                                     using the default OpenSIPS
>>>>>>>>>                                     config.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                                     _______________________________________________
>>>>>>>>>                                     Users mailing list
>>>>>>>>>                                     Users at lists.opensips.org  <mailto: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/20150819/cf96a87f/attachment-0001.htm>


More information about the Users mailing list