Why sipXecs challenges REFER

When looking at traces of a REFER request (usually used when doing a transfer) you'll sometimes see the sipXecs proxy challenge the request for authentication (a 407 response).

It helps to understand the problem we are trying to solve. The sipXproxy may restrict some users to a subset of possible calls - for example, I might be allowed to make local PSTN calls but not International PSTN calls. This is enforced by challenging an INVITE that requires some privilege level and then using the authenticated identity to look for that privilege (note: this has no relationship to any registration authentication; registration only controls what calls we route '''to''' a UAS; it has no effect on calls '''from''' a UAC).

We want it to be true that '''if I can call a given target, then I can also transfer any call to that target'''.

A problem with this is that in a SIP blind transfer, the transferee sends the INVITE to the transfer target - and the tranferee may not be in the local domain or have any credentials for it. We want that INVITE to be authorized using the identity of the transfer controller, so...

The sipXproxy looks at any REFER; if both of these are true:

1. The Refer-To URI is in the domain the sipXproxy is authoritative for
2. The request is not authenticated

then it challenges the REFER for authentication.

Transfers to some other domain are not challenged (this is because in practice they seem to usually be from a party in that foreign domain so the controller isn't likely to have local credentials).

When the sipXproxy gets an authenticated blind transfer request (REFER with 1 above true and 2 false), it rewrites the Refer-To URI, adding a private signed identity header parameter (X-Sipx-Authidentity) to it. When the transferee sends the INVITE, this private header shows up at the sipXproxy as an identity that it can then use to authorize the call.

This is not perfectly secure, but in practice it's good enough for our needs.