Bugs item #2412241, was opened at 2008-12-09 18:06 Message generated for change (Comment added) made by murrayc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2412241&group_id=143636
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pekka Pessi (ppessi) Assigned to: Pekka Pessi (ppessi) Summary: Registration to Ekiga.net fails Initial Comment: 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. ---------------------------------------------------------------------- Comment By: Murray Cumming (murrayc) Date: 2009-10-13 05:50 Message: So, if the problem is with ekiga.net, has anyone contacted them about it yet? ---------------------------------------------------------------------- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-06-08 13:54 Message: 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. ---------------------------------------------------------------------- Comment By: Andre Klapper (riot69) Date: 2009-04-09 09:51 Message: Maemo downstream ticket: https://bugs.maemo.org/show_bug.cgi?id=4259 ---------------------------------------------------------------------- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2009-03-03 18:49 Message: 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. ---------------------------------------------------------------------- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2008-12-10 13:17 Message: >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. ---------------------------------------------------------------------- Comment By: Inca Rose (incarose) Date: 2008-12-09 19:48 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=756076&aid=2412241&group_id=143636 ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
