Manipulation of Headers and Request URIs in SIP Messages
The header manipulation feature enables you to add, modify, or remove fields in SIP headers and to modify the request URI in SIP messages. It also enables you to reject SIP messages based on information in the SIP header.
This feature is useful for solving interoperability issues between vendors and peers.
How Header Manipulation Works
To use this feature, you set up message manipulation rules and then add the rules to new transaction policies. Message manipulation rules can specify the following actions for SIP headers:
- add—Add an instance of the header field.
- add-missing—Add a new header field if the header field is missing from the SIP header.
- add-overwrite—Add a new header field if the header field is missing from the SIP header. If the header field already exists, its field value is overwritten with the new field value that you specify.
- modify-regular-expression—Change the value of a regular expression.
- remove-all—Remove all instances of the header field.
- remove-regular-expression—Remove all of the header fields that have field values that match the regular expression that you specify.
- reject-regular-expression—Reject SIP messages and terminate the usage that the message is part of.
You can also set up message manipulation rules that specify the modifications that you want to perform on regular expressions in the request URI of SIP messages.
Applying Message Manipulation Rules
After you create your message manipulation rules, you apply them using new transaction policies. Message manipulation affects the transaction that matches the policy as well as any transactions that belong to a dialog that results from the transaction.
You can apply the message manipulation rules in the following directions:
- Forward—Applied to any message going from the user agent client (UAC), or the caller, to the user agent server (UAS), or the call recipient.
- Reverse—Applied to any message going from the UAS (the call recipient) to the UAC (the caller).
Header Manipulation Examples
This topic provides examples of manipulating SIP headers.
Example: Removing a Text String from the Alert-Info Field
Apply the remove-alert-info manipulation rule to the forward direction in a new transaction policy:
manipulation-rule remove-alert-info {
actions {
sip-header Alert-Info {
field-value {
remove-regular-expression DummyDomain;
}
}
}
}The second appearance of Alert-Info in the following example is removed:
Example: Rejecting a Message Based on the Field Value of the From Header
Apply the reject-from manipulation rule to the forward direction in a new transaction policy:
manipulation-rule reject-from {
actions {
sip-header From {
field-value {
reject-regular-expression anonymous;
}
}
}
}A received SIP message request with From header with the following field value is rejected with a 403 Forbidden SIP response.
Example: Using a Regular Expression to Modify the P-Asserted-Identity Field Value
Apply the modify-p-asserted-identity manipulation rule to the forward direction in a new transaction policy:
manipulation-rule modify-p-asserted-identity {
actions {
sip-header P-Asserted-Identity {
field-value {
modify-regular-expression "sip:[0-9]+@.*" with "sip:P-Asserted-Identiy@juniper.net";
}
}
}
}A ReINVITE request received from the UAS with P-Asserted-Identity: sip:987654321@SomeDomain.com is modified to P-Asserted-Identity: sip:P-Asserted-Identiy@juniper.net and then forwarded to the UAC.
Example: Adding the Transport Protocol and “q” Parameter to the Contact Header
Apply the add-transport-q manipulation rule to the forward direction in a new transaction policy:
manipulation-rule add-transport-q {
actions {
sip-header contact {
field-value {
modify-regular-expression "(.*)" with "<\1;transport=UDP>;q=0.7";
}
}
}
}
A request received from with Contact: sip:70.100.101.1 is modified to Contact: <sip:70.100.101.1:5060;transport=UDP>;q=0.7.
Using High Availability with Message Manipulation
In the case of an active standby switchover, dialogs that were matched to a policy before the switchover continue to use the policy even if the policy is modified or deleted from the CLI.
In the case of a stateful restart, the new BSG process applies message manipulation rules to dialogs that were already matched to a policy before the switchover occurred as follows:
- If the policy did not change, the same rule is applied to new messages on the dialog.
- If the message manipulation rule was modified, the new rule is applied to new messages on the dialog.
- If the message manipulation rule was deleted, no header manipulation is applied to new messages on the dialog.
Displaying Message Manipulation Rules That Are Currently Being Applied
You can use the following show commands to view the message manipulation rules that are currently being applied to active calls on a specific BSG:
