Hi all,
it might be a minor issue, or it might not be an issue at all, but I stumbled over following statements in RFC 3261:
Chapter 16.6 Request Forwarding (of a proxy)
1. Copy request
The proxy starts with a copy of the received request. The copy
MUST initially contain all of the header fields from the
received request. Fields not detailed in the processing
described below MUST NOT be removed. The copy SHOULD maintain
the ordering of the header fields as in the received request.
The proxy MUST NOT reorder field values with a common field
name (See Section 7.3.1https://www.rfc-editor.org/rfc/rfc3261.html#section-7.3.1). The proxy MUST NOT add to, modify,
or remove the message body.
An actual implementation need not perform a copy; the primary
requirement is that the processing for each next hop begin with
the same request.
Chapter 16.7 Response Processing (at a proxy)
9. Forward response
After performing the processing described in steps "Aggregate
Authorization Header Field Values" through "Record-Route", the
proxy MAY perform any feature specific manipulations on the
selected response. The proxy MUST NOT add to, modify, or
remove the message body. Unless otherwise specified, the proxy
MUST NOT remove any header field values other than the Via
header field value discussed in Section 16.7https://www.rfc-editor.org/rfc/rfc3261.html#section-16.7 Item 3. In
particular, the proxy MUST NOT remove any "received" parameter
On the other hand, everywhere in the Internet (starting with stackoverflow), you can read it is OK, if a SIP proxy modifies a body, and also kamailio allows it.
Might be a question for the coffee break.
All the best Christoph
The RFCs are correct; strictly speaking, a proxy should not alter the encapsulated message body, or most other SIP message attributes.
Kamailio is a huge toolbox with many capabilities, not unlike a programming language. It gives one the power to do a great many things.
Some of these things aren't standards-compliant, and that's okay. The ends justify the means. Other times--many times--call for judicious restraint, as just because Kamailio can do something doesn't mean that you should do it, or that using a tool Kamailio offers to do something bluntly is a good substitute for doing something delicately.
Knowing the difference is the soul of experience. :-)
-- Alex
On 6 Mar 2024, at 06:19, Valentin Christoph via sr-users sr-users@lists.kamailio.org wrote:
Hi all, it might be a minor issue, or it might not be an issue at all, but I stumbled over following statements in RFC 3261: Chapter 16.6 Request Forwarding (of a proxy) 1. Copy request
The proxy starts with a copy of the received request. The copy MUST initially contain all of the header fields from the received request. Fields not detailed in the processing described below MUST NOT be removed. The copy SHOULD maintain the ordering of the header fields as in the received request. The proxy MUST NOT reorder field values with a common field name (See Section 7.3.1). The proxy MUST NOT add to, modify, or remove the message body. An actual implementation need not perform a copy; the primary requirement is that the processing for each next hop begin with the same request.
Chapter 16.7 Response Processing (at a proxy) 9. Forward response
After performing the processing described in steps "Aggregate Authorization Header Field Values" through "Record-Route", the proxy MAY perform any feature specific manipulations on the selected response. The proxy MUST NOT add to, modify, or remove the message body. Unless otherwise specified, the proxy MUST NOT remove any header field values other than the Via header field value discussed in Section 16.7 Item 3. In particular, the proxy MUST NOT remove any "received" parameter
On the other hand, everywhere in the Internet (starting with stackoverflow), you can read it is OK, if a SIP proxy modifies a body, and also kamailio allows it. Might be a question for the coffee break. All the best Christoph __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Hello Christoph,
Kamailio is providing a lot of different functions. Some of these functions could be used to implement a network element with features which are forbidden in the RFC 3261 and/or other relevant RFCs. One of the most prominent examples is e.g., rewriting of From and To headers. It is in the end the responsibility of the implementing person to ensure that the relevant standards in the specific environments are observed.
Cheers,
Henning
From: Valentin Christoph via sr-users sr-users@lists.kamailio.org Sent: Mittwoch, 6. März 2024 12:20 To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Onic Roman Roman.Onic@kontron.com; Scherney Theodor Theodor.Scherney@kontron.com; Friedrich Peter Peter.Friedrich@kontron.com; Wolfgang Gleinser Wolfgang.Gleinser@kontron.com; Valentin Christoph Christoph.Valentin@kontron.com Subject: [SR-Users] Question for RFC junkies / kamailio modifying message bodies
Hi all,
it might be a minor issue, or it might not be an issue at all, but I stumbled over following statements in RFC 3261:
Chapter 16.6 Request Forwarding (of a proxy)
1. Copy request
The proxy starts with a copy of the received request. The copy
MUST initially contain all of the header fields from the
received request. Fields not detailed in the processing
described below MUST NOT be removed. The copy SHOULD maintain
the ordering of the header fields as in the received request.
The proxy MUST NOT reorder field values with a common field
name (See Section 7.3.1https://www.rfc-editor.org/rfc/rfc3261.html#section-7.3.1). The proxy MUST NOT add to, modify,
or remove the message body.
An actual implementation need not perform a copy; the primary
requirement is that the processing for each next hop begin with
the same request.
Chapter 16.7 Response Processing (at a proxy)
9. Forward response
After performing the processing described in steps "Aggregate
Authorization Header Field Values" through "Record-Route", the
proxy MAY perform any feature specific manipulations on the
selected response. The proxy MUST NOT add to, modify, or
remove the message body. Unless otherwise specified, the proxy
MUST NOT remove any header field values other than the Via
header field value discussed in Section 16.7https://www.rfc-editor.org/rfc/rfc3261.html#section-16.7 Item 3. In
particular, the proxy MUST NOT remove any "received" parameter
On the other hand, everywhere in the Internet (starting with stackoverflow), you can read it is OK, if a SIP proxy modifies a body, and also kamailio allows it.
Might be a question for the coffee break.
All the best Christoph