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.:
@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.
-
@JasGot said in SIP Calls not passing audio under one specific condition.:
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.Seems like it would not help if that's what it is supposed to be doing.
-
@JasGot One thing I know from working with Sonicwalls at least 12 years is that SIP Transformations are usually not needed. Consistent NAT is what I have had to use mostly and increasing the UDP Timeout on the firewall rules.
In your case the Loopback is usually created automatically on Sonicwalls when using the Public Server Wizard.
-
@dbeato
Two things I see that may be worth testing are 1) Consistent NAT, and 2) putting the public IP in the PBXs SDP fieldHere's a comment I found in an article about Sonicwall and SIP.
By default, SIP clients use their private IP address in the SIP Session Definition Protocol (SDP) messages that are sent to the SIP proxy. If your SIP proxy is located on the public (WAN) side of the SonicWALL security appliance and SIP clients are on the private (LAN) side behind the firewall, the SDP messages are not translated and the SIP proxy cannot reach the SIP clients. -
Finally resolved by modifying the loopback rule in the router.
Key was to check this setting: "Disable Source Port Mapping"Allowing Source Port Mapping caused the router to re-write the source ip and port to the internal address. The SIP Carrier had no way to locate the internal address.
-
This post is deleted! -
@JasGot That is good to know.
