RFC 3327
1. Introduction
▶In SIP, Record-Route ensures proxies remain in the signaling path for requests within an existing dialog. However, REGISTER is a non-dialog request — Record-Route doesn't apply. The Path header solves this by allowing proxies to insert themselves during registration.
In IMS, the P-CSCF adds itself to the Path header during registration. The S-CSCF stores these Path entries as the Service-Route. When a request arrives for the registered UE, the S-CSCF routes it through the P-CSCF using the stored Path, ensuring policy enforcement and security.
2. Path Header Operation
▶The Path mechanism ensures that the P-CSCF is always in the routing path for incoming requests, enabling it to enforce security (IPsec), apply policy (e.g., emergency number detection), and perform charging correlation.
UE P-CSCF I-CSCF S-CSCF | | | | | REGISTER | | | | Contact:| | | |--------------->| REGISTER | | | | Path: | | | | Contact: | | | |------------------->| REGISTER | | | | Path: | | | |------------------->| | | | | | | | S-CSCF stores: | | | | Contact = | | | | Path = | | | | | | 200 OK | | | | Path: | | | |<---------------|<-------------------|<-------------------| | | | | | [Later incoming INVITE for UE] | | | | | | | | INVITE | | | INVITE | (via P-CSCF per | | |<---------------| stored Path) | | | |<-------------------|<-------------------| caller
3. Security Considerations
▶- Path header manipulation could redirect traffic through rogue proxies — trust boundaries must be enforced
- Only trusted proxies (within the operator's network) should be allowed to insert Path headers
- S-CSCF must validate that Path entries come from trusted peers
- Path is critical for security: ensures all signaling traverses the IPsec-protected P-CSCF