### Description
Our partner sending a call with this header ``` From: "COVER JERRY & M" sip:+12099283442@206.147.236.174:5060;otg=TLMNCAXFDS0_3887;tag=gK0c7f90e2 ``` According [RFC3261](https://www.rfc-editor.org/rfc/rfc3261#section-25.1) ``` Several rules are incorporated from RFC 2396 [5] but are updated to make them compliant with RFC 2234 [10]. These include:
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" / "$" / "," unreserved = alphanum / mark mark = "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")" escaped = "%" HEXDIG HEXDIG ``` Also ``` SIP follows the requirements and guidelines of RFC 2396 [5] when defining the set of characters that must be escaped in a SIP URI, and uses its ""%" HEX HEX" mechanism for escaping. From RFC 2396 [5]:
The set of characters actually reserved within any given URI component is defined by that component. In general, a character is reserved if the semantics of the URI changes if the character is replaced with its escaped US-ASCII encoding [5]. Excluded US- ASCII characters (RFC 2396 [5]), such as space and control characters and characters used as URI delimiters, also MUST be escaped. URIs MUST NOT contain unescaped space and control characters. ``` And ``` Expanding the hname and hvalue tokens in Section 25 show that all URI reserved characters in header field names and values MUST be escaped. ```
For now, looks like `the sanity` module does not check reserver char usage. This ticket was created to collect recommendations for feature implementation.
Should be checked headers? Maybe a similar check is already present in the code and you can provide a reference? Unscaped reserved char usage in "From", "To", "P-Asserted-Identity" and "Remote-Party-ID" for display name breaking SIP message (for example the "lost" module cannot parse properly "From" header). Should such be implemented in the Kamailio core also?
### Expected behavior One of these expected: 1) Kamailio drop a message with reserved char usage in the header names and values. For TCP and TLS transport drop connection; 2) sanity module allows checking reserved char usage in the header names and values.
Kamailio should never simply drop messages with some invalid characters or "slightly" broken headers (or other values) because it must be flexible in accepting. One of the big advantages of Kamailio is the ability to allow fixing broken messages. So unless it is really broken that basic SIP parsing cannot be done, it should be left for config writer to decide when to drop or try to fix.
I am not sure if you are right with the `&` character here, because it is in the display name is not in the URI. Are you sure that `&` is not allowed in the display name? The references you pasted refer to URI, as I got it at first read.
Also, the main role of the proxy should be checking validity of all values in the signaling, but dispatching traffic, letting the end points to decide what they can handle or not. For example, if the sdp has some invalid codec id or parameters, is not the proxy that should catch that.
Then, not everything has to be done in the C code, there can be conditions done also via regexp matching or using existing functions such as:
- https://www.kamailio.org/docs/modules/devel/modules/textops.html#textops.f.s...
The Display name is in UTF8 and may contain a lot of things that can't exist unquoted in the SIP uri.
Agree with Daniel, sanity should not drop this message. Let's take the discussion to the list and close this issue.
Thanks, @oej I will close the issue because we have a localized issue with sip uri parsing in the `P-Asserted-Identity` header. https://github.com/kamailio/kamailio/issues/3426
Closed #3421 as completed.