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?
-
@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.
-
@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.
