On Sep 12, 2008, at 9:08 AM, Scott Lawrence wrote: > > On Thu, 2008-09-11 at 15:22 -0400, Michael Jerris wrote: >> On Sep 11, 2008, at 12:45 PM, M. Ranganathan wrote: >> >>> On Thu, Sep 11, 2008 at 12:31 PM, Christopher Parfitt >>> <[EMAIL PROTECTED]> wrote: >>>> Sorry I did set the sipxproxy to DEBUG but I had to restart sipxpbx >>>> mannually as it did not "take" >>>> >>>> Here is the DEBUG sipxproxy log >>>> >>>> >>>> C. >>>> >>> >>> I see the same problem as I was having. The PAI header makes >>> FreeSWITCH send out a challenge response. I dont know whether an >>> external issue is appropriate for this case or we can remove PAI for >>> all "in-domain" routing (not bound for a gateway). Opinions >>> solicited >>> ..... >>> >> >> I am not sure how PAI header would cause freeswitch to auth. What >> auth settings are being setup on the sip profile these calls are >> coming from? >> >> Scott- Should we be sending 401 not 407 when authenticating an >> invite? > > Freeswitch (at least in the conference bridge instantiation) is a user > agent, so it should use 401.
I will take a look at this in our code. Is there any important processing different between 401 and 407? >> How should freeswitch be authenticating these calls? Not at all? > > Whether or not calls into the conference should be authenticated at > the > SIP level is a requirements question... my intuition is that they > should > not because there is some DTMF conference access code anyway, and > requiring authentication would mean that callers outside the domain > could never join. Auth can be completely disabled for an ip/port sip binding by setting auth_calls param to false in the sip profile configuration. Mike _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
