Hi,
The presence server will only send NOTIFYs containing presentities to
authorised entities. The only way the presence server knows whether an
entity is authorised or not is if the contact is allowed in the
pres-rules. Therefore, the client _MUST_ update the pres-rules document.
When a pres-r
Sangeeta Shah writes:
> When client A authorizes client B to see it's presence information -
> it adds an entry for client B in its resource list and updates it's
> resource list on the server.
authorizing someone to see my presence status has nothing to do with my
resource lists, which i may not
Hello All,
I did resolve this by handling the notify properly in the config file.
Now I have a new problem.and it's something that has been raised
before in the following thread:
http://web.archiveorange.com/archive/v/jZFTG3ON951Zi1WiCcK9
Would appreciate some input from the Kamailio RLS/
Hello All,
Did anyone get a chance to look at my question below?
Can anyone explain what will happen when the next hop is the rls
server address? How will this notify get handled.
Thanks,
Sangeeta
On Tue, Oct 30, 2012 at 5:01 PM, Sangeeta Shah wrote:
> I have another follow up question on RL
I have another follow up question on RLS behavior/implementation based
on some additional debugging today:
Client A (8475551001) starts up and registers with the presence server
1. It sends a subscribe with event=presence.winfo
2. Puts the following xml documents: pres-rules, rls-services, resourc
Peter/Hugh,
After a bit more debugging and playing around with the server, I
have a few more follow up questions:
1. Purpose of rls_handle_notify: I understand the purpose of
rls_handle_subscribe and rls_update_subs. What's the purpose of
rls_handle_notify? If I have kamailio configured as a pre
> Peter,
> I know the weekend is coming up, but I would love seeing this in the RLS
> README. Could you put that on your to-do list? We can't have TOO MUCH
> documentation...
>
It's all a matter of perspective. If you are writing the documentation
and there is lots to do it can certainly seem lik
Hello,
I have added comments inline below...
>Appreciate your detailed response. The client we are using is compliant
> with the GSM RCS spec and the xml (including the use of external anchors)
> comes straight from the specs. Are you aware of any RLS capable clients
> that doesn't use exte
26 okt 2012 kl. 19:07 skrev Peter Dunkley :
> Hi,
>
> External anchors are not currently supported by the Kamailio RLS module. The
> presence of these do not explain all of the symptoms you are seeing - but you
> are not going to be able to get your resource-lists working properly if they
>
Hi,
External anchors are not currently supported by the Kamailio RLS module.
The presence of these do not explain all of the symptoms you are seeing
- but you are not going to be able to get your resource-lists working
properly if they are in there - at best these will be ignored, at worst
they wi
Hugh,
Thanks for the response.
When the client subscribes to the presence.winfo event - it does
result in an entry in the active_watchers table.
Then it is sending a subscribe to the presence event with the
supported header set to "eventlist"
Also I am starting from an empty database. So as y
Hi,
I don't know what might cause exactly the issues you are seeing, but
here's what I would do to track it down.
1. If no xcap documents exist on the system, the client will get a 404
and should usually PUT some new (empty) documents.
Assuming these 'empty' documents exist, the following s
Did anyone get a chance to look at this post. I upgraded to Kamailio
3.3.2 since the changelog indicated several RLS fixes. But as soon as
I bring my client up I see 4000 entries in my PUA table and about 500+
entries in the rls_watchers table for the same presentity.
What would trigger behavior l
Can anyone provide any guidance on what the rls server_address and
outboundproxy params values should be set to when using the kamailio
server as a combined presence/rls/xcap server.
I am not sure why - but the code seems to be looping in the following
calls causing several hundreds rls_watchers a
Thanks for the response.
I did drop the uniqueness on the expires_idx INDEX for the pua table.
Now I see this error in the syslog:
Oct 23 10:33:42 RCS-Presence /usr/local/sbin/kamailio[26439]: ERROR:
db_mysql [km_dbase.c:122]: driver error on query: Duplicate entry
'2ee709f03a582d75-26439@127.0.0.
Sangeeta Shah writes:
> Only error I see in the syslog:
> Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11745]: ERROR:
> db_mysql [km_dbase.c:122]: driver error on query: Duplicate entry
> '1350937406' for key 'expires_idx'
if this comes from pua table, check that the index has been defin
To be a bit more clear: the server_address has the ip of the kamailio
server. Not sure if that's correct. Also not sure what the pua
default_domain is supposed to be set to: right now it's the server's
ip.
Sangeeta
On Mon, Oct 22, 2012 at 3:32 PM, Sangeeta Shah wrote:
> Hello All,
>I am ho
Hello All,
I am hoping the authors of the RLS/PUA modules can answer this
question since I am not sure what's going on. I have the rls module
enabled, with the following config spec:
# --rls module params --
modparam("rls", "db_url", DBURL)
modparam("rls", "db_mode", 2)
modparam("rls",
18 matches
Mail list logo
