please help
----- Forwarded by Piyush Bansal/RCOM/RelianceADA on 10/10/2013 10:51 AM
-----
From:
Piyush Bansal/RCOM/RelianceADA
To:
serusers(a)iptel.org, serdev(a)iptel.org
Date:
10/09/2013 12:14 PM
Subject:
query related to NOTIFY message size
Hi there,
I have certain queries regarding batch SUBSCRIBE and NOTIFY. I
have a user who has 100 buddies in his buddy list. If any of his buddy
changes his/her presence status, that user gets a NOTIFY message with
presence status of all the 100 buddies.
In that case, the message size is exceeding 500 KB. Thats quite a
higher value for a UDP packet.
Can anybody suggest-
1. If there is any way to restrict the size of the packet.
2. How to ensure that the packet is received correctly by the client.
Thanks and Regards,
--Piyush Bansal
The information contained in this electronic message (email) and any attachments to this email are intended for the exclusive use of the addressee(s) and access to this email by any one else is unauthorised. The email may contain proprietary, confidential or privileged information or information relating to Reliance Group. If you are not the intended recipient, please notify the sender by telephone, fax, or return email and delete this communication and any attachments thereto, immediately from your computer. Any dissemination, distribution, or copying of this communication and the attachments thereto (in whole or part), in any manner, is strictly prohibited and actionable at law. The recipient acknowledges that emails are susceptible to alteration and their integrity can not be guaranteed and that Company does not guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email.
please help
----- Forwarded by Piyush Bansal/RCOM/RelianceADA on 10/10/2013 10:51 AM
-----
From:
Piyush Bansal/RCOM/RelianceADA
To:
serusers(a)iptel.org, serdev(a)iptel.org
Date:
10/09/2013 12:15 PM
Subject:
query regarding SER
HI there,
I have few queries regarding data deletion from database tables-
1. Once the timer of REGISTER expires, the entry for that user is not
getting deleted from "location" table.
2. Same thing is happening with SUBSCRIBER timer expiry. The entries from
presence tables are not getting deleted.
Please suggest how to debug this issue??
Thanks and Regards,
--Piyush Bansal
The information contained in this electronic message (email) and any attachments to this email are intended for the exclusive use of the addressee(s) and access to this email by any one else is unauthorised. The email may contain proprietary, confidential or privileged information or information relating to Reliance Group. If you are not the intended recipient, please notify the sender by telephone, fax, or return email and delete this communication and any attachments thereto, immediately from your computer. Any dissemination, distribution, or copying of this communication and the attachments thereto (in whole or part), in any manner, is strictly prohibited and actionable at law. The recipient acknowledges that emails are susceptible to alteration and their integrity can not be guaranteed and that Company does not guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email.
Hi,
Can anyone point me in the right direction for setting up SIP trunks?
Whenever I send a call to a registered user on a trunk it just sends to
destination s(a)x.x.x.x. Is there anyway to say "these extensions are
location at this destination IP and port".
Cheers,
Keith
Hello, I have to take care of an old server running kamailio 1.4 (I plan to
upgrade to latest, but I cannot do it at the moment).
It uses carrierroute and it works fine.
Now I am testing adding a new carrier and it worked.
However, sometimes I get a failure to resolve a route (using cr_route):
Oct 9 21:29:04 centos53-02121
/usr/local/src/svn/kamailio-1.4/kamailio[3160]:
ERROR:carrierroute:cr_do_route: desired routing domain doesn't exist,
prefix 99900000112233445566778899, carrier 10, domain 0
I can see the cause of the problem is because an element called "id" is
solved differently sometimes when "cr_reload_routes" is issued.
I am using always this same table:
mysql> select * from carrierroute where carrier=10;
+------+---------+--------+-------------+-------+------+------+-------+--------------------+----------------+----------------+-------------+
| id | carrier | domain | scan_prefix | flags | mask | prob | strip |
rewrite_host | rewrite_prefix | rewrite_suffix | description |
+------+---------+--------+-------------+-------+------+------+-------+--------------------+----------------+----------------+-------------+
| 4271 | 10 | 0 | 999000 | 0 | 0 | 1 | 6 |
192.168.2.123:5060 | | | NULL |
| 4272 | 10 | 1 | 999000 | 0 | 0 | 1 | 6 |
192.168.2.123:5060 | | | NULL |
+------+---------+--------+-------------+-------+------+------+-------+--------------------+----------------+----------------+-------------+
2 rows in set (0.00 sec)
When cr_route works fine, the reload logged this:
Oct 9 21:31:21 centos53-02121
/usr/local/src/svn/kamailio-1.4/kamailio[7902]:
DBG:carrierroute:get_route_tree_by_id: tree carrier_10, domain 0 : 0
Oct 9 21:31:21 centos53-02121
/usr/local/src/svn/kamailio-1.4/kamailio[7902]:
DBG:carrierroute:get_route_tree_by_id: tree carrier_10, domain 1 : 1
But when it fails, it logged this:
Oct 9 21:29:04 centos53-02121
/usr/local/src/svn/kamailio-1.4/kamailio[3160]:
DBG:carrierroute:get_route_tree_by_id: tree carrier_10, domain 0 : 1
Oct 9 21:29:04 centos53-02121
/usr/local/src/svn/kamailio-1.4/kamailio[3160]:
DBG:carrierroute:get_route_tree_by_id: tree carrier_10, domain 1 : 2
So I understand that the problem is a mismatch between a value that is
produced by kamailio when I ask for a domain (named '0' and '1') and value
of id that probably was computed based on domain at the time the route_tree
was created.
So, I was thinking, maybe domain names '0' and '1' would not be good for
this and I should use some longer names. Well i should not expect a domain
named '0' to always result in an id=0. But I would expect that whatever id
is resolved, it should happen equally for both values being matched that
came from the same base element (supposedly, the domain name).
I will test using longer names anyway, but since this problem doesn't
happen everytime I do cr_reload_routes, I was hoping to get an opinion
about it.
Regards,
Takeshi
Thank you Juha for your replies!
>From RFC3856:
A Presence Event Package for the Session Initiation Protocol (SIP)
6.11. State Agents
RFC 3265 [2] requires each package to consider the role of state
agents in the package, and if they are used, to specify how
authentication and authorization are done.
State agents are core to this package. Whenever the PA is not
co-located with the PUA for the presentity, the PA is acting as a
state agent. It collects presence state from the PUA, and aggregates
it into a presence document. Because there can be multiple PUA, a
centralized state agent is needed to perform this aggregation. That
is why state agents are fundamental to presence. Indeed, they have a
specific term that describes them - a presence server.
Seems the presence server needs to aggregate statuses from different PUAs for the same presentity into a single presence document, if I understand it correctly? Anyway it is not what happens currently with Kamailio 4.0.3 unless I'm missing anything.
Cheers,
Yufei
On 08/10/13 11:00, sr-users-request(a)lists.sip-router.org<mailto:sr-users-request@lists.sip-router.org> wrote:
Message: 2
Date: Mon, 7 Oct 2013 13:31:17 +0300
From: Juha Heinanen <jh(a)tutpro.com><mailto:jh@tutpro.com>
To: "Kamailio \(SER\) - Users Mailing List"
<sr-users(a)lists.sip-router.org><mailto:sr-users@lists.sip-router.org>
Subject: Re: [SR-Users] Presence: Duplicate entry
'username-domain-presence-*#-OFFLINE-#*' for key 'presentity_idx' when
multiple clients register using the same credentials
Message-ID: <21074.36213.575240.614265(a)siika.tutpro.com><mailto:21074.36213.575240.614265@siika.tutpro.com>
Content-Type: text/plain; charset=us-ascii
Yufei Tao writes:
> When a client (S) subscribes to this contact (username@domain) whose
> credentials are used by two clients, (S) gets NOTIFYs containing
> statuses from either of the username@domain contacts in alternation. But
> all these NOTIFYs have the same call-id.
>
> I've tried remove the constraint 'CONSTRAINT presentity_idx UNIQUE
> (username, domain, event, etag)' from the presentity table and the
> errors have gone away. Just wondering if this is something that *should*
> be done to cope with the situation where multiple presentities use the
> same credentials.
before knowing how to answer to that, i would like to know what presence
rfcs say about this situation, i.e., is current kamailio presence
implementation somehow broken when an aor (= presentity) has several
active contacts.
should notify give status of both contacts separately or should presence
server try somehow to combine status of the contacts into a single
notify? what does it mean if one contact tells that it is offline and
another online? should presence server send only one notify telling
that the presentity is online (since it is if one contact tells so)?
-- juha
On 05/10/13 11:00, sr-users-request(a)lists.sip-router.org<mailto:sr-users-request@lists.sip-router.org> wrote:
Hi
I use kamailio 4.0.3 with presence. I sometimes get these errors:
Oct 4 09:26:24 server /usr/sbin/kamailio[1292]: ERROR: presence
[publish.c:171]: msg_presentity_clean(): Marking presentity
Oct 4 09:26:34 server /usr/sbin/kamailio[1292]: ERROR: db_mysql
[km_dbase.c:122]: db_mysql_submit_query(): driver error on query:
Duplicate entry 'username-domain-presence-*#-OFFLINE-#*' for key
'presentity_idx'
Oct 4 09:26:34 server /usr/sbin/kamailio[1292]: ERROR: <core>
[db_query.c:337]: db_do_update(): error while submitting query
Oct 4 09:26:34 server /usr/sbin/kamailio[1292]: ERROR: presence
[presentity.c:1281]: mark_presentity_for_delete(): unsuccessful sql
update operation
This is when multiple SIP clients are registered using the same
credentials, they each have a presentity entry, with the same username
and domain but different etags, which is fine. But when they expire, the
presentity.etag will be filled with '*#-OFFLINE-#*', and when both
expire at about the same time, kamailio tries to fill both with the same
'*#-OFFLINE-#*' etag. Because presentity table has a 'CONSTRAINT
presentity_idx UNIQUE (username, domain, event, etag)', this gives the
errors.
Should the constraint be removed to cope with this situation?
Thank you!
Yufei
--
Yufei Tao
Red Embedded
This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message.
You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
Red Embedded Design, Company Number 06688253 Registered in England: The Waterfront, Salts Mill Rd, Saltaire, BD17 7EZ
Hi,
Wonder if anyone can point me in the right direction, or explain a bit more
about how the code in Kamailio works. I am looking to build a front end to
Kamailio so I can easily add routes etc without direct access to the config.
Thanks,
Keith
HI there,
I have few queries regarding data deletion from database tables-
1. Once the timer of REGISTER expires, the entry for that user is not
getting deleted from "location" table.
2. Same thing is happening with SUBSCRIBER timer expiry. The entries from
presence tables are not getting deleted.
Please suggest how to debug this issue??
Thanks and Regards,
--Piyush Bansal
The information contained in this electronic message (email) and any attachments to this email are intended for the exclusive use of the addressee(s) and access to this email by any one else is unauthorised. The email may contain proprietary, confidential or privileged information or information relating to Reliance Group. If you are not the intended recipient, please notify the sender by telephone, fax, or return email and delete this communication and any attachments thereto, immediately from your computer. Any dissemination, distribution, or copying of this communication and the attachments thereto (in whole or part), in any manner, is strictly prohibited and actionable at law. The recipient acknowledges that emails are susceptible to alteration and their integrity can not be guaranteed and that Company does not guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email.
Hi there,
I have certain queries regarding batch SUBSCRIBE and NOTIFY. I
have a user who has 100 buddies in his buddy list. If any of his buddy
changes his/her presence status, that user gets a NOTIFY message with
presence status of all the 100 buddies.
In that case, the message size is exceeding 500 KB. Thats quite a
higher value for a UDP packet.
Can anybody suggest-
1. If there is any way to restrict the size of the packet.
2. How to ensure that the packet is received correctly by the client.
Thanks and Regards,
--Piyush Bansal
The information contained in this electronic message (email) and any attachments to this email are intended for the exclusive use of the addressee(s) and access to this email by any one else is unauthorised. The email may contain proprietary, confidential or privileged information or information relating to Reliance Group. If you are not the intended recipient, please notify the sender by telephone, fax, or return email and delete this communication and any attachments thereto, immediately from your computer. Any dissemination, distribution, or copying of this communication and the attachments thereto (in whole or part), in any manner, is strictly prohibited and actionable at law. The recipient acknowledges that emails are susceptible to alteration and their integrity can not be guaranteed and that Company does not guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email.
Hi there,
I have certain queries regarding batch SUBSCRIBE and NOTIFY. I
have a user who has 100 buddies in his buddy list. If any of his buddy
changes his/her presence status, that user gets a NOTIFY message with
presence status of all the 100 buddies.
In that case, the message size is exceeding 500 KB. Thats quite a
higher value for a UDP packet.
Can anybody suggest-
1. If there is any way to restrict the size of the packet.
2. How to ensure that the packet is received correctly by the client.
Thanks and Regards,
--Piyush Bansal
The information contained in this electronic message (email) and any attachments to this email are intended for the exclusive use of the addressee(s) and access to this email by any one else is unauthorised. The email may contain proprietary, confidential or privileged information or information relating to Reliance Group. If you are not the intended recipient, please notify the sender by telephone, fax, or return email and delete this communication and any attachments thereto, immediately from your computer. Any dissemination, distribution, or copying of this communication and the attachments thereto (in whole or part), in any manner, is strictly prohibited and actionable at law. The recipient acknowledges that emails are susceptible to alteration and their integrity can not be guaranteed and that Company does not guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email.
HI there,
I have few queries regarding data deletion from database tables-
1. Once the timer of REGISTER expires, the entry for that user is not
getting deleted from "location" table.
2. Same thing is happening with SUBSCRIBER timer expiry. The entries from
presence tables are not getting deleted.
Please suggest how to debug this issue??
Thanks and Regards,
--Piyush Bansal
The information contained in this electronic message (email) and any attachments to this email are intended for the exclusive use of the addressee(s) and access to this email by any one else is unauthorised. The email may contain proprietary, confidential or privileged information or information relating to Reliance Group. If you are not the intended recipient, please notify the sender by telephone, fax, or return email and delete this communication and any attachments thereto, immediately from your computer. Any dissemination, distribution, or copying of this communication and the attachments thereto (in whole or part), in any manner, is strictly prohibited and actionable at law. The recipient acknowledges that emails are susceptible to alteration and their integrity can not be guaranteed and that Company does not guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email.
