hello everybody
I am building webphone using asterisk 13.12.0 JSSIP and WebRTC.
When I make a call between 2 computer on the same VPN everything is fine
But when I call outside from my computer, the connection is not possible
Asterisk CLI Messages ERROR [4225] [C-00000038] chan_sip.c: Serious Network Trouble; __sip_xmit returns error for pkt data
And I realize the ip address used for registration and the ip address used for audio transmission is different, it seems to only use the internal ip address to transmit the audio and that is the reason I cannot connect to the outside.
Can someone tell me why and what am I doing wrong
Thanks for my bad English
It will use whatever address the other party specifies in the SDP as the destination address to transmit the a audio. Whilst the source address will be the internal address, your router should change that. However, if you specify rtp_symmetric=yes, and it receives media, on the correct port number, from the external address, it will start using that as the destination for future media.
If you really meant the address for incoming media, that has its own configuration option.
thank for your Reply
I tried adding rtp_symmetric=yes in sip.conf but the result is still the same. I’m beginner with asterisk so the data flow I don’t really understand yet
can you first explain for me the situation I’m in, and how to fix the Serious Network Trouble error
because if I can’t call out then this app becomes meaningless
You also seem to be a beginner with networks and SIP. In that case, you shouldn’t be trying to use WebRTC. Also, you should not be trying to use WebRTC with an essentially obsolete version of Asterisk.
I know that and I’ll try to learn more, please give me advice so I can fix it
because my company is using asterisk 13.12.0 and my boss assigned me to learn how to build webRTC on asterisk 13.12.0.
Thank you so much for helpful!
Change what is causing the system call to fail. My guess is that it is a sendto call. You may need to run under a debugger to find the exact return code and see the exact parameters passed. If this is associated with learning the media address, it might not be an error at all, but a transient state.
Warnings, like this, describe what went wrong at a low level in the processing. They don’t tell you where the configuration error was, and experienced users probably don’t see them to get an idea of where it might be, because they get the configuration right in the first place.
A more practical approach for most people is to take detailed logs of the network traffic and compare them with what you would expect if your particular system was working.