[SIP Beyond VoIP] question about user+event request uri userparts

[Dan Pascu]

On 1 May 2013, at 21:21, Juha Heinanen wrote:

> dan,
> 
> i did some more tests and it turned out that the escaped chars in rls
> services uri are the reason, why the service uri is not found:
> 
> May  1 21:12:01 siika /usr/sbin/pres-serv[28224]: INFO: rls [subscribe.c:94]: matching <sip%3Ajh%2Bpresence%40test.tutpro.com> to <sip:jh+presence at test.tutpro.com>

Are you running an up to date opensips server? Saul committed a fix for this in his recent body of work related to presence in opensips. I'm not sure if he added these to the 1.8 branch, but they should be in the 1.9 branch and in trunk.

> i then tried to figure out whose job it is to unescape the uri.  in
> RFC 4826 XML Resource Lists, i found this:
> 
>   If the XCAP client cannot determine whether the user intent is to
>   create or replace, the client SHOULD canonicalize the URI before
>   performing the operation.  For a SIP URI (often present in the "uri"
>   attribute of the <entry> element), this canonicalization procedure is
>   defined in Section 5.  We expect that the SIP URIs that will be
>   placed into resource lists documents will usually be of the form
>   sip:user at domain, and possibly include a user parameter.  The
>   canonicalization rules work perfectly for these URIs.
> 
> i get the impression that the service uri should have been canonizided
> (section 5) by xcap client (in this case sip-session) before the rls
> services document is created.  in the examples of the rfc, the service
> uri never contains escaped chars.  what is your opinion, is this a bug
> in python-xcaplib?

No it's not a bug and it's not in python-xcaplib (document generation is handled by python-sipsimple).

How the URI is encoded in XML is defined by the XML schemas that accompany the presence RFCs. The URI has the type xs:anyURI, which is not even specified by the SIP RFCs, but is a standard data type defined by the W3C schemas. According to them, a xs:anyURI should be percent encoded, so the content of the XML files on the XCAP server is correct to be percent encoded. It is the responsibility of the writer of the XML document to encode them and of the reader to decode them. In the application they should never appear percent encoded, only in the XML document. This was a bug in opensips that got fixed recently.

As for that URI canonization that is mentioned there, that has nothing to do with this, or with the fact that xs:anyURI needs to be percent encoded. That is something different that operates at a higher level than document schema and XML data types.

Why examples do not contain percent encoded URI I do not know, but they are wrong. I suspect is just an oversight, alongside the many I noticed in the presence RFCs. If the URI is not percent encoded, the XML document fails the schema validation.

You will need opensips to be up to date (to include the work Saul pushed) because that also adds OMA support which is required by sipsimple to work (sipsimple will not work with plain IETF presence, as it requires some of the OMA extensions - namely the ability to have external references in pres-rules).

--
Dan