### Description Kamailio sending HELD request with broken sip uri when the INVITE message contains a display name or display name with special character "&". ``` P-Asserted-Identity: "User &" sip:+12001112233@206.147.236.78:5060 ``` or ``` P-Asserted-Identity: "User" sip:+12001112233@206.147.236.78:5060 ``` For the first case, HELD request body looks like ```xml <?xml version="1.0" encoding="UTF-8"?> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held" responseTime="5000"> <locationType exact="true">geodetic locationURI</locationType> <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <uri /> </device> </locationRequest> ``` Here `uri` element is empty.
For the second case, HELD request body looks like (ident formatted) ``` <?xml version="1.0" encoding="UTF-8"?> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held" responseTime="5000"> <locationType exact="true">geodetic locationURI</locationType> <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <uri>"User" <sip:+12001112233@206.147.236.78:5060></uri> </device> </locationRequest> ``` In [HELD schema](https://datatracker.ietf.org/doc/html/rfc6155#section-6) the 'uri' element specified as ``` <xs:element name="uri" type="xs:anyURI"/> ``` For me looks like here `display name` cannot be used. Moreover, if an inbound call does not contain `P-Asserted-Identity` header then `lost` properly extracts uri from the `From` header. For me look like need to improve `P-Asserted-Identity` parsing in the `lost` module and properly extract uri from header value.
Thanks for the report. It probably make sense to separate the two issues, the broken SIP URI case, and the enhancement suggestion for PAI header.
I think here not enhancement. For me here is only a broken SIP URI in the HELD request.
I also made an additional test and found `$ai` pseudo variable properly extracting uri from the `P-Asserted-Identity` header.
Thanks for testing. The LoST module uses core parser functions `../core/parser/parse_from.h` and `../core/parser/parse_ppi_pai.h` to get content of the corresponding header. When reproducing the error I saw that `get_from` and `get_pai` give different results. For `get_from` it is no problem to parse the header content of the examples above and to return the proper sip/tel uri used as HELD id, but `get_pai` also returns the display name.
I will implement my own parser, although a consistent behavior of the core parser functions would be the better option.
We should use the core parser and not re-implement parser component in modules, if not strictly necessary. One (probably unrelated) reason that get_from and get_pai return different results is that the grammar for both headers is different defined from the RFCs. But I agree that its confusing that get_from does not return display name, but get_pai does.
Have you tried to access only the user/domain part of the pai header, and not the full body? Have a look e.g. to the sipcapture module for an inspiration.
To clarify, there are C functions to actually parse a a URI component, that gives you control about what parts you want to access, [link](https://github.com/kamailio/kamailio/blob/5a2df203a244e79a1868910da312f76509...)
To clarify, there are C functions to actually parse a a URI component, that gives you control about what parts you want to access, [link](https://github.com/kamailio/kamailio/blob/5a2df203a244e79a1868910da312f76509...)
Thanks for the example - I fixed it that way and will commit it
This should be fixed by the mentioned commit. Please re-open if the issue still persists.
Closed #3426 as completed.
yes, I was tested with referenced commit. The issue does not reproduce more.
-
Henning Westerholt -
sergey-safarov
-
Wolfgang Kampichler