Sorry for late reply sir.I was busy.I did capture the packet trace on asterisk side here is the result
still can’t hear any sound now
local packet capture
and the call log shows RTP Timeout
stun_capture.pcapng.zip (5.5 MB)
Then that would mean traffic is not forwarded/going to your Asterisk. Neither side can talk to each other for ICE, so it would fail, and no media would flow.
1 Like
So it happens by the firewall blocking the RTP port forwarding to client?
<--- Received SIP response (556 bytes) from UDP:192.168.130.20:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.250.230.160:5060;branch=z9hG4bKPj9f199331-8de9-4e17-9202-c0ffb5ab8da5;received=172.250.230.160;rport=5060
From: <sip:testnope@172.250.230.160>;tag=0f7a2ce2-de53-4be4-b2c5-a228294cf2c1
To: <sip:192.168.130.20>;tag=as6d480ec8
Call-ID: 49384272-9e4b-4933-8063-d4ed3ab6e8d8
CSeq: 33232 OPTIONS
Server: CAIP SIP 2.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: <sip:192.168.130.20:5060>
Accept: application/sdp
Content-Length: 0
> 0x7f09600a2960 -- Strict RTP learning complete - Locking on source address 192.168.130.20:19212
> 0x7f0960085bb0 -- Strict RTP learning after ICE completion
<--- Received SIP response (858 bytes) from UDP:192.168.130.20:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.250.230.160:5060;branch=z9hG4bKPjea5f439f-9044-4144-bcb3-60edb08f5db5;received=172.250.230.160;rport=5060
From: <sip:012399009@172.250.230.160>;tag=ddc2e99b-2869-4948-b0fe-f13ceb36a070
To: <sip:09978551579@192.168.130.20>;tag=as42911d6a
Call-ID: 72da17c8-a4f7-4b69-8c6d-7e75a382d613
CSeq: 18605 INVITE
Server: CAIP SIP 2.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: <sip:09978551579@192.168.130.20:5060>
Content-Type: application/sdp
Content-Length: 270
v=0
o=root 852153712 852153712 IN IP4 192.168.130.20
s=CAIP SIP 2.0
c=IN IP4 192.168.130.20
t=0 0
m=audio 19212 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
i think the client RTP learning is complete but webrtc client is still not complete in RTP learning think that might be some issues cause by FIREWALL?
This isn’t WebRTC SDP.
Also client and server are ambiguous, as their definitions in SIP don’t align with those that new users use. In the example 192.160.130.20 is the server user agent, and 172.250.230.160 is the client user agent, but I suspect you are using client and server the other way round.
1 Like
yes david551, i was using the asterisk with virtual IP provided by Fortinet,the asterisk is behind NAT(Fortinet firewall) local server and sip gateway is on local too.the sip gateway has given ip address to our local server ip 172.250.230.160 then the fortinet is forwarded to public ip address but sadly there is RTP timed out
Is 172.250.230.160 your public IP? Are you US located?
NetRange: 172.248.0.0 - 172.251.255.255
CIDR: 172.248.0.0/14
NetName: RRWE
NetHandle: NET-172-248-0-0-1
Parent: NET172 (NET-172-0-0-0-0)
NetType: Direct Allocation
OriginAS: AS7843, AS11955, AS20001
Organization: Charter Communications Inc (CC-3517)
[…]
On Saturday 14 December 2024 at 12:50:48, RizeKishimaro via Asterisk Community
wrote:
i was using the asterisk with virtual IP provided by Fortinet,
the asterisk is behind NAT(Fortinet firewall) local server and sip gateway is
on local too.
What do you mean by “SIP gateway”? Maybe I missed something earlier in this
thread, but I think it would be helpful if you would explain in some detail
precisely what your networking setup is.
the sip gateway has given ip address to our local server ip 172.250.230.160
You do realise that this is a public address, yes?
It reverse resolves to the hostname syn-172-250-230-160.res.spectrum.com.
It seems like you are perhaps confusing it with the range 172.16.0.0/12 (whose
highest address is 172.31.255.255) and thinking that it’s a private address.
then the fortinet is forwarded to public ip address
Please explain your network setup. By all means obfuscate any public IP
addresses, but only in a way such that we can still tell “this address here is
the same as that address there” and “these two addresses are in the same
subnet” etc.
Perhaps just substitute the final octet of each address with a letter, being
consistent to always change the same octet for the same letter, and not using
the same letter for different octets.
Finally, the use of the phrase “SIP gateway” makes me slightly nervous - is
there a “SIP helper” or “SIP ALG” (Application Layer Gateway" involved in this
setup? If there is, I strongly recommend that you turn it off, since in my
experience at least “SIP helpers” are completely mis-named and either cause
problems, or at least make troubleshooting more difficult than without them.
Antony.
–
I don’t know, maybe if we all waited then cosmic rays would write all our
software for us. Of course it might take a while.
-
Ron Minnich, Los Alamos National Laboratory
Please reply to the list; please *don't* CC me.
1 Like
that is my private IP address(Local IP Address).
Public ip address is 43.242.135.215
here is the break down of my network setup
43.242.135.215(Fortinet Virtual Public IP) <-> 43.242.135.210(Fortinet Firewall IP) <-> 172.250.230.160(local Asterisk server IP) <-> 192.168.130.20(The Local Sip Provider Gateway IP that takes PSTN number from VoIP providers)
the 172.250.230.160 is my Local Asterisk Server address,But why did it goes up with public address of that domain?I will try to analyze it thank you. 
I think it’s more complex.
The sip provider i meant is VoIP provider(MPT) to our services.And i disabled SIP ALG Sip Helper in Fortinet.
Thank you.
Le 14/12/2024 à 15:16, RizeKishimaro via Asterisk Community a écrit :
that is my private IP address(Local IP Address).
Public ip address is 43.242.xx5.xxx
It can’t be your private IP as it is a well known public IP as I showed
you. 172.16.0.0/16 is private
20-bit block 172.16.0.0 – 172.31.255.255 16 contiguous class B networks
–
Daniel
1 Like
Hi, The 172.250.230.160 is the VM ip address of the local server but i have no idea how it went to public.Thank you for your answer tootai(Daniel)
Le 14/12/2024 à 15:46, RizeKishimaro via Asterisk Community a écrit :
Hi, The 172.250.230.160 is the VM ip address of the local server but i
have no idea how it went to public.Thank you for your answer
tootai(Daniel)
It didn’t went public, YOU choose a wrong IP for your VM! This range
belongs to Charter Communication in the US, AS7843, AS11955 and AS20001
Check the whois database
–
Daniel
1 Like
Ohh dear,Guess i need to assign my VM different IP address so it will work?
On Saturday 14 December 2024 at 15:10:14, tootai via Asterisk Community wrote:
It didn’t went public, YOU choose a wrong IP for your VM!
How can a customer who rents a VM from a hosting provider select the IP
address of the machine? Surely it is given to them by the hosting provider.
If you arbitrarily change the IP address of your Internet-facing interface so
that it no longer matches what your hosting provider expects, then networking
simply becomes notworking.
At the very least, your Internet-facing address has to be in the same subnet
as the gateway (default route) address given to you by the hosting provider.
However, maybe I am ghetting confused here and it’s not the Internet-facing
interface we’re talking about here? I’m puzzled by this from the previous
description of the networking setup:
172.250.230.160 (local Asterisk server IP) ↔ 192.168.130.20 (The Local Sip
Provider Gateway IP that takes PSTN number from VoIP providers)
How does 172.250.230.160 connect to 192.168.130.20 (which definitely is a
private IP address)?
Antony.
–
+++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++
Please reply to the list;
please *don't* CC me.
Thank you for your question, Antony. To clarify:
The IP address 172.250.230.160 is assigned to our VM by the Esxi, and we have not arbitrarily changed it. It remains part of the subnet expected by the Esxi, ensuring connectivity to their gateway and compliance with their networking configuration.
Regarding the connection between 172.250.230.160 (local Asterisk server IP) and 192.168.130.20 (the local SIP provider gateway IP), this involves internal routing within our virtual environment. Specifically, we have implemented inter-VLAN routing on our VM, which allows communication between the VLAN hosting the Asterisk server and the VLAN connected to the SIP provider gateway. This configuration enables traffic to route correctly between these two private subnets.
It is important to note that 192.168.130.20 is a private IP address used within the provider’s local network. This address is not Internet-facing but exists within a private layer, likely configured by the SIP provider to handle local communication.
I hope this clears up the confusion. Let me know if further details are needed!
Don’t know if it will work but if your router with public IP does hes job he will NOT routed packet to this IP in your local network but using Internet. Give a 172.16.30.0.0/16 IP or better a 192.168.130.0/24
1 Like
Thank you tootai, I will try to change internal VM ip to that.
On Saturday 14 December 2024 at 15:42:06, RizeKishimaro via Asterisk Community
wrote:
Regarding the connection between
172.250.230.160(local Asterisk server
IP) and192.168.130.20(the local SIP provider gateway IP), this
involves internal routing within our virtual environment.
…
This configuration enables traffic to route correctly between these two private
subnets.
I could accept the phrase “local subnets” or “internal subnets”, but please
don’t use the word “private” when at least some of the addresses are public
and registered to (other, by the sound of it) organisations.
I hope this clears up the confusion. Let me know if further details are
needed!
I’m not sure how much further this gets us with sorting out your RTP problems,
but I do agree with tootai that using 172.250.x.y for internal / local
purposes is simply wrong.
All internal networks (not publicly-facing one with addresses assigned by some
hosting or connectivity provider) should be using addresses from RFC1918:
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
You can get away with using other addresses, but it’s confusing, it’s wrong,
it makes debugging harder, and means that if you ever need to communicate with
the organisation those addresses have actually been assigned to, you can’t.
Antony.
–
If you ask a Yorkshireman whether he knows the German word for “egg”,
don’t be surprised if he just smiles and says “Aye”.
Please reply to the list;
please *don't* CC me.
1 Like
so instead of getting of our private address when negotiating it goes to the public ip address that is from outside of the world. that’s why?