The Privacy header controls specific behavior around removing the
P-Asserted-Identity header. If you think a P-Asserted-Identity header
might be added to a request, and want it removed, then you had better
add Privacy:id, regardless of what kind of request (or response) it is.
The contexts in which the P-Asserted-Identity header is inserted are
defined elsewhere, using conventions not standardized by the ietf. So
you should either insert the header in all requests and responses, or
else do so in accord with the environment where you operate. In the case
of IMS, I *think* it is sufficient to include in dialog establishing
requests and their responses.
Paul
Sigrid Thijs wrote:
> Stephen McVarnock wrote:
>> I would have thought it would be required in any Re-INVITE but certainly
>> not in any of the other request types.
>
> The privacy header is allowed in other requests than INVITE according to
> RFC3323:
>
> Header field where proxy ACK BYE CAN INV OPT REG
> ___________________________________________________________
> Privacy amrd o o o o o o
>
> Header field SUB NOT PRK IFO UPD MSG
> ___________________________________________________________
> Privacy o o o o o o
>
> I would think the Privacy header should be added to all in-dialog
> requests, because otherwise it can reveal information about the identity
> of the caller. But I haven't found a clear statement about this
> behavior, or did I miss something?
>
>> Sigrid Thijs wrote:
>>> Hi,
>>>
>>> when a user wants to make a call but not reveal his identity, this can
>>> be done by adding a Privacy header with "id" to the INVITE (as described
>>> in RFC3323 and RFC3325).
>>> Is it also necessary to add this Privacy header to all the next
>>> in-dialog requests, like re-INVITE and BYE?
>>>
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
