On Thu, Sep 11, 2008 at 5:03 PM, Huijun Yang <[EMAIL PROTECTED]> wrote: > > >>> 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 think the reason to have PAI at the first place is try to comply >> with SIP Connect. If we have PAI only for "in-domain" routing, but >> bound for gateway, then we will fail that initiative... > > > >> Not really. The sipxrbidge can add the PAI in this case when it > notices an outbund request with [EMAIL PROTECTED] ( I > do that already > so I can get past AT&T testing). However it would probably be best if > the proxy did it correctly and so > that it can be used in a more > general way. > > > There are some other features that also rely on trusted PAI, such as > sourceRouting, but that has not been finalized. For now, I guess we need > to understand the FreeSWITCH problem a little better to confirm it is > indeeded caused by PAI, as Joe just said he was able to connect to > FreeSWITCH.
Concur with this. It is of course entirely possible that co-incidental with the PAI support being added to the poxy, a configuration error for freeSWITCH also crept in - thus resulting in the unexpected behavior. It would be premature to conclude that it was caused by the addition of the PAI header. I noticed the behavior right after the PAI enhancements. I suppose somebody with knowledge of FreeSWITCH can take that one up. > > Cheers > Huijun > -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
