Hello
I'd like to explain my scenario and the module I'd like to develop. I am hoping for comments whether there are already modules like that or which modules' API I could use to make the development easier.
Scenario: I have two domains (A and B) with a Kamailio server in each of them configured as presence servers. The agents from both domains want to subscribe to few resources from domain A.
Idea: In order to reduce traffic between the domains, the presence server from domain B shall handle the subscriptions internally and use an internal virtual presence-user-agent to subscribe to the resources in domain A.
SIP Messages:
Subscription: 1) Subscribe resource.domain.a, from each user agent ua_n.domain.b 2) 202 OK from kamailio.domain.b 3) If not already subscribed, Subscribe resource.domain.a from kamailio.domain.b with virtual user-agent 4) 202 OK from kamailio.domain.a
(Repeat for each susbcriber) (Subscription has to be refreshed by an internal timer)
Events: 1) Publish resouce.domain.a to kamailio.domain.a 2) 200 OK from kamailio.domain.a 3) Notify resource.domain.a to kamailio.domain.b 4) 200 OK from kamailio.domain.b 5) Notify resource.domain.a to each user agent ua_n.domain.b 6) 200 OK from each ua_n.domain.b
(Internally, Kamailio of domain B has to forward the incoming Notify to all locally subscribed user-agents)
I tried using the PUA module but it does not fit all my needs. Now I think I will have to develop my own module in order to achieve everything. Any ideas?
Kind regards
MAybe you could implement it with resource lists (RLS module subscribes to domain B if a lists in domain A is subscribed).
But above scenario does not reduce the traffic, as for every subscription to A, a subscription to B is done. This is necessary, as usually you have authorization at B to verify if the the user is allowed to subscribe a resource at B.
regards Klaus
On 22.10.2013 16:24, Jan Gaida wrote:
Hello
I'd like to explain my scenario and the module I'd like to develop. I am hoping for comments whether there are already modules like that or which modules' API I could use to make the development easier.
Scenario: I have two domains (A and B) with a Kamailio server in each of them configured as presence servers. The agents from both domains want to subscribe to few resources from domain A.
Idea: In order to reduce traffic between the domains, the presence server from domain B shall handle the subscriptions internally and use an internal virtual presence-user-agent to subscribe to the resources in domain A.
SIP Messages:
Subscription:
- Subscribe resource.domain.a, from each user agent ua_n.domain.b
- 202 OK from kamailio.domain.b
- If not already subscribed, Subscribe resource.domain.a from
kamailio.domain.b with virtual user-agent 4) 202 OK from kamailio.domain.a
(Repeat for each susbcriber) (Subscription has to be refreshed by an internal timer) Events:
- Publish resouce.domain.a to kamailio.domain.a
- 200 OK from kamailio.domain.a
- Notify resource.domain.a to kamailio.domain.b
- 200 OK from kamailio.domain.b
- Notify resource.domain.a to each user agent ua_n.domain.b
- 200 OK from each ua_n.domain.b
(Internally, Kamailio of domain B has to forward the incoming Notify to all locally subscribed user-agents)
I tried using the PUA module but it does not fit all my needs. Now I think I will have to develop my own module in order to achieve everything. Any ideas?
Kind regards
-- *Jan **Gaida* Ingeniero Desarrollo Software C/ Marconi 3 (PTM) 28760 Tres Cantos Spain jan.gaida@grupoamper.com mailto:jan.gaida@grupoamper.com | www.grupoamper.com http://www.grupoamper.com
This message and any attachments are intended only for the use of the individual to whom they are addressed and it may contain information that is privileged or confidential. If you have received this communication by mistake, please notify us immediately by e-mail or telephone.The storage, recording, use or disclosure of this e-mail and its attachments by anyone other than the intended recipient is strictly prohibited. This message has been verified using antivirus software; however, the sender is not responsible for any damage to hardware or software resulting from the presence of any virus.
Este mensaje y cualquier anexo son exclusivamente para la persona a quien van dirigidos y pueden contener información privilegiada o confidencial. Si usted ha recibido esta comunicación por error, le agradecemos notificarlo de inmediato por esta misma vía o por teléfono. Está prohibida su retención, grabación, utilización o divulgación con cualquier propósito. Este mensaje ha sido verificado con software antivirus; sin embargo, el remitente no se hace responsable en caso de que en éste o en los archivos adjuntos haya presencia de algún virus que pueda generar daños en los equipos o programas del destinatario.
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Thank you very much for your answer, Klaus.
The problem with RLS is (like you said) that it's working with synchronous subscriptions and with asynchronous notifies. But I want to subscribe only once for each resource and then deliver each Notify instantaneously.
Nevertheless, looking at the code of the RLS module has given me new ideas for the implementation of my presence-proxy. I think I can reuse quite a big part of it.
By the way, does anyone know if there is a RFC for a presence proxy like the one I describe?
Kind regards Jan
On Wed, Oct 23, 2013 at 9:36 AM, Klaus Darilion < klaus.mailinglists@pernau.at> wrote:
MAybe you could implement it with resource lists (RLS module subscribes to domain B if a lists in domain A is subscribed).
But above scenario does not reduce the traffic, as for every subscription to A, a subscription to B is done. This is necessary, as usually you have authorization at B to verify if the the user is allowed to subscribe a resource at B.
regards Klaus
On 22.10.2013 16:24, Jan Gaida wrote:
Hello
I'd like to explain my scenario and the module I'd like to develop. I am hoping for comments whether there are already modules like that or which modules' API I could use to make the development easier.
Scenario: I have two domains (A and B) with a Kamailio server in each of them configured as presence servers. The agents from both domains want to subscribe to few resources from domain A.
Idea: In order to reduce traffic between the domains, the presence server from domain B shall handle the subscriptions internally and use an internal virtual presence-user-agent to subscribe to the resources in domain A.
SIP Messages:
Subscription:
- Subscribe resource.domain.a, from each user agent ua_n.domain.b
- 202 OK from kamailio.domain.b
- If not already subscribed, Subscribe resource.domain.a from
kamailio.domain.b with virtual user-agent 4) 202 OK from kamailio.domain.a
(Repeat for each susbcriber) (Subscription has to be refreshed by an internal timer) Events:
- Publish resouce.domain.a to kamailio.domain.a
- 200 OK from kamailio.domain.a
- Notify resource.domain.a to kamailio.domain.b
- 200 OK from kamailio.domain.b
- Notify resource.domain.a to each user agent ua_n.domain.b
- 200 OK from each ua_n.domain.b
(Internally, Kamailio of domain B has to forward the incoming Notify to all locally subscribed user-agents)
I tried using the PUA module but it does not fit all my needs. Now I think I will have to develop my own module in order to achieve everything. Any ideas?
Kind regards
-- *Jan **Gaida* Ingeniero Desarrollo Software C/ Marconi 3 (PTM) 28760 Tres Cantos Spain jan.gaida@grupoamper.com <mailto:jan.gaida@grupoamper.**comjan.gaida@grupoamper.com> | www.grupoamper.com http://www.grupoamper.com
This message and any attachments are intended only for the use of the individual to whom they are addressed and it may contain information that is privileged or confidential. If you have received this communication by mistake, please notify us immediately by e-mail or telephone.The storage, recording, use or disclosure of this e-mail and its attachments by anyone other than the intended recipient is strictly prohibited. This message has been verified using antivirus software; however, the sender is not responsible for any damage to hardware or software resulting from the presence of any virus.
Este mensaje y cualquier anexo son exclusivamente para la persona a quien van dirigidos y pueden contener información privilegiada o confidencial. Si usted ha recibido esta comunicación por error, le agradecemos notificarlo de inmediato por esta misma vía o por teléfono. Está prohibida su retención, grabación, utilización o divulgación con cualquier propósito. Este mensaje ha sido verificado con software antivirus; sin embargo, el remitente no se hace responsable en caso de que en éste o en los archivos adjuntos haya presencia de algún virus que pueda generar daños en los equipos o programas del destinatario.
______________________________**_________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**devhttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
btw: what is the problem with using PUA module?
On 23.10.2013 15:37, Jan Gaida wrote:
Thank you very much for your answer, Klaus.
The problem with RLS is (like you said) that it's working with synchronous subscriptions and with asynchronous notifies. But I want to subscribe only once for each resource and then deliver each Notify instantaneously.
Nevertheless, looking at the code of the RLS module has given me new ideas for the implementation of my presence-proxy. I think I can reuse quite a big part of it.
By the way, does anyone know if there is a RFC for a presence proxy like the one I describe?
Kind regards Jan
On Wed, Oct 23, 2013 at 9:36 AM, Klaus Darilion <klaus.mailinglists@pernau.at mailto:klaus.mailinglists@pernau.at> wrote:
MAybe you could implement it with resource lists (RLS module subscribes to domain B if a lists in domain A is subscribed). But above scenario does not reduce the traffic, as for every subscription to A, a subscription to B is done. This is necessary, as usually you have authorization at B to verify if the the user is allowed to subscribe a resource at B. regards Klaus On 22.10.2013 16:24, Jan Gaida wrote: Hello I'd like to explain my scenario and the module I'd like to develop. I am hoping for comments whether there are already modules like that or which modules' API I could use to make the development easier. Scenario: I have two domains (A and B) with a Kamailio server in each of them configured as presence servers. The agents from both domains want to subscribe to few resources from domain A. Idea: In order to reduce traffic between the domains, the presence server from domain B shall handle the subscriptions internally and use an internal virtual presence-user-agent to subscribe to the resources in domain A. SIP Messages: Subscription: 1) Subscribe resource.domain.a, from each user agent ua_n.domain.b 2) 202 OK from kamailio.domain.b 3) If not already subscribed, Subscribe resource.domain.a from kamailio.domain.b with virtual user-agent 4) 202 OK from kamailio.domain.a (Repeat for each susbcriber) (Subscription has to be refreshed by an internal timer) Events: 1) Publish resouce.domain.a to kamailio.domain.a 2) 200 OK from kamailio.domain.a 3) Notify resource.domain.a to kamailio.domain.b 4) 200 OK from kamailio.domain.b 5) Notify resource.domain.a to each user agent ua_n.domain.b 6) 200 OK from each ua_n.domain.b (Internally, Kamailio of domain B has to forward the incoming Notify to all locally subscribed user-agents) I tried using the PUA module but it does not fit all my needs. Now I think I will have to develop my own module in order to achieve everything. Any ideas? Kind regards -- *Jan **Gaida* Ingeniero Desarrollo Software C/ Marconi 3 (PTM) 28760 Tres Cantos Spain jan.gaida@grupoamper.com <mailto:jan.gaida@grupoamper.com> <mailto:jan.gaida@grupoamper.__com <mailto:jan.gaida@grupoamper.com>> | www.grupoamper.com <http://www.grupoamper.com> <http://www.grupoamper.com> This message and any attachments are intended only for the use of the individual to whom they are addressed and it may contain information that is privileged or confidential. If you have received this communication by mistake, please notify us immediately by e-mail or telephone.The storage, recording, use or disclosure of this e-mail and its attachments by anyone other than the intended recipient is strictly prohibited. This message has been verified using antivirus software; however, the sender is not responsible for any damage to hardware or software resulting from the presence of any virus. Este mensaje y cualquier anexo son exclusivamente para la persona a quien van dirigidos y pueden contener información privilegiada o confidencial. Si usted ha recibido esta comunicación por error, le agradecemos notificarlo de inmediato por esta misma vía o por teléfono. Está prohibida su retención, grabación, utilización o divulgación con cualquier propósito. Este mensaje ha sido verificado con software antivirus; sin embargo, el remitente no se hace responsable en caso de que en éste o en los archivos adjuntos haya presencia de algún virus que pueda generar daños en los equipos o programas del destinatario. _________________________________________________ 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-__dev <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev>-- *Jan **Gaida* Ingeniero Desarrollo Software C/ Marconi 3 (PTM) 28760 Tres Cantos Spain jan.gaida@grupoamper.com mailto:jan.gaida@grupoamper.com | www.grupoamper.com http://www.grupoamper.com
This message and any attachments are intended only for the use of the individual to whom they are addressed and it may contain information that is privileged or confidential. If you have received this communication by mistake, please notify us immediately by e-mail or telephone.The storage, recording, use or disclosure of this e-mail and its attachments by anyone other than the intended recipient is strictly prohibited. This message has been verified using antivirus software; however, the sender is not responsible for any damage to hardware or software resulting from the presence of any virus.
Este mensaje y cualquier anexo son exclusivamente para la persona a quien van dirigidos y pueden contener información privilegiada o confidencial. Si usted ha recibido esta comunicación por error, le agradecemos notificarlo de inmediato por esta misma vía o por teléfono. Está prohibida su retención, grabación, utilización o divulgación con cualquier propósito. Este mensaje ha sido verificado con software antivirus; sin embargo, el remitente no se hace responsable en caso de que en éste o en los archivos adjuntos haya presencia de algún virus que pueda generar daños en los equipos o programas del destinatario.
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
The RLS module uses PUA and Presence module. I think I will do the same. PUA for sending the remote subscribe (+ timer to refresh subscriptions) and Presence for the local subscribes and notifies. I tried using PUA's send_publish for sending an internal publish message so that I could use directly the Presence's handle_publish functions to send the notify to the agents, but I ran into a problem converting the incoming notify message into a publish because I needed the correct If-Match and e-tag headers. And beside that, this would mean two additional messages for each incoming Notify.
Regards
On Thu, Oct 24, 2013 at 10:17 AM, Klaus Darilion < klaus.mailinglists@pernau.at> wrote:
btw: what is the problem with using PUA module?
On 23.10.2013 15:37, Jan Gaida wrote:
Thank you very much for your answer, Klaus.
The problem with RLS is (like you said) that it's working with synchronous subscriptions and with asynchronous notifies. But I want to subscribe only once for each resource and then deliver each Notify instantaneously.
Nevertheless, looking at the code of the RLS module has given me new ideas for the implementation of my presence-proxy. I think I can reuse quite a big part of it.
By the way, does anyone know if there is a RFC for a presence proxy like the one I describe?
Kind regards Jan
On Wed, Oct 23, 2013 at 9:36 AM, Klaus Darilion <klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@**pernau.atklaus.mailinglists@pernau.at>> wrote:
MAybe you could implement it with resource lists (RLS module subscribes to domain B if a lists in domain A is subscribed). But above scenario does not reduce the traffic, as for every subscription to A, a subscription to B is done. This is necessary, as usually you have authorization at B to verify if the the user is allowed to subscribe a resource at B. regards Klaus On 22.10.2013 16:24, Jan Gaida wrote: Hello I'd like to explain my scenario and the module I'd like to develop. I am hoping for comments whether there are already modules like that or which modules' API I could use to make the development easier. Scenario: I have two domains (A and B) with a Kamailio server in each ofthem configured as presence servers. The agents from both domains want to subscribe to few resources from domain A.
Idea: In order to reduce traffic between the domains, the presence server from domain B shall handle the subscriptions internally and use an internal virtual presence-user-agent to subscribe to the resources in domain A. SIP Messages: Subscription: 1) Subscribe resource.domain.a, from each user agent ua_n.domain.b 2) 202 OK from kamailio.domain.b 3) If not already subscribed, Subscribe resource.domain.a from kamailio.domain.b with virtual user-agent 4) 202 OK from kamailio.domain.a (Repeat for each susbcriber) (Subscription has to be refreshed by an internal timer) Events: 1) Publish resouce.domain.a to kamailio.domain.a 2) 200 OK from kamailio.domain.a 3) Notify resource.domain.a to kamailio.domain.b 4) 200 OK from kamailio.domain.b 5) Notify resource.domain.a to each user agent ua_n.domain.b 6) 200 OK from each ua_n.domain.b (Internally, Kamailio of domain B has to forward the incoming Notify to all locally subscribed user-agents) I tried using the PUA module but it does not fit all my needs.Now I think I will have to develop my own module in order to achieve everything. Any ideas?
Kind regards -- *Jan **Gaida* Ingeniero Desarrollo Software C/ Marconi 3 (PTM) 28760 Tres Cantos Spain jan.gaida@grupoamper.com <mailto:jan.gaida@grupoamper.**com<jan.gaida@grupoamper.com><mailto:jan.gaida@grupoamper._**_com <mailto:jan.gaida@grupoamper.**com <jan.gaida@grupoamper.com>>> | www.grupoamper.com <http://www.grupoamper.com> <http://www.grupoamper.com> This message and any attachments are intended only for the use of the individual to whom they are addressed and it may containinformation that is privileged or confidential. If you have received this communication by mistake, please notify us immediately by e-mail or telephone.The storage, recording, use or disclosure of this e-mail and its attachments by anyone other than the intended recipient is strictly prohibited. This message has been verified using antivirus software; however, the sender is not responsible for any damage to hardware or software resulting from the presence of any virus.
Este mensaje y cualquier anexo son exclusivamente para la personaa quien van dirigidos y pueden contener información privilegiada o confidencial. Si usted ha recibido esta comunicación por error, le agradecemos notificarlo de inmediato por esta misma vía o por teléfono. Está prohibida su retención, grabación, utilización o divulgación con cualquier propósito. Este mensaje ha sido verificado con software antivirus; sin embargo, el remitente no se hace responsable en caso de que en éste o en los archivos adjuntos haya presencia de algún virus que pueda generar daños en los equipos o programas del destinatario.
______________________________**___________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-**router.org<sr-dev@lists.sip-router.org>http://lists.sip-router.org/__**cgi-bin/mailman/listinfo/sr-__**dev http://lists.sip-router.org/__cgi-bin/mailman/listinfo/sr-__dev <http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**devhttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- *Jan **Gaida* Ingeniero Desarrollo Software C/ Marconi 3 (PTM) 28760 Tres Cantos Spain jan.gaida@grupoamper.com <mailto:jan.gaida@grupoamper.**comjan.gaida@grupoamper.com> | www.grupoamper.com http://www.grupoamper.com
This message and any attachments are intended only for the use of the individual to whom they are addressed and it may contain information that is privileged or confidential. If you have received this communication by mistake, please notify us immediately by e-mail or telephone.The storage, recording, use or disclosure of this e-mail and its attachments by anyone other than the intended recipient is strictly prohibited. This message has been verified using antivirus software; however, the sender is not responsible for any damage to hardware or software resulting from the presence of any virus.
Este mensaje y cualquier anexo son exclusivamente para la persona a quien van dirigidos y pueden contener información privilegiada o confidencial. Si usted ha recibido esta comunicación por error, le agradecemos notificarlo de inmediato por esta misma vía o por teléfono. Está prohibida su retención, grabación, utilización o divulgación con cualquier propósito. Este mensaje ha sido verificado con software antivirus; sin embargo, el remitente no se hace responsable en caso de que en éste o en los archivos adjuntos haya presencia de algún virus que pueda generar daños en los equipos o programas del destinatario.
______________________________**_________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**devhttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-
Jan Gaida -
Klaus Darilion