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.
Dale
_______________________________________________
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/
