SIP Calls not passing audio under one specific condition.
-
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.
-
@JaredBusch said in SIP Calls not passing audio under one specific condition.:
@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.
Just checked. I had created them originally. So they are there.
-
@JaredBusch said in SIP Calls not passing audio under one specific condition.:
@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.
So once the Setup is complete, are the calling party and receiving party directly connected to each other?
-
@JasGot said in SIP Calls not passing audio under one specific condition.:
@JaredBusch said in SIP Calls not passing audio under one specific condition.:
@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.
So once the Setup is complete, are the calling party and receiving party directly connected to each other?
You (skyetel customer) are directl connected to someone yes. The recipient or not would depend on their carrier, service, wtfever.
-
@JasGot said in SIP Calls not passing audio under one specific condition.:
Just checked. I had created them originally. So they are there.
This will get into packet capture area, most likely.
-
@JaredBusch said in SIP Calls not passing audio under one specific condition.:
You (skyetel customer) are directl connected to someone yes.
They must keep tabs on the call, though, right? How else would they know the duration? So the SIP (setup) keeps its finger on the pulse of the call?
-
@JasGot said in SIP Calls not passing audio under one specific condition.:
@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.
That's PSTN. POTS is the designation for legacy non-SIP analogue lines.
-
@Dashrender said in SIP Calls not passing audio under one specific condition.:
OK so you're using Skyetel - me too.
Just tested on our VitalPBX + Skyetel and it "just works". No special config needed. It's weird to want to do that, but it can work. Your carrier COULD do the hairpin, or your PBX can.
-
@scottalanmiller said in SIP Calls not passing audio under one specific condition.:
@Dashrender said in SIP Calls not passing audio under one specific condition.:
OK so you're using Skyetel - me too.
Just tested on our VitalPBX + Skyetel and it "just works". No special config needed. It's weird to want to do that, but it can work. Your carrier COULD do the hairpin, or your PBX can.
yup, that what I test above.. worked fine.
I'm guessing I don't have a hairpin issue because there is no NAT on Vultr instances.
-
@Dashrender said in SIP Calls not passing audio under one specific condition.:
I'm guessing I don't have a hairpin issue because there is no NAT on Vultr instances.
Exactly. Rod and I said the same thing. Our PBX has a public IP address (as does yours) so it sends the call right back to itself without a problem.
-
Left column is Skyetel and right column is our pbx, this is a call from an internal extension to our external number
As you can see in the image, RTP packets stay in our pbx side, skyetel is not involved in the audio path. -
@scottalanmiller said in SIP Calls not passing audio under one specific condition.:
@Dashrender said in SIP Calls not passing audio under one specific condition.:
I'm guessing I don't have a hairpin issue because there is no NAT on Vultr instances.
Exactly. Rod and I said the same thing. Our PBX has a public IP address (as does yours) so it sends the call right back to itself without a problem.
The pbx in question is behind NAT.
