[OpenSIPS-Users] ERROR:rtpproxy:force_rtp_proxy: Unable to parse body
Bogdan-Andrei Iancu
bogdan at opensips.org
Wed Aug 19 17:17:45 CEST 2015
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/767f37a6/attachment-0001.htm>
More information about the Users
mailing list