[SR-Users] RLS issue
Klaus Darilion
klaus.mailinglists at pernau.at
Wed Jan 5 10:40:19 CET 2011
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 at open-ims.test, what dns query will Kamalio do?
>
> The subscription message is:
>
> SUBSCRIBE sip:restricted_areas_presentities at open-ims.test SIP/2.0
> Call-ID: nYhLl92BHRHtSTy3f8iNZ1v6irOhhfd2fNnFtSXTOlk.
> CSeq: 1 SUBSCRIBE
> From: "restricted_areas" <sip:restricted_areas at open-ims.test>;tag=f733f739
> To: <sip:restricted_areas_presentities at 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 at 155.54.190.245:8060>
> Supported: eventlist
> Route: <sip:orig at 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 at open-ims.test"><resource-list><list
> name="friends"><rl:entry uri="sip:testuser01 at open-ims.test"/><rl:entry
> uri="sip:testuser02 at 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 at 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 at 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 at 155.54.190.245:8060 [record_route]=
>>> <sip:mo at scscf.open-ims.test:6060;lr>,<sip:mo at pcscf.open-ims.test:4060;lr>
>>>
>>> 5(13925) DEBUG: presence [hash.c:471]: pres_uri=
>>> sip:restricted_areas_presentities at 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
>
More information about the sr-users
mailing list