Outbound calls on VOIP line - can't hear other party

Status
Not open for further replies.

pob

Customer
Joined
Nov 20, 2012
Messages
5
Reaction score
0
We are using Linksys SPA 962 phones with a Broadvoice VOIP line. Lately, when we make outbound calls we cannot hear the party on the other line. They can hear us, we just cannot hear them. Incoming calls work fine. The activity log is below:

12:04:30.753 [MS105000] C:12.2: No RTP packets were received:remoteAddr=206.15.148.180:44464,extAddr=173.190.236.14:9006,localAddr=173.190.236.14:9006
12:04:29.302 [CM503008]: Call(12): Call is terminated
12:04:23.842 [CM503007]: Call(12): Device joined: sip:[email protected]:5060
12:04:23.826 [CM503007]: Call(12): Device joined: sip:[email protected]:5060
12:04:14.357 [CM505003]: Provider:[Broadvoice] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [] PBX contact: [sip:[email protected]:20676]
12:04:14.357 [CM503002]: Call(12): Alerting sip:[email protected]:5060
12:04:11.783 [CM503025]: Call(12): Calling VoIPline:4027701598@(Ln.10000@Broadvoice)@[Dev:sip:[email protected]:5060]
12:04:11.673 [CM503004]: Call(12): Route 2: PSTNline:4027701598@(Ln.10001@Grandstream GXW-4104)@[Dev:sip:[email protected]:5060;transport=udp,Dev:sip:[email protected]:5062;transport=udp,Dev:sip:[email protected]:5064;transport=udp,Dev:sip:[email protected]:5066;transport=udp]
12:04:11.673 [CM503004]: Call(12): Route 1: VoIPline:4027701598@(Ln.10000@Broadvoice)@[Dev:sip:[email protected]:5060]
12:04:11.658 [CM503010]: Making route(s) to "ALL:Cell Phone NE"<sip:[email protected]>
12:04:11.658 [CM505001]: Ext.106: Device info: Device Identified: [Man: Linksys;Mod: SPA Series;Rev: General] Capabilities:[reinvite, no-replaces, able-no-sdp, recvonly] UserAgent: [Linksys/SPA962-6.1.5(a)] PBX contact: [sip:[email protected]:5060]
12:04:11.658 [CM503001]: Call(12): Incoming call from Ext.106 to "ALL:Cell Phone NE"<sip:[email protected]>

This system has been working for several years and just recently started behaving this way. The Broadvoice people said it was because the invite and media were not coming from the same IP address. I'm new to this system so I'm just starting to learn it. Any help would be appreciated.
 
12:04:30.753 [MS105000] C:12.2: No RTP packets were received:remoteAddr=206.15.148.180:44464,extAddr=173.190.236.14:9006,localAddr=173.190.236.14:9006

This is the issue. No RTP is indicative of no voice packets being received. Run the firewall checker to ensure that all is well there. You may also need to see if PBX provides Audio is checked as well along with accepts re-invites. Do the firewall check first.

What version of 3CX are you running?
 
pob said:
The Broadvoice people said it was because the invite and media were not coming from the same IP address
How many external IPs has your router(gateway)?
How many routes to internet has PBX host?
 
Thanks for the replies. We are running version 9.

PBX Delivers Audio was not checked but checking it did not resolve.
Supports re-invite is also checked.

The firewall checker (below) shows a few warnings.

We have one external IP address, the PBX host should have just the one route to internet.

Firewall Checker results -

3CX Firewall Checker, v1.0. Copyright (C) 3CX Ltd. All rights reserved.

<11:37:04>: Phase 1, checking servers connection, please wait...
<11:37:04>: Stun Checker service is reachable. Phase 1 check passed.
<11:37:04>: Phase 2a, Check Port Forwarding to UDP SIP port, please wait...
<11:37:05>: UDP SIP Port is set to 5060. Response received WITH TRANSLATION 18140::5060. Phase 2a check passed with WARNINGS. Some functionality will be LIMITED. For more information, please visit

http://www.3cx.com/blog/docs/firewall-checker/

<11:37:05>: Phase 2b. Check Port Forwarding to TCP SIP port, please wait...
<11:37:05>: TCP SIP Port is set to 5060. Response received WITH TRANSLATION 18140::5060. Phase 2b check passed with WARNINGS. Some functionality will be LIMITED. For more information, please visit

http://www.3cx.com/blog/docs/firewall-checker/

<11:37:05>: Phase 3. Check Port Forwarding to TCP Tunnel port, please wait...
<11:37:05>: TCP TUNNEL Port is set to 5090. Response received correctly with no translation. Phase 3 check passed.

