> -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Worley, Dale AVAYA (BL60:9D30) > Sent: Wednesday, February 17, 2010 2:17 PM > To: Lawrence, Scott AVAYA (BL60:9D30) > Cc: sipX-dev > Subject: Re: [sipX-dev] XX-7668 Directed call pickup of a > user does not workif he has configured 'User Call Forwarding' > > On Tue, 2010-02-16 at 16:09 -0500, Scott Lawrence wrote: > > On Tue, 2010-02-16 at 14:51 -0500, Dale Worley wrote: > > > I think we're going to have to fix XX-7668 for version 4.2. It > > > seems to be due to some anomaly in how the proxy decides when to > > > challenge a SUBSCRIBE -- the initial pass through the > proxy is not > > > challenged, but two of three child forks are. The fork that > > > succeeds masks that two of the forks do not, and it > messes up call > > > pick-up. I suspect it messes up other processing, too. > > > > Did you find why those SUBSCRIBE forks are challenged? I can't see > > any obvious reason that they should have been... > > It seems to be a normal thing to challenge SUBSCRIBEs. The > problem is that two forks are challenged and one is not. > > Dale Worley updated XX-7668: > ---------------------------- > > Attachment: fork.txt > > The failure seems to be generated as follows. (See > extracts of > the logs and sample messages in attachment fork.txt.) > > The SUBSCRIBE is not challenged initially because the proxy > avoids challenging requests that will spiral. (See > SipRouter.cpp:396 et seq.) The SUBSCRIBE is sent to the > registrar and receives 3 contacts. The 2nd contact > is generated > by user-forwarding and so has an X-sipX-Authidentity header > parameter. > > When the proxy acts on the 302 and generates 3 child > SUBSCRIBEs, > the 2nd of them will not be challenged because it has an > X-sipX-Authidentity header. The 1st and 3rd do not have the > header and will be challenged. Because the 2nd request > succeeds, the auth challenges to the 1st and 3rd children are > discarded. >
Why are the 1st and 3rd children being challenged at all? Are these SUBSCRIBEs being routed by dialplans that require permissions? _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
