You are right, but Ancuta, which developed the attached patch, tells me that the actual issue was when ser tried to generate an ACK on >299 responses for calls to such URNs.
Anyway, if we talk so much about this, it's not such a big deal, so here it is attached and here: http://svn.berlios.de/viewcvs/openimscore?view=rev&rev=631
Cheers,
-Dragos
Dragos Vingarzan schrieb:IIRC openser/ser can not parse service URNs. Usually, if a UAC initiates an emergency call, it looks like:
* Core - support for emergency URI,
What is this exactly? Any reference to ietf/itu specs?
I am not really sure myself as somebody else did the implementation. But all the specs should be listed here: http://www.openimscore.org/emergency . And even for us this is still partly a branch with work in progress. The thing was that ser was even crashing when it got some of these, so in any case, even if not used, it would be a good patch.
I'll have to do a diff and find out what was exactly changes as there were to many things in the last 3-4 years. And we probably have some garbage through that. I'll send the patch after some cleanup.
INVITE urn:service:sos SIP/2.0
Route: sip:uri-of-the-psap@example.com;lr
From: sip:user@domain.com;tag=123
To: urn:service:sos
...
Thus, the proxy does not even have to route based on the service URN, but just on the pre-loaded route-set. Nevertheless, the proxy must not crash or generate errors if the RURI and From/To URI does contain a service URN. Actually From/To/RURI are allowed to contain any URIs (also http URIs) - thus sr should supports parsing of these.
regards
klaus