Hi, I'm testing the trial version of the webphone on a linux, which has three interfaces: lo0, eth0 and eth1. Of course, lo0 is the local 127.0.0.0 interface. When I try to register the webphone on an asterisk located on a network reached through the eth0 interface, the operation fails because the webphone is sending 127.0.0.0 in the Via field instead sending the eth0 one and the response from the asterisk is lost, as I was able to see with wireshark. However, if I try the register operation from a zoiper softphone running on the same linux machine like the webphone, the register operation success and the Via field carries the eth0 IP, not the lo0 one. Therefore, my questions are as follow: is it a bug? does anyone know if there is any way to instruct webphone what interface IP to use for the Via field?
Thanks in advanced.
Hello
The webphone just pick up the first interface. We might change this and adjust after the serveraddress parameter in the next version, but a better solution would be if you turn off the via ip checking on your server side. This should be done on all servers who are interacting with customers. In this way, the server would just respond to the address from where it is receiving the request. The via header could be useful only for some b2b scenarios.
In don't remember exactly how you can turn off the via ip checking, but you should be able to find it easily on the asterisk forums.
Here are some more about this:
www.asteriskguru.com/tutorials/sip_nat_oneway_or_no_audio_asterisk.html
We had to set "Nat=yes" (it was "never" before) on sip.conf in the asterisk for it started to work, but we don't understand why because both of them, the Webphone and the asterisk, were in the same network without a router between them and other softphones didn't need Nat=yes to work either. We'll continue investigating the issue.
Thanks
The reason is that the webphone might insert 127.0.0.1 in the via in some circumstances. We already fixed it in the upcoming release.
But the VoIP server should always consider the source address also and not only the address sent in the signaling because that is often wrong (especially when the devices are behind NAT ...which is not your case here)
You need to register / login to be able to post in the forum
Forum home