Huijun Yang wrote: > > > Huijun Yang wrote: >> It would fail because from Joe's previous trace in the case of >> conference to external extension, the code did not seem to handle 407 >> challenge, and call failed. In this case, inviting a local user for >> some reason did not get challenged. It might be a bug in sipXproxy, >> and that is why I am asking for sipxproxy.log to verify. If it is >> indeed a bug in sipXproxy, once that bug is fixed, it will challenge >> the request in the case of inviting a local user. If the code to >> handle the challenge is not there, it will fail as well, same as the >> case of inviting external extension. > > >> I reproduced the successful conference invite and am attaching > sipXproxy.log here. > > Was not able to get the cause from the log. You may want to fire an > issue for this. > > Huijun
Huijun: Thanks for your help. Joe and I talked to Scott and it looks like everything works as expected with regard to proxy behavior in the scenario. Check the difference between conference-invite-working.xml and conference-invite.xml that Joe posted. To recapture the problem: sipXconfig is inviting users to a conference. The initial invite is not going to get challenged unless reaching the invitee requires a permission (that's why inviting local user or inviting through SIP URL works and inviting a number that has a dial rule with permission does not). And, if I understand this correctly, recent changes to authentication do not apply here at all: FROM address identity is not that of the user, it's conference server and conference server does not have credentials. The subsequent REFER is challenged as well, but that challenge is always correctly handled by sipXconfig. If sipXconfig were to respond to initial INVITE challenge with conference owners credentials, everything would work as expected: as a conference owner you'd be able to invite anyone whom you can call. I'll have another look at sipXconfig code and either post a patch for review or ask Ranga for more help. But the important thing to note is the solution is sound and the proxy behaves as expected. In the meantime, Joe will be checking in his code... D. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
