SIP Calls not passing audio under one specific condition.
-
Internal NEC SV9100 PBX with SIP Trunk.
When a user dials their own POTS number, the call connects but there is no audio either way.What works:
All outbound calls to other numbers.
All inbound calls from other numbers.
All ext-ext calls.What does not work:
A user calls their own company main line. Dials, connects, no audio, drops.
Example: internal user calls 212-123-4567 and expects the person at the front desk to answer an incoming call.
What happens: No audio, call drops.PBX provider says not the PBX but have seen it before and the SIP Carrier fixed it.
SIP Carrier say they are not in the audio path so it's not their issue.
My first thought was firewall, since SIP is originating and terminating behind firewall. Also, I recall @scottalanmiller and @JaredBusch saying in past discussions, that if the call is complete and there is no audio, it is almost always "XXX" in the firewall. But I don't recall what "XXX" was...
Any thoughts?
-
Where does the POTS line connect to? Is it another PBX?
-
@JasGot said in SIP Calls not passing audio under one specific condition.:
SIP Carrier say they are not in the audio path so it's not their issue.
They have to be. If you call out on SIP to the PSTN to come back in on a POTS line, if the SIP carrier isn't in the path, then there's no audio to be had because they are the only way that audio can get from point A to point B in this scenario.
-
@JasGot said in SIP Calls not passing audio under one specific condition.:
A user calls their own company main line. Dials, connects, no audio, drops.
What number are they calling FROM?
-
@scottalanmiller said in SIP Calls not passing audio under one specific condition.:
@JasGot said in SIP Calls not passing audio under one specific condition.:
A user calls their own company main line. Dials, connects, no audio, drops.
What number are they calling FROM?
The same number. When I said POTS, I meant to indicate they were calling their published main phone number.
-
@scottalanmiller said in SIP Calls not passing audio under one specific condition.:
Where does the POTS line connect to? Is it another PBX?
Same pbx. My error. There are no post lines. All are sip.
-
POTS = Plain old telephone service - think copper wires to your home in the 80's.
You most likely mean a DID - direct inward dial, a phone number that is assigned to your office carrier that is delivered to your PBX over the trunk between your carrier and your PBX.
-
When I moved to SIP several years ago, We learned we couldn't call our own phone number either. I think we got a fast busy.
This is sometimes called tromboning, or boomeranging, calling out only to have the call come right back over the same trunk to your own PBX.
Cox didn't support this, I'd ask your carrier if they support an outgoing call coming right back over the same trunk?
-
@Dashrender said in SIP Calls not passing audio under one specific condition.:
POTS = Plain old telephone service - think copper wires to your home in the 80's.
You most likely mean a DID - direct inward dial, a phone number that is assigned to your office carrier that is delivered to your PBX over the trunk between your carrier and your PBX.
No. I meant to indicate they were calling their published main phone number. I meant to use the word POTS. I know it is not the right word. It was my error.
-
@Dashrender said in SIP Calls not passing audio under one specific condition.:
When I moved to SIP several years ago, We learned we couldn't call our own phone number either. I think we got a fast busy.
This is sometimes called tromboning, or boomeranging, calling out only to have the call come right back over the same trunk to your own PBX.
Cox didn't support this, I'd ask your carrier if they support an outgoing call coming right back over the same trunk?
This seems to be exactly what we are experiencing.
This is the carrier's response.
I'm afraid we are not able to help diagnose audio issues as our network does not exist in the audio pathway of the calls. We explain that in detail here: https://support.skyetel.com/hc/en-us/articles/360041178293-Our-Network-Topology The PBX and local firewall would need to allow the audio to come from its own IP. Here is what the SIP looks like: Server: NEC SV9100-NA 10.60.53/2.1 Via: SIP/2.0/UDP [ipaddress]:5060;TH=div;branch=[removed] Content-Length: 185 TH: uch v=0 o=- 0 0 IN IP4 [ipaddress] s=T029 c=IN IP4 [ipaddress] t=0 0 m=audio 10034 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=ptime:20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 Since this call is internal, it is not being sent through the PSTN, perhaps your PBX is interacting with or expecting its LAN IP? Please let us know if you need anything else. -
OK so you're using Skyetel - me too.
I just picked up my Fanvil phone that's registered to my VitalPBX which is offsite (not that this should make any difference) which has a Skyetel registered SIP trunk.
I called my main DID (the one my customers call) and it worked just fine (which frankly surprised me).
-
My context when calling an extension is sub-local-dialing instead of trk-1-dial, I wonder what your logs show? is your PBX smart enough to know when you dial your own DIDs the call stays completely inside your own PBX, bypassing your carrier trunks?
-
@scottalanmiller said in SIP Calls not passing audio under one specific condition.:
They have to be.
No they do not. As linked in the post above:
https://support.skyetel.com/hc/en-us/articles/360041178293-Our-Network-Topology -
@JasGot said in SIP Calls not passing audio under one specific condition.:
My first thought was firewall, since SIP is originating and terminating behind firewall. Also, I recall @scottalanmiller and @JaredBusch saying in past discussions, that if the call is complete and there is no audio, it is almost always "XXX" in the firewall. But I don't recall what "XXX" was...
NAT, it is always 100% a NAT issue.
-
You would need to get a packet capture from all the devices.
Either
- your router does not know what to do with an inbound connection from itself.
- your pbx does not know what to do with a packet form itself looped from the outside.
-
You can "fix" it the brute force way by creating an outbound route in your NEC that catches the DID range of your stuff and sends the call someplace other than the Skyetel trunk. such as the operator or something.
-
@JaredBusch said in SIP Calls not passing audio under one specific condition.:
You would need to get a packet capture from all the devices.
Eitheryour router does not know what to do with an inbound connection from itself.
I regularly create Loopback NATs in our firewalls. would this be a scenario where I would need it?
-
Skyetel tech sent this in response to "Internal as perceived by Skyetel?".
How is the Skyetel network not part of the audio in this call?
Digital Deskphone->PBX with SIP Card->Firewal->Comcast Cable Modem->Skyetel->Comcast Cable Modem->Firewall->PBX with SIP Card->Any Deskphone that chooses to answer the incoming call.
Yes, as both the source number and destination number are on Skyetel's network, and the source IP and destination IP are exactly the same, these calls are not routed to any external carriers and only to our own SIP gateways. So the call media, RTP, may be going through a NAT loop or being filtered out somewhere by the local firewall or PBX. -
@JasGot said in SIP Calls not passing audio under one specific condition.:
@JaredBusch said in SIP Calls not passing audio under one specific condition.:
You would need to get a packet capture from all the devices.
Eitheryour router does not know what to do with an inbound connection from itself.
I regularly create Loopback NATs in our firewalls. would this be a scenario where I would need it?
Most likely, yes.
-
@JasGot said in SIP Calls not passing audio under one specific condition.:
How is the Skyetel network not part of the audio in this call?
Skyetel is not part of the audio of any call unless they answer it.
SIP != Audio
SIP is only the setup of a call.
The audio is RTP on ports 10000-20000 by default in Asterisk. Don't know about your NEC.
When a call is setup, on your Skyetel trunk, they simply pass the RTP channel info as presented to them along. They do not accept and forward it.
