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