SIP Calls not passing audio under one specific condition.
-
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.
-
@JasGot said in SIP Calls not passing audio under one specific condition.:
@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.
You're firewall needs to support hairpin, would be my guess.
-
@Dashrender said in SIP Calls not passing audio under one specific condition.:
You're firewall needs to support hairpin, would be my guess.
It does, and it is configured properly.
What do you know about SIP Transformations. This looks like it could be helpful. The PBX is the only SIP client behind the firewall. So the test should be quick and easy. I've always read to keep SIP Transformations OFF on sonicwall, but I've never read if that applies to onprem PBX or hosted PBX.
From Sonicwall:
If your SIP proxy is located on the public (WAN) side of the SonicWALL and SIP clients are on the LAN side, the SIP clients by default embed/use their private IP address in the SIP/Session Definition Protocol (SDP) messages that are sent to the SIP proxy, hence these messages are not changed and the SIP proxy does not know how to get back to the client behind the SonicWALL. Selecting Enable SIP Transformations enables the SonicWALL to go through each SIP message and change the private IP address and assigned port. -
@JasGot said in SIP Calls not passing audio under one specific condition.:
@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.
That was my point, I just didn't explain it well. Without NAT, this just works. Meaning, it's NAT configuration that's the issue.
-
@JasGot said in SIP Calls not passing audio under one specific condition.:
I've always read to keep SIP Transformations OFF on sonicwall, but I've never read if that applies to onprem PBX or hosted PBX.
Well the first rule is to not have SonicWall, lol. Number one killer of SIP traffic out there. I've never seen any case where their SIP Transformations work (nor, in theory, should it ever be needed.) It's worth testing in this scenario, nothing to lose, but it feels unlikely to help by turning it on.
