[Home]

Summary:ASTERISK-28389: PJ ICE Rx error status code: 370400 'Bad Request'.
Reporter:Brian J. Murrell (brian_j_murrell)Labels:pjsip
Date Opened:2019-04-18 11:25:20Date Closed:2019-05-03 12:00:02
Priority:MinorRegression?
Status:Closed/CompleteComponents:Resources/res_rtp_asterisk
Versions:13.26.0 Frequency of
Occurrence
Related
Issues:
is the original version of this clone:ASTERISK-23629 PJ ICE Rx error status code: 370400 'Bad Request'.
Environment:CentOS 7.6Attachments:
Description:...
Comments:By: Asterisk Team (asteriskteam) 2019-04-18 11:25:21.543-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.
By: Asterisk Team (asteriskteam) 2019-04-18 11:25:23.065-0500

Per the Asterisk versions page [1], the maintenance (bug fix) support for the Asterisk branch you are using has ended. For continued maintenance support please move to a supported branch of Asterisk. After testing with a supported branch, if you find this problem has not been resolved, please open a new issue against the latest version of that Asterisk branch.

Thanks!

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions
By: Asterisk Team (asteriskteam) 2019-04-18 11:25:35.790-0500

This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.
By: Brian J. Murrell (brian_j_murrell) 2019-04-18 11:27:30.352-0500

Per the comments in the cloned-from issue:

Here's what wireshark has to say about the response from stun.linphone.org which is causing these messages.

{noformat}
Simple Traversal of UDP Through NAT
   [Request In: 1]
   [Time: 0.111060000 seconds]
   Message Type: Binding Response (0x0101)
   Message Length: 0x0040
   Message Transaction ID: 6999906837272c48e1da866617eded14
   Attributes
       Attribute: MAPPED-ADDRESS
           Attribute Type: MAPPED-ADDRESS (0x0001)
           Attribute Length: 8
           Protocol Family: IPv4 (0x0001)
           Port: 13210
           IP: d7-19-27-1.example.com (7.19.27.1)
       Attribute: SOURCE-ADDRESS
           Attribute Type: SOURCE-ADDRESS (0x0004)
           Attribute Length: 8
           Protocol Family: IPv4 (0x0001)
           Port: 3478
           IP: sip3.linphone.org (37.59.51.72)
       Attribute: CHANGED-ADDRESS
           Attribute Type: CHANGED-ADDRESS (0x0005)
           Attribute Length: 8
           Protocol Family: IPv4 (0x0001)
           Port: 0
           IP: 0.0.0.0 (0.0.0.0)
       Attribute: Unknown (0x0020)
           Attribute Type: Unknown (0x0020)
           Attribute Length: 8
       Attribute: SERVER
           Attribute Type: SERVER (0x8022)
           Attribute Length: 12
           Server version: oRTP   0.99
{noformat}
By: Joshua C. Colp (jcolp) 2019-04-18 11:30:03.088-0500

Please don't clone issues in the future. Create new ones, as it can clutter things up.

Please also attach a packet capture and information about how the STUN server is being used. Are you configuring it in rtp.conf? If you use any other STUN server does the problem occur?
By: Brian J. Murrell (brian_j_murrell) 2019-04-18 11:41:05.570-0500

I guess there is no point in attaching a packet capture until I am on a release that would get a bugfix applied for this if/when a bug is found.

I am configuring in rtp.conf:

{noformat}
stunaddr=stun.linphone.org
;stunaddr=stun.zoiper.com
{noformat}

I have tried with both of those STUN servers above and both produce the same result.  I am happy to try others if you wish.
By: Joshua C. Colp (jcolp) 2019-04-18 11:55:47.112-0500

What version are you actually on? And how is PJSIP built? Bundled or external?
By: Brian J. Murrell (brian_j_murrell) 2019-04-18 12:00:16.024-0500

13.26.0 and bundled I am pretty sure.
By: Joshua C. Colp (jcolp) 2019-04-18 13:01:33.778-0500

Are you receiving the precise "Bad Request" message in the title? A stunaddr in rtp.conf I believe would not actually hit the PJNATH stack. That uses the old STUN code in Asterisk itself. What precisely is happening?
By: Brian J. Murrell (brian_j_murrell) 2019-04-18 13:06:48.276-0500

{noformat}
   -- Executing [600@internal-sip:1] Playback("PJSIP/brian_h8-00000057", "demo-echotest") in new stack
[Apr 18 14:02:07] WARNING[18951][C-00000031]: res_rtp_asterisk.c:2621 __rtp_recvfrom: PJ ICE Rx error status code: 370400 'Bad Request'.
[Apr 18 14:02:07] WARNING[18951][C-00000031]: res_rtp_asterisk.c:2621 __rtp_recvfrom: PJ ICE Rx error status code: 370400 'Bad Request'.
[Apr 18 14:02:07] WARNING[18951][C-00000031]: res_rtp_asterisk.c:2621 __rtp_recvfrom: PJ ICE Rx error status code: 370400 'Bad Request'.
[Apr 18 14:02:07] WARNING[18951][C-00000031]: res_rtp_asterisk.c:2621 __rtp_recvfrom: PJ ICE Rx error status code: 370400 'Bad Request'.
   -- <PJSIP/brian_h8-00000057> Playing 'demo-echotest.gsm' (language 'en')
{noformat}

Are STUN servers configured somewhere other than {{rtp.conf}} for PJSIP then?
By: Joshua C. Colp (jcolp) 2019-04-18 15:01:27.866-0500

PJSIP doesn't use STUN servers for that and there aren't any that are configurable. The STUN servers in rtp.conf are for figuring out the server reflexive candidates to place as ICE candidates. Once that is done the PJNATH stack (and its STUN implementation) is used for the traffic between Asterisk and the remote endpoint. I think you need to describe the specific scenario including what endpoint is used and provide the packet capture. I believe that is where the message is coming from, not from the STUN servers mentioned in rtp.conf
By: Asterisk Team (asteriskteam) 2019-05-03 12:00:01.295-0500

Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines