In an attempt to draw more attention to the issue that I brought here: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2009-July/008105.html I'll be trying to rephrase it under this new thread. I noticed that some of our user had troubles to register with Callcentric.com. Looking at the problem under Wireshark, here's what is happening. Each time a transaction occurs, Pjsip is doing a namelookup using either its internal resolver or gethostbyname(). dig callcentric.com gives: ;; ANSWER SECTION: callcentric.com. 10800 IN A 204.11.192.36 callcentric.com. 10800 IN A 204.11.192.37 callcentric.com. 10800 IN A 204.11.192.38 callcentric.com. 10800 IN A 204.11.192.39 callcentric.com. 10800 IN A 204.11.192.22 callcentric.com. 10800 IN A 204.11.192.23 callcentric.com. 10800 IN A 204.11.192.31 callcentric.com. 10800 IN A 204.11.192.34 callcentric.com. 10800 IN A 204.11.192.35 so the chances of getting a different IP when querying the nameserver are high. When we send the 1st REGISTER request, an ip - let's call it "X" - is obtained. "X" then replies to the UAC by sending a 407 challenge. As expected, PJSIP responds to that challenge in pjsip_auth_clt_reinit_req, then it goes through pjsip_regc_send, pjsip_endpt_send_request, pjsip_tsx_send_msg and a new lookup is performed. At that point, it is highly probable that a new ip Y will be returned. With Y, the new REGISTER is then sent in response to the challenge sent by X. Y don't know what's happening and complain by replying to the UAC with a 407 stale=true, indicating the the nonce is invalid (which is normal since it didn't even send it in the first place). The big picture --------------- localAddress -> 204.11.192.22 : REGISTER callcentric.com 204.11.192.22 -> localAddress : 407 Proxy Authentication Required localAddress -> 204.11.192.36 : REGISTER callcentric.com 204.11.192.36 -> localAddress : 407 Proxy Authentication Required, stale=true (...) "Maximum number of stale retries exceeded (PJSIP_EAUTHSTALECOUNT)" The client will eventually be able to connect to the proxy when the sequence REGISTER/407/REGISTER/ is all targeted at the same IP address. Expected Behaviour ------------------ - REGISTER response to a 407 challenge should always be targeted at the same IP address that sent that challenge. - Subsequent re-REGISTER should be targeted at that same inital IP address - for the rest, keep the same behaviour that Benny described in http://osdir.com/ml/voip.pjsip/2007-07/msg00224.html "But that doesn't mean it will necessarily cause any problems, as true SIP stateful proxies only need to be transaction stateful, not call stateful. So if the next request goes to the other proxies, it should still be routed correctly." Now, does the RFC say to do so ? Asterisk seems to implement the "right" behaviour: https://issues.asterisk.org/bug_view_advanced_page.php?bug_id=12312 A project like Twinkle (which implements its own SIP stack ?) also does that. For further reference, this issue is documented in our ticket system at : http://projects.savoirfairelinux.net/issues/show/1852 Thank you, Pierre-Luc Bacon, development team for SFLPhone at savoirfairelinux.com
