Scott Lawrence wrote:
> On Mon, 2008-01-28 at 13:04 +0000, SCG2 wrote:
>
>> Is there any circumstance at all where it makes sense to challenge an INVITE
>> which is putting a call on hold?
>
> A UAS or a Proxy is allowed to challenge any request (except an ACK,
> since it isn't supposed to get any response) for any reason at any time,
> and the UAC should be prepared to retry with authentication. It doesn't
> make sense to explicitly mention this fact in every discussion of every
> SIP usage - it's just true unless there is a specific exception called
> out by some spec.
>
> Paul Kyzivat responds:
>
>> [...] practically speaking authentication is
>> rarely done on in-dialog requests. Bypassing it assumes that the dialog
>> id is only known to the parties on the signaling path, even though this
>> might not be true.
>
> We've recently started challenging some in-dialog requests:
> specifically, any REFER without Replaces is challenged by our proxy so
> that we can use the identity of the transfer controller to authorize the
> INVITE generated by the transferee.
Can you explain further? (I'm just curious to understand what is in the
wild.)
This is the proxy on the terminating side? (The one that did the AOR to
Contact translation on the initial invite.) And its expecting the same
credential that is used to authorize registration?
If so, that in effect means only an agent operating on behalf of the
callee will be able to initiate such a REFER. Right? (That seems a sane
policy, but it certainly is a *policy*, and there could be others.)
This of course depends on that proxy having record-routed.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
