[Home]

Summary:ASTERISK-26860: Upon RTCP reception, netsock2.c:210 ast_sockaddr_split_hostport: Port missing in (null)
Reporter:Evers Lab (evers)Labels:
Date Opened:2017-03-13 09:50:58Date Closed:2017-12-20 06:10:57.000-0600
Priority:MinorRegression?
Status:Closed/CompleteComponents:
Versions:13.14.0 Frequency of
Occurrence		Frequent
Related
Issues:
is duplicated byASTERISK-27313 Warning message netsock2.c:210 ast_sockaddr_split_hostport: Port missing in (null)
Environment:CentOS7Attachments:( 0) conf_and_verbose.txt
Description:When the call arrives to the Queue and listens to music on hold, the console continually gives an error. When the agent answers the call, the error stops

[Edit by Rusty - adding Sean Bright's reproduction guide below]

This is fairly easy to duplicate with Asterisk 13 from git:

{{extensions.conf:}}
{noformat}
[just-moh]
exten => 1234,1,Answer()
exten => 1234,n,MusicOnHold()
{noformat}

{{Asterisk CLI:}}
{noformat}
*CLI> channel originate PJSIP/some-endpoint extension 1234@just-moh
{noformat}

Answer {{some-endpoint}} and place the call on hold. Every time Asterisk receives an RTCP packet, you'll see this error.
Comments:By: Asterisk Team (asteriskteam) 2017-03-13 09:50:59.781-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].
By: Joshua C. Colp (jcolp) 2017-03-14 05:46:01.311-0500

A few people have mentioned this but it does not seem to occur for everyone. Can you please provide the console output with debug on (debug going to console in logger.conf as well as core set debug 9 in CLI), SIP logging (sip set debug on or pjsip set logger on), and configuration.
By: Carl Fortin (phonefxg) 2017-03-14 13:46:35.097-0500

In my case, I see this error when a fax is receiving or transmitting. The warning started around version 14.2.1. That's all I have for now. Maybe Evers Lab can confirm it.

By: Sean Bright (seanbright) 2017-03-19 16:28:52.510-0500

This is fairly easy to duplicate with Asterisk 13 from git:

{{extensions.conf:}}
{noformat}
[just-moh]
exten => 1234,1,Answer()
exten => 1234,n,MusicOnHold()
{noformat}

{{Asterisk CLI:}}
{noformat}
*CLI> channel originate PJSIP/some-endpoint extension 1234@just-moh
{noformat}

Answer {{some-endpoint}} and place the call on hold. Every time Asterisk receives an RTCP packet, you'll see this error.
By: Evers Lab (evers) 2017-03-24 11:32:13.432-0500

[Edit by Rusty - Removed configs and debug from the comment. Please read through the issue tracker guidelines before posting.]

https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines
By: Rusty Newton (rnewton) 2017-03-30 14:14:10.384-0500

Attaching [~evers] conf and verbose output to the issue as .txt file.
By: Friendly Automation (friendly-automation) 2017-05-04 17:57:20.012-0500

Change 5566 merged by Jenkins2:
res_rtp_asterisk: Clearing the remote RTCP address causes RTCP failures

[https://gerrit.asterisk.org/5566|https://gerrit.asterisk.org/5566]
By: Friendly Automation (friendly-automation) 2017-05-04 18:29:22.621-0500

Change 5565 merged by Joshua Colp:
res_rtp_asterisk: Clearing the remote RTCP address causes RTCP failures

[https://gerrit.asterisk.org/5565|https://gerrit.asterisk.org/5565]
By: Friendly Automation (friendly-automation) 2017-05-04 18:29:31.297-0500

Change 5564 merged by Joshua Colp:
res_rtp_asterisk: Clearing the remote RTCP address causes RTCP failures

[https://gerrit.asterisk.org/5564|https://gerrit.asterisk.org/5564]
By: Evers Lab (evers) 2017-06-02 01:31:15.557-0500

Hello!
Your patch helps when the customer is on hold or the client hears MOH. And the corresponding lines of code are already included in the new version of the asterisk 13. But the problem is actual when the handset is first picked up.

By: Asterisk Team (asteriskteam) 2017-06-02 01:31:15.907-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: Evers Lab (evers) 2017-06-02 01:41:47.399-0500

{{Asterisk CLI:}}
{noformat}
*CLI>
*CLI>
*CLI>
 == Using SIP RTP CoS mark 5
   -- Executing [999300@TRUNK-IN:1] Dial("SIP/TRUNK-00000012", "SIP/999300") in new stack
 == Using SIP RTP CoS mark 5
   -- Called SIP/999300
   -- SIP/999300-00000013 is ringing
   -- SIP/999300-00000013 is ringing
[Jun  2 12:31:20] WARNING[5008]: netsock2.c:210 ast_sockaddr_split_hostport: Port missing in (null)
      > 0x7f9a0c005d00 -- Probation passed - setting RTP source address to 10.10.10.22:39728
   -- SIP/999300-00000013 answered SIP/TRUNK-00000012
   -- Channel SIP/999300-00000013 joined 'simple_bridge' basic-bridge <cb282b15-5979-42db-8286-374446dbffcb>
   -- Channel SIP/TRUNK-00000012 joined 'simple_bridge' basic-bridge <cb282b15-5979-42db-8286-374446dbffcb>
      > Bridge cb282b15-5979-42db-8286-374446dbffcb: switching from simple_bridge technology to native_rtp
      > Locally RTP bridged 'SIP/TRUNK-00000012' and 'SIP/999300-00000013' in stack
      > Locally RTP bridged 'SIP/TRUNK-00000012' and 'SIP/999300-00000013' in stack
      > 0x7f9a0c005d00 -- Probation passed - setting RTP source address to 10.10.10.22:39728
      > 0x7f995c00f6d0 -- Probation passed - setting RTP source address to 10.10.10.6:27036
   -- Channel SIP/TRUNK-00000012 left 'native_rtp' basic-bridge <cb282b15-5979-42db-8286-374446dbffcb>
   -- Channel SIP/999300-00000013 left 'native_rtp' basic-bridge <cb282b15-5979-42db-8286-374446dbffcb>
 == Spawn extension (TRUNK-IN, 999300, 1) exited non-zero on 'SIP/TRUNK-00000012'
*CLI>

{noformat}

By: Kevin Harwell (kharwell) 2017-06-15 12:53:29.637-0500

With regards to the CLI output posted by [~evers] in the previous comment:

This is a slightly different effect (from the original issue reported), but due to the same underlying problem. In this case the remote RTCP address has not been set yet by Asterisk as it is still in a "learning mode", but RTCP is being received from the remote client.
By: Benjamin Keith Ford (bford) 2017-07-24 09:22:46.052-0500

[~evers], can you provide more information on what you are doing to reproduce the issue? Some things that would be helpful:
# Your configurations used when the warning message is triggered (relevant dialplan)
# What scenario is causing the warning (is phone A calling phone B on same Asterisk instance, or is phone A calling phone B on a different Asterisk instance, or is ... etc.)
# Has your Asterisk version changed from 13.14 between the two instances of the warning message?
By: Benjamin Keith Ford (bford) 2017-07-28 15:37:32.642-0500

[~evers], are you still experiencing this issue? We need more information to move forward with a solution. Any additional information you can provide would be helpful, including configurations, the scenario that causes this message to appear, and Asterisk version (if it has changed from 13.14).
By: Joshua C. Colp (jcolp) 2017-12-20 06:10:37.891-0600

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested. 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