The Ekiga.net checks during registration that both the Via and Contact headers contain a public IP address. The registation fails with 606 if the Via header contains a NATted address from the private address space.
Why do you think this is a sofia-sip problem ?
There is nothing wrong whit that.
Ekiga SIP server will end up sending the response to the udp-src address ignoring the Via host address.
The UA application must take care of the contact address by:
-Using some kind of STUN mechanism
- Learning from the REGISTER response ( checking the Via parameters ) and reusing a new REGISTER
- or not taking care at all and failing to get incoming calls.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>The UA application must take care of the contact address by:
>-Using some kind of STUN mechanism
>- Learning from the REGISTER response ( checking the Via parameters ) and
reusing a new REGISTER
Sure, we do the latter, but the ekiga.net proxy rejects this REGISTER with 606 Not Acceptable.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It shouldn't be an interop problem to put the public transport address in the client's Via. When the binding breaks, the proxy should signal it with rport and received which will be different from the address in Via.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I reverse my stance from the earlier comments The modification of transport address in Via may cause interoperability problems with proxies that implement support for RFC 3581 and rely on the specified behavior for NAT-aware policies.
The restriction imposed by the proxy is arbitrary. It does not follow any specification or best practice published by IETF that I'm aware of. The answer is, fix the proxy.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> So, if the problem is with ekiga.net, has anyone contacted them about it
yet?
Sort of; last word I heard from them is, they need this restriction so that their own client keeps working. I still think they shouldn't impose a restriction on the address in Via, and sofia-sip should now re-register with a discovered mapped address in Contact. I didn't press this last comment to them yet, though.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Why do you think this is a sofia-sip problem ?
There is nothing wrong whit that.
Ekiga SIP server will end up sending the response to the udp-src address ignoring the Via host address.
The UA application must take care of the contact address by:
-Using some kind of STUN mechanism
- Learning from the REGISTER response ( checking the Via parameters ) and reusing a new REGISTER
- or not taking care at all and failing to get incoming calls.
>The UA application must take care of the contact address by:
>-Using some kind of STUN mechanism
>- Learning from the REGISTER response ( checking the Via parameters ) and
reusing a new REGISTER
Sure, we do the latter, but the ekiga.net proxy rejects this REGISTER with 606 Not Acceptable.
It shouldn't be an interop problem to put the public transport address in the client's Via. When the binding breaks, the proxy should signal it with rport and received which will be different from the address in Via.
Maemo downstream ticket: https://bugs.maemo.org/show_bug.cgi?id=4259
I reverse my stance from the earlier comments The modification of transport address in Via may cause interoperability problems with proxies that implement support for RFC 3581 and rely on the specified behavior for NAT-aware policies.
The restriction imposed by the proxy is arbitrary. It does not follow any specification or best practice published by IETF that I'm aware of. The answer is, fix the proxy.
So, if the problem is with ekiga.net, has anyone contacted them about it yet?
> So, if the problem is with ekiga.net, has anyone contacted them about it
yet?
Sort of; last word I heard from them is, they need this restriction so that their own client keeps working. I still think they shouldn't impose a restriction on the address in Via, and sofia-sip should now re-register with a discovered mapped address in Contact. I didn't press this last comment to them yet, though.
What do you know, it works for me with the sofia-sip build we use in Maemo 5.
Can somebody else confirm if it works with sofia-sip trunk?
I'm not 100% sure I did everything correctly, but using sofia-sip trunk didn't change anything for me.
Affecting Ubuntu via https://bugs.launchpad.net/ekiga/+bug/294994 , debian via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535796 , both via telepathy-sofiasip on https://bugs.freedesktop.org/show_bug.cgi?id=19328
Reported against ekiga's bug tracker at: https://bugzilla.gnome.org/show_bug.cgi?id=624751
Any updates?