Andrés, I'm not familiar with the routing policies of Open-IMS. thus you may want to ask also on their mailing lists. But at least I can talk about the RLS in general and Kamailio:
Theory: =======
If the RLS receives a SUBSCRIBE for a RL it generates subscriptions for the list entries. These are either virtual subscriptions (if the RLS acts also as Presence Server and thus knows already the state of a list member in the same domain) or back-end subscriptions (if the list member is in another domain or RLS and PS are separate instances).
If the list member is on another domain it depends on the local policies if the RLS sends the SUBSCRIBE directly to the target domain or sends the request to a local outboundproxy.
If the list member is in the same domain but the RLS and PS are dedicated instances, then routing depends also on the local policy. Of course it would be most efficient if the RLS sends the SUBSCRIBE request directly to the PS, but local policy may also decide to route the request via some proxy (e.g. for accounting or authorization).
Kamailio ========
RLS server in Kamailio is a dedicated module and has no direct interaction with presence server modules. Thus, RLS module does not support virtual subscriptions but all subscriptions are real SIP back-end subscriptions.
RLS module in Kamailio does not support setting an outbound proxy (IIRC code is there but broken), thus, when RLS module sends SUBSCRIBE requests it always uses normal SIP resolutions mechanism to find the target address (NAPTR/SRV/A)
Your Setup ===========
Now, you have to decide how you want the SUBSCRIBE request to be routed - directly from RLS to PS or via some proxy? This is a policy decision and you have to decide (or maybe 3GPP has such a policy?). Once you have decided how you want the back-end SUBSCRIBE to be routed, then you can implement it - either current Kamailio behavior is fine or you have to find some workarounds.
We recently had some discussions on the list about missing features in RLS module compared to Opensips' RLS module. Opensips support outboundproxy and also uses the proper resource list type. That's why I use Opensips as PS/RLS although my main proxy is still Kamailio.
regards Klaus
Am 04.01.2011 21:14, schrieb "Andrés S. García Ruiz":
Hi,
Thanks. I've already been sniffing the network. The capture file of the presence server (kamailio) and the ua (watcher) is attached.
Backend subscriptions must be sent to what CSCF of the presentity domain? The S-CSCF? You wrote me that Kamailio uses dns queries in order to determine the ip of the next IMS entity. In case of a subscription to list@open-ims.test, what dns query will Kamalio do?
The subscription message is:
SUBSCRIBE sip:restricted_areas_presentities@open-ims.test SIP/2.0 Call-ID: nYhLl92BHRHtSTy3f8iNZ1v6irOhhfd2fNnFtSXTOlk. CSeq: 1 SUBSCRIBE From: "restricted_areas" sip:restricted_areas@open-ims.test;tag=f733f739 To: sip:restricted_areas_presentities@open-ims.test Via: SIP/2.0/TCP 155.54.190.245:8060;rport;branch=z9hG4bK-d8754z-a71d1c184df2d432-1---d8754z- Max-Forwards: 70 Event: presence Accept: multipart/related, application/rlmi+xml, application/pidf+xml, application/auth-policy+xml Expires: 30000 Contact: sip:restricted_areas@155.54.190.245:8060 Supported: eventlist Route: sip:orig@scscf.open-ims.test:6060;lr Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO User-Agent: X-Lite IMS-OSGi-Client 0.1 CVS-Mon_Jan_03_09-56-46_CET_2011 Content-Length: 0
And the XCAP document:
<?xml version="1.0" encoding="UTF-8"?><rls-services
xmlns:rl="urn:ietf:params:xml:ns:resource-lists" xmlns="urn:ietf:params:xml:ns:rls-services"><service uri="sip:restricted_areas_presentities@open-ims.test"><resource-list><list name="friends"><rl:entry uri="sip:testuser01@open-ims.test"/>rl:entry uri="sip:testuser02@open-ims.test"/</list></resource-list><packages><package>presence</package></packages></service></rls-services>
The URI for the document is: /xcap-root/rls-services/users/sip:restricted_areas@open-ims.test/index
Could anyone send me a capture file with the whole process of the subscription to the rls and the notifies sent along with the configuration files of Kamailio (if needed) and the xcap documents?
Thank you all, Andrés.
El 04/01/11 15:08, Klaus Darilion escribió:
Am 04.01.2011 13:06, schrieb "Andrés S. García Ruiz":
Hello,
Thanks for your responses and happy new year!
Could anyone tell me how to make the RLS module work properly?
I've tried several different solutions, but I still don't know what's the expected behaviour of the RLS.
I'm using the Kamailio integrated presence server + RLS. Then, the RLS is supposed to send a SUBSCRIBE to each of the presentities in the subscribed presence list?
Correct. So-called "backend subscriptions"
In that case, and if the domain of the presentity is the same as the used by the watcher, the SUBSCRIBE will go back to the Kamailio?
yes.
This is the reason why I don't receive the notify. There are no dialogs for the subscription:
5(13925) DEBUG: presence [notify.c:1302]: found 0 dialogs( 0 in database and 0 in hash_table) 5(13925) DEBUG: presence [notify.c:1387]: Could not get subscription dialog 5(13925) DEBUG: presence [notify.c:1461]: dialog info: 5(13925) DEBUG: presence [notify.c:122]: [pres_uri]= sip:restricted_areas_presentities@open-ims.test [to_user]= restricted_areas_presentities [to_domain]= open-ims.test [w_user]= restricted_areas [w_domain]= open-ims.test [event]= presence [status]= active [expires]= 0 [callid]= nYhLl92BHRHtSTy3f8iNZ1v6irOhhfd2fNnFtSXTOlk. [local_cseq]=1 [to_tag]= a6a1c5f60faecf035a1ae5b6e96e979a-5cc7 [from_tag]= f733f739 [contact]= sip:restricted_areas@155.54.190.245:8060 [record_route]= sip:mo@scscf.open-ims.test:6060;lr,sip:mo@pcscf.open-ims.test:4060;lr
5(13925) DEBUG: presence [hash.c:471]: pres_uri= sip:restricted_areas_presentities@open-ims.test 5(13925) DEBUG: presence [notify.c:643]: No record exists in hash_table 5(13925) DEBUG: presence [notify.c:1515]: Could not get the notify_body 5(13925) DEBUG: presence [notify.c:225]: state = terminated 5(13925) DEBUG: presence [notify.c:1555]: headers: Max-Forwards: 70 Event: presence Contact: sip:155.54.190.245:5060;transport=udp Subscription-State: terminated;reason=timeout
Any hints?
That shouldn'T be the problem. You should see the backend subscription by sniffing on the loopback interface, e.g. to sniff an all interfaces (and in nice format) use:
ngrep -d any -W byline -t -P "" port 5060
regards Klaus