<11:37:05>: Phase 4. Check Port Forwarding to RTP external port range, please wait...
<11:37:06>: UDP RTP Port 9000. Response received correctly with no translation. Phase 4-01 check passed.
<11:37:06>: UDP RTP Port 9001. Response received correctly with no translation. Phase 4-02 check passed.
<11:37:06>: UDP RTP Port 9002. Response received correctly with no translation. Phase 4-03 check passed.
<11:37:06>: UDP RTP Port 9003. Response received correctly with no translation. Phase 4-04 check passed.
<11:37:06>: UDP RTP Port 9004. Response received correctly with no translation. Phase 4-05 check passed.
<11:37:06>: UDP RTP Port 9005. Response received correctly with no translation. Phase 4-06 check passed.
<11:37:06>: UDP RTP Port 9006. Response received correctly with no translation. Phase 4-07 check passed.
<11:37:06>: UDP RTP Port 9007. Response received correctly with no translation. Phase 4-08 check passed.
<11:37:06>: UDP RTP Port 9008. Response received correctly with no translation. Phase 4-09 check passed.
<11:37:06>: UDP RTP Port 9009. Response received correctly with no translation. Phase 4-10 check passed.
<11:37:06>: UDP RTP Port 9010. Response received correctly with no translation. Phase 4-11 check passed.
<11:37:06>: UDP RTP Port 9011. Response received correctly with no translation. Phase 4-12 check passed.
<11:37:06>: UDP RTP Port 9012. Response received correctly with no translation. Phase 4-13 check passed.
<11:37:06>: UDP RTP Port 9013. Response received correctly with no translation. Phase 4-14 check passed.
<11:37:06>: UDP RTP Port 9014. Response received correctly with no translation. Phase 4-15 check passed.
<11:37:06>: UDP RTP Port 9015. Response received correctly with no translation. Phase 4-16 check passed.
<11:37:06>: UDP RTP Port 9016. Response received correctly with no translation. Phase 4-17 check passed.
<11:37:06>: UDP RTP Port 9017. Response received correctly with no translation. Phase 4-18 check passed.
<11:37:06>: UDP RTP Port 9018. Response received correctly with no translation. Phase 4-19 check passed.
<11:37:06>: UDP RTP Port 9019. Response received correctly with no translation. Phase 4-20 check passed.
<11:37:06>: UDP RTP Port 9020. Response received correctly with no translation. Phase 4-21 check passed.
<11:37:06>: UDP RTP Port 9021. Response received correctly with no translation. Phase 4-22 check passed.
<11:37:06>: UDP RTP Port 9022. Response received correctly with no translation. Phase 4-23 check passed.
<11:37:06>: UDP RTP Port 9023. Response received correctly with no translation. Phase 4-24 check passed.
<11:37:06>: UDP RTP Port 9024. Response received correctly with no translation. Phase 4-25 check passed.
<11:37:06>: UDP RTP Port 9025. Response received correctly with no translation. Phase 4-26 check passed.
<11:37:06>: UDP RTP Port 9026. Response received correctly with no translation. Phase 4-27 check passed.
<11:37:06>: UDP RTP Port 9027. Response received correctly with no translation. Phase 4-28 check passed.
<11:37:06>: UDP RTP Port 9028. Response received correctly with no translation. Phase 4-29 check passed.
<11:37:06>: UDP RTP Port 9029. Response received correctly with no translation. Phase 4-30 check passed.
<11:37:06>: UDP RTP Port 9030. Response received correctly with no translation. Phase 4-31 check passed.
<11:37:06>: UDP RTP Port 9031. Response received correctly with no translation. Phase 4-32 check passed.
<11:37:06>: UDP RTP Port 9032. Response received correctly with no translation. Phase 4-33 check passed.
<11:37:06>: UDP RTP Port 9033. Response received correctly with no translation. Phase 4-34 check passed.
<11:37:06>: UDP RTP Port 9034. Response received correctly with no translation. Phase 4-35 check passed.
<11:37:06>: UDP RTP Port 9035. Response received correctly with no translation. Phase 4-36 check passed.
<11:37:06>: UDP RTP Port 9036. Response received correctly with no translation. Phase 4-37 check passed.
<11:37:06>: UDP RTP Port 9037. Response received correctly with no translation. Phase 4-38 check passed.
<11:37:06>: UDP RTP Port 9038. Response received correctly with no translation. Phase 4-39 check passed.
<11:37:06>: UDP RTP Port 9039. Response received correctly with no translation. Phase 4-40 check passed.
<11:37:06>: UDP RTP Port 9040. Response received correctly with no translation. Phase 4-41 check passed.
<11:37:06>: UDP RTP Port 9041. Response received correctly with no translation. Phase 4-42 check passed.
<11:37:06>: UDP RTP Port 9042. Response received correctly with no translation. Phase 4-43 check passed.
<11:37:06>: UDP RTP Port 9043. Response received correctly with no translation. Phase 4-44 check passed.
<11:37:06>: UDP RTP Port 9044. Response received correctly with no translation. Phase 4-45 check passed.
<11:37:06>: UDP RTP Port 9045. Response received correctly with no translation. Phase 4-46 check passed.
<11:37:06>: UDP RTP Port 9046. Response received correctly with no translation. Phase 4-47 check passed.
<11:37:06>: UDP RTP Port 9047. Response received correctly with no translation. Phase 4-48 check passed.
<11:37:06>: UDP RTP Port 9048. Response received correctly with no translation. Phase 4-49 check passed.
<11:37:06>: UDP RTP Port 9049. Response received correctly with no translation. Phase 4-50 check passed.


Application exit code is 2
 
If
pob said:
We have one external IP address, the PBX host should have just the one route to internet.
then, how it is possible that
pob said:
The Broadvoice people said it was because the invite and media were not coming from the same IP address
?
 
The remoteAddr it shows is sip.broadvoice.com, the extAddr it shows is our static IP. They said the invite came from the remoteAddr and the media from extAddr. Is there a way to change it so that the invite shows up from our static IP as opposed to the sip.broadvoice.com. Would I even want to?
 
Everything ok with STUN? is seems like you pbx dont˙know public ip? try outbound call with wireshark and in invite message check the situation with ip address
 
Thanks mixig, I think it has to do with STUN too. I changed the "Which IP to use in contact field for registration" to our static IP instead of External (STUN resolved). So far it appears to be working but we've had periods like this before where everything worked fine without having made any changes.

If it starts acting up again I'll look into wireshark and maybe see about turning off the STUN server altogether as a test.
 
Status
Not open for further replies.

Members Online Now

Forum statistics

Threads
111,843
Messages
589,327
Members
164,679
Latest member
SamadMYK