please help
----- Forwarded by Piyush Bansal/RCOM/RelianceADA on 10/10/2013 10:51 AM -----
From: Piyush Bansal/RCOM/RelianceADA To: serusers@iptel.org, serdev@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.
Hi all!
Situation:
Server has two IP's. kamailio binded to IP1, dmq binded to IP2. Everywhere in dmq node listed IP2, of cause. But when message replicated to dmq node, message sended from IP1 and cannot be dispatched as message from dmq node.
modules/dmq/dmq_funcs.c
396: if(tmb.t_replicate(msg, &node->orig_uri) < 0) {
Here used t_replicate from TM module. Message replicated from IP1 of kamailio SIP. But if dmq bind to another IP - IP2.
I think message must send from IP, described in dmq's config: modparam("dmq","server_address", "sip:.....");
Hi,
Interesting - had not considered the multi IP scenario when adding the replicate function. The send/broadcast functions should both work as expected in multi IP setup (although not what you need) - are you able to confirm this is the case?
I am travelling so it may be a little longer than usual, but I will try to take a look over the next day or so.
Regards,
Charles On 9 Oct 2014 15:32, "Victor V. Kustov" coyote@bks.tv wrote:
Hi all!
Situation:
Server has two IP's. kamailio binded to IP1, dmq binded to IP2. Everywhere in dmq node listed IP2, of cause. But when message replicated to dmq node, message sended from IP1 and cannot be dispatched as message from dmq node.
modules/dmq/dmq_funcs.c
396: if(tmb.t_replicate(msg, &node->orig_uri) < 0) {
Here used t_replicate from TM module. Message replicated from IP1 of kamailio SIP. But if dmq bind to another IP - IP2.
I think message must send from IP, described in dmq's config: modparam("dmq","server_address", "sip:.....");
-- Best regard,
JID: coyote@bks.tv JID: coyote@bryansktel.ru I use FREE operation system: 3.15.9- GNU/Linux up 1 day, 4 hours, 7 minutes
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hi, Charles
Main problem - usage t_replicate from TM module. All TM funcs operate with main kamailio interface and socket, but DMQ interfaces and sockets needed.
-- WBR, Victor JID: coyote@bks.tv JID: coyote@bryansktel.ru
Hi Victor,
Have not had chance to test but can you try with the following small patch (against master):
diff --git a/modules/dmq/dmq_funcs.c b/modules/dmq/dmq_funcs.c index 3c9c8c3..331591f 100644 --- a/modules/dmq/dmq_funcs.c +++ b/modules/dmq/dmq_funcs.c @@ -370,6 +370,7 @@ error: int cfg_dmq_t_replicate(struct sip_msg* msg, char* s) { dmq_node_t* node; + struct socket_info* sock; int i = 0;
/* avoid loops - do not replicate if message has come from another node @@ -381,6 +382,11 @@ int cfg_dmq_t_replicate(struct sip_msg* msg, char* s) return -1; }
+ sock = lookup_local_socket(&dmq_server_socket); + if (sock) { + set_force_socket(msg, sock); + } + lock_get(&node_list->lock); node = node_list->nodes; while(node) {
Cheers,
Charles
On 13 October 2014 14:05, Victor V. Kustov coyote@bks.tv wrote:
Hi, Charles
Main problem - usage t_replicate from TM module. All TM funcs operate with main kamailio interface and socket, but DMQ interfaces and sockets needed.
-- WBR, Victor JID: coyote@bks.tv JID: coyote@bryansktel.ru
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hi Victor,
I have now tested with Kamailio/DMQ listening on separate IPs and the added forcing of send socket appears to address the broken logic you describe.
So I will commit the change shortly, unless you can see any problem with the proposed solution?
Best regards,
Charles
On 13 October 2014 23:04, Charles Chance charles.chance@sipcentric.com wrote:
Hi Victor,
Have not had chance to test but can you try with the following small patch (against master):
diff --git a/modules/dmq/dmq_funcs.c b/modules/dmq/dmq_funcs.c index 3c9c8c3..331591f 100644 --- a/modules/dmq/dmq_funcs.c +++ b/modules/dmq/dmq_funcs.c @@ -370,6 +370,7 @@ error: int cfg_dmq_t_replicate(struct sip_msg* msg, char* s) { dmq_node_t* node;
struct socket_info* sock; int i = 0; /* avoid loops - do not replicate if message has come from anothernode @@ -381,6 +382,11 @@ int cfg_dmq_t_replicate(struct sip_msg* msg, char* s) return -1; }
sock = lookup_local_socket(&dmq_server_socket);if (sock) {set_force_socket(msg, sock);}lock_get(&node_list->lock); node = node_list->nodes; while(node) {Cheers,
Charles
On 13 October 2014 14:05, Victor V. Kustov coyote@bks.tv wrote:
Hi, Charles
Main problem - usage t_replicate from TM module. All TM funcs operate with main kamailio interface and socket, but DMQ interfaces and sockets needed.
-- WBR, Victor JID: coyote@bks.tv JID: coyote@bryansktel.ru
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hello,
one thing I wanted to add -- it may be good to backup the old value of the sock and restore it later.
I am not sure if this is used in a context of a request that is going to be forwarded as well to some other address. If yes, then perhaps is it safer to backup and restore initial socket value.
Perhaps it needs to check if the transaction exists and if not, create it first via tm api, then set the new socket for message and call the t_replicate function, not to get the dmq server socket in tm.
Cheers, Daniel
On 15/10/14 15:41, Charles Chance wrote:
Hi Victor,
I have now tested with Kamailio/DMQ listening on separate IPs and the added forcing of send socket appears to address the broken logic you describe.
So I will commit the change shortly, unless you can see any problem with the proposed solution?
Best regards,
Charles
On 13 October 2014 23:04, Charles Chance <charles.chance@sipcentric.com mailto:charles.chance@sipcentric.com> wrote:
Hi Victor, Have not had chance to test but can you try with the following small patch (against master): diff --git a/modules/dmq/dmq_funcs.c b/modules/dmq/dmq_funcs.c index 3c9c8c3..331591f 100644 --- a/modules/dmq/dmq_funcs.c +++ b/modules/dmq/dmq_funcs.c @@ -370,6 +370,7 @@ error: int cfg_dmq_t_replicate(struct sip_msg* msg, char* s) { dmq_node_t* node; + struct socket_info* sock; int i = 0; /* avoid loops - do not replicate if message has come from another node @@ -381,6 +382,11 @@ int cfg_dmq_t_replicate(struct sip_msg* msg, char* s) return -1; } + sock = lookup_local_socket(&dmq_server_socket); + if (sock) { + set_force_socket(msg, sock); + } + lock_get(&node_list->lock); node = node_list->nodes; while(node) { Cheers, Charles On 13 October 2014 14:05, Victor V. Kustov <coyote@bks.tv <mailto:coyote@bks.tv>> wrote: Hi, Charles Main problem - usage t_replicate from TM module. All TM funcs operate with main kamailio interface and socket, but DMQ interfaces and sockets needed. -- WBR, Victor JID: coyote@bks.tv <mailto:coyote@bks.tv> JID: coyote@bryansktel.ru <mailto:coyote@bryansktel.ru> _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-devwww.sipcentric.com http://www.sipcentric.com/
Follow us on twitter @sipcentric http://twitter.com/sipcentric
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hi Daniel,
On 15 October 2014 14:51, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
one thing I wanted to add -- it may be good to backup the old value of the sock and restore it later.
Thanks - I had that in mind already.
I am not sure if this is used in a context of a request that is going to be forwarded as well to some other address. If yes, then perhaps is it safer to backup and restore initial socket value.
Perhaps it needs to check if the transaction exists and if not, create it first via tm api, then set the new socket for message and call the t_replicate function, not to get the dmq server socket in tm.
Sorry, I don't fully understand the last part?
Best regards
Charles
Cheers,
Daniel
On 15/10/14 15:41, Charles Chance wrote:
Hi Victor,
I have now tested with Kamailio/DMQ listening on separate IPs and the added forcing of send socket appears to address the broken logic you describe.
So I will commit the change shortly, unless you can see any problem with the proposed solution?
Best regards,
Charles
On 13 October 2014 23:04, Charles Chance charles.chance@sipcentric.com wrote:
Hi Victor,
Have not had chance to test but can you try with the following small patch (against master):
diff --git a/modules/dmq/dmq_funcs.c b/modules/dmq/dmq_funcs.c index 3c9c8c3..331591f 100644 --- a/modules/dmq/dmq_funcs.c +++ b/modules/dmq/dmq_funcs.c @@ -370,6 +370,7 @@ error: int cfg_dmq_t_replicate(struct sip_msg* msg, char* s) { dmq_node_t* node;
struct socket_info* sock; int i = 0; /* avoid loops - do not replicate if message has come fromanother node @@ -381,6 +382,11 @@ int cfg_dmq_t_replicate(struct sip_msg* msg, char* s) return -1; }
sock = lookup_local_socket(&dmq_server_socket);if (sock) {set_force_socket(msg, sock);}lock_get(&node_list->lock); node = node_list->nodes; while(node) {Cheers,
Charles
On 13 October 2014 14:05, Victor V. Kustov coyote@bks.tv wrote:
Hi, Charles
Main problem - usage t_replicate from TM module. All TM funcs operate with main kamailio interface and socket, but DMQ interfaces and sockets needed.
-- WBR, Victor JID: coyote@bks.tv JID: coyote@bryansktel.ru
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
www.sipcentric.com
Follow us on twitter @sipcentric http://twitter.com/sipcentric
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.
sr-dev mailing listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hello,
On 15/10/14 20:36, Charles Chance wrote:
Hi Daniel,
On 15 October 2014 14:51, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello, one thing I wanted to add -- it may be good to backup the old value of the sock and restore it later.Thanks - I had that in mind already.
I am not sure if this is used in a context of a request that is going to be forwarded as well to some other address. If yes, then perhaps is it safer to backup and restore initial socket value. Perhaps it needs to check if the transaction exists and if not, create it first via tm api, then set the new socket for message and call the t_replicate function, not to get the dmq server socket in tm.Sorry, I don't fully understand the last part?
t_replicate() create the transaction for the respective requests (if the transaction doesn't exist already). Creation of the transaction involves cloning to shared memory the sip_msg_t structure. If you update the forced socket to dmq server address for the request, it gets in shared memory with the new value, which may be wrong for further processing of the message in branch/failure routes.
My suggestion is to check if transaction exists and if not, first create it and then backup socket, update it for dmq address, do the replication and restore the socket from backup (note that the dmq the function will still use the sip_msg_t from private memory even after creating the transaction).
Cheers, Daniel
Hi Daniel,
Perfect, thank you - now I understand.
Cheers, Charles On 15 Oct 2014 21:11, "Daniel-Constantin Mierla" miconda@gmail.com wrote:
Hello,
On 15/10/14 20:36, Charles Chance wrote:
Hi Daniel,
On 15 October 2014 14:51, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
one thing I wanted to add -- it may be good to backup the old value of the sock and restore it later.
Thanks - I had that in mind already.
I am not sure if this is used in a context of a request that is going to be forwarded as well to some other address. If yes, then perhaps is it safer to backup and restore initial socket value.
Perhaps it needs to check if the transaction exists and if not, create it first via tm api, then set the new socket for message and call the t_replicate function, not to get the dmq server socket in tm.
Sorry, I don't fully understand the last part?
t_replicate() create the transaction for the respective requests (if the transaction doesn't exist already). Creation of the transaction involves cloning to shared memory the sip_msg_t structure. If you update the forced socket to dmq server address for the request, it gets in shared memory with the new value, which may be wrong for further processing of the message in branch/failure routes.
My suggestion is to check if transaction exists and if not, first create it and then backup socket, update it for dmq address, do the replication and restore the socket from backup (note that the dmq the function will still use the sip_msg_t from private memory even after creating the transaction).
Cheers, Daniel
-- Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Hi Charles, with patch K. work as expected, thank you.
By the way, we test merged 4.3 version with full dmq replication usrloc/dmq with json by Alex Hermann's. After testing dmq replication for K. 4.3 will ready to use.
-- WBR, Victor JID: coyote@bks.tv JID: coyote@bryansktel.ru
-
Charles Chance -
Daniel-Constantin Mierla -
Piyush.Bansal＠relianceada.com -
Victor V. Kustov