From the outset the router was specifically chosen to be just the straight forward and basic type.
There are no documented features anywhere, even by any other name, for any form of sip handling.
There is nothing resembling any type sip handling present in the routers configuration interface.
We happen to run another and separate pair of phones for direct IP to IP calling, through another dedicated
series of these same routers. These have been investigated with Wireshark during the set-up and commissioning.
If there were any such, even undocumented, sip facilitated behaviour, it would have already been observed.
It doesn’t sound like it has anything to do with the registration. It sounds like your router has some sort of SIP Helper application that is trying to assist by re-writing the ports in the INVITE. Many modern routers come with this functionality enabled by default, even though in my experience it does nothing but break SIP communications.
Take a look at your router documentation for any mention of SIP functionality and disable it.
I have opensips 2.3 beta, along with a local phone both running inside and behind the same router.
I have one port forwarded for opensips to listen on and a port range forwarded for the local phone.
There is a remote phone in another domain behind another router, also with a port range forwarded.
I am using stun for both phones and this resolves the correct IP domains for each phone.
With stun implemented and saying it is full cone on both phones. The phones can now ring each other.
The local phone can call the remote phone and there is two way audio.
When the remote phone calls the local phone, there is neither way audio.
Invites from the remote phone always appear with the correct expected provisioned sip and rtp ports.
I would expect that the local router is changing the local phones sip contact port when it registers.
When I look at a sipgrep capture of an outgoing invite both the sip and the rtp ports are changed.
I am not all that sure where in the process or even why the rtp port for the invite has been changed.
Inbound calls then of course end up sending and returning rtp through non forwarded port ranges.
What I would like to understand is how to make an inclusion, when any local phones register,
that will allow the outgoing contact details to show the phones actual provisioned sip ports.
With that correct, in the outgoing invite, the rtp streams would then normally be within the
expected range of ports opened and forwarded to the phones and that would solve the audio.
I am looking for working examples, but I have not turned up enough specific information about just this.
Knowing better where and how to start and the names of what I am looking for would be most helpful.
Users mailing list
|Free forum by Nabble||Edit this page|