Hello,
I'm testing DMQ_USRLOC modulo between two Kamailio servers (A) and (B)
The two servers share the same domain and using Amazon Route53 to distributes 50% requests each Server.
The problem is when I try to make a call from user A (registered on kamailio A) and the user B (registered on Kamailio B).
The call follow this flow:
User A --> KamailioA --> UserB
go directly to userB because KamailioA know, via DMQ_USRLOC IP and port of UserB. With some Softphone the call work with audio without problem; with other Softphone USERB never answer the INVITE sends from Kamailio. Is it possible use this flow?
USER A --> KamailioA --> KamailioB --> User B
to resolve this kind of problem or is there other available option?
Thank you
On 13 Jul 2021, at 14:46, Social Boh social@bohboh.info wrote:
Hello,
I'm testing DMQ_USRLOC modulo between two Kamailio servers (A) and (B)
The two servers share the same domain and using Amazon Route53 to distributes 50% requests each Server.
The problem is when I try to make a call from user A (registered on kamailio A) and the user B (registered on Kamailio B).
The call follow this flow:
User A --> KamailioA --> UserB
go directly to userB because KamailioA know, via DMQ_USRLOC IP and port of UserB. With some Softphone the call work with audio without problem; with other Softphone USERB never answer the INVITE sends from Kamailio. Is it possible use this flow?
USER A --> KamailioA --> KamailioB --> User B
to resolve this kind of problem or is there other available option?
If the softphone is behind NAT it has a relation to one IP address in the NAT. You need to send the INVITE from that IP and no other IP in order to reach the device. Even without NAT, many devices just don’t respond to messages from unknown IP addresses.
/O
Thank you Olle to take time to answer my question.
So the solution is send the INVITE from the same Kamailio where the device registered.
The question now is: How Can I do that taking advantage of DMQ_USRLOC module?
Thank you
Regards
--- I'm SoCIaL, MayBe
El 13/07/2021 a las 8:04 a. m., Olle E. Johansson escribió:
On 13 Jul 2021, at 14:46, Social Boh social@bohboh.info wrote:
Hello,
I'm testing DMQ_USRLOC modulo between two Kamailio servers (A) and (B)
The two servers share the same domain and using Amazon Route53 to distributes 50% requests each Server.
The problem is when I try to make a call from user A (registered on kamailio A) and the user B (registered on Kamailio B).
The call follow this flow:
User A --> KamailioA --> UserB
go directly to userB because KamailioA know, via DMQ_USRLOC IP and port of UserB. With some Softphone the call work with audio without problem; with other Softphone USERB never answer the INVITE sends from Kamailio. Is it possible use this flow?
USER A --> KamailioA --> KamailioB --> User B
to resolve this kind of problem or is there other available option?
If the softphone is behind NAT it has a relation to one IP address in the NAT. You need to send the INVITE from that IP and no other IP in order to reach the device. Even without NAT, many devices just don’t respond to messages from unknown IP addresses.
/O __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Yes, you need the Path module and special logic for lateral routing of requests received from A and transiting through a Path hop of B.
— Sent from mobile, with due apologies for brevity and errors.
On Jul 13, 2021, at 8:47 AM, Social Boh social@bohboh.info wrote:
Hello,
I'm testing DMQ_USRLOC modulo between two Kamailio servers (A) and (B)
The two servers share the same domain and using Amazon Route53 to distributes 50% requests each Server.
The problem is when I try to make a call from user A (registered on kamailio A) and the user B (registered on Kamailio B).
The call follow this flow:
User A --> KamailioA --> UserB
go directly to userB because KamailioA know, via DMQ_USRLOC IP and port of UserB. With some Softphone the call work with audio without problem; with other Softphone USERB never answer the INVITE sends from Kamailio. Is it possible use this flow?
USER A --> KamailioA --> KamailioB --> User B
to resolve this kind of problem or is there other available option?
Thank you
--
I'm SoCIaL, MayBe
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
If I have to use Path or other solution, which is the main idea behind the DMQ_USRLOC module?
Regards
--- I'm SoCIaL, MayBe
El 13/07/2021 a las 8:36 a. m., Alex Balashov escribió:
Yes, you need the Path module and special logic for lateral routing of requests received from A and transiting through a Path hop of B.
— Sent from mobile, with due apologies for brevity and errors.
On Jul 13, 2021, at 8:47 AM, Social Boh social@bohboh.info wrote:
Hello,
I'm testing DMQ_USRLOC modulo between two Kamailio servers (A) and (B)
The two servers share the same domain and using Amazon Route53 to distributes 50% requests each Server.
The problem is when I try to make a call from user A (registered on kamailio A) and the user B (registered on Kamailio B).
The call follow this flow:
User A --> KamailioA --> UserB
go directly to userB because KamailioA know, via DMQ_USRLOC IP and port of UserB. With some Softphone the call work with audio without problem; with other Softphone USERB never answer the INVITE sends from Kamailio. Is it possible use this flow?
USER A --> KamailioA --> KamailioB --> User B
to resolve this kind of problem or is there other available option?
Thank you
--
I'm SoCIaL, MayBe
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
To replicate knowledge of the registration contact bindings automatically.
It doesn’t provide magic routing to reach them. It just shares the knowledge. :-)
— Sent from mobile, with due apologies for brevity and errors.
On Jul 13, 2021, at 9:46 AM, Social Boh social@bohboh.info wrote:
If I have to use Path or other solution, which is the main idea behind the DMQ_USRLOC module?
Regards
I'm SoCIaL, MayBe
El 13/07/2021 a las 8:36 a. m., Alex Balashov escribió: Yes, you need the Path module and special logic for lateral routing of requests received from A and transiting through a Path hop of B.
— Sent from mobile, with due apologies for brevity and errors.
On Jul 13, 2021, at 8:47 AM, Social Boh social@bohboh.info wrote:
Hello,
I'm testing DMQ_USRLOC modulo between two Kamailio servers (A) and (B)
The two servers share the same domain and using Amazon Route53 to distributes 50% requests each Server.
The problem is when I try to make a call from user A (registered on kamailio A) and the user B (registered on Kamailio B).
The call follow this flow:
User A --> KamailioA --> UserB
go directly to userB because KamailioA know, via DMQ_USRLOC IP and port of UserB. With some Softphone the call work with audio without problem; with other Softphone USERB never answer the INVITE sends from Kamailio. Is it possible use this flow?
USER A --> KamailioA --> KamailioB --> User B
to resolve this kind of problem or is there other available option?
Thank you
--
I'm SoCIaL, MayBe
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Hello,
If I have to use path protocol or other routing logic to share REGISTER between the Two Kamailio so I can call From USERA on KamailioA to USERB on KamailioB, I think I don't need to still use DMQ_USRLOC module.
Can you offer a practical use of this module, please?
Thank you
Regards
--- I'm SoCIaL, MayBe
El 13/07/2021 a las 9:01 a. m., Alex Balashov escribió:
To replicate knowledge of the registration contact bindings automatically.
It doesn’t provide magic routing to reach them. It just shares the knowledge. :-)
— Sent from mobile, with due apologies for brevity and errors.
On Jul 13, 2021, at 9:46 AM, Social Boh social@bohboh.info wrote:
If I have to use Path or other solution, which is the main idea behind the DMQ_USRLOC module?
Regards
I'm SoCIaL, MayBe
El 13/07/2021 a las 8:36 a. m., Alex Balashov escribió: Yes, you need the Path module and special logic for lateral routing of requests received from A and transiting through a Path hop of B.
— Sent from mobile, with due apologies for brevity and errors.
On Jul 13, 2021, at 8:47 AM, Social Boh social@bohboh.info wrote:
Hello,
I'm testing DMQ_USRLOC modulo between two Kamailio servers (A) and (B)
The two servers share the same domain and using Amazon Route53 to distributes 50% requests each Server.
The problem is when I try to make a call from user A (registered on kamailio A) and the user B (registered on Kamailio B).
The call follow this flow:
User A --> KamailioA --> UserB
go directly to userB because KamailioA know, via DMQ_USRLOC IP and port of UserB. With some Softphone the call work with audio without problem; with other Softphone USERB never answer the INVITE sends from Kamailio. Is it possible use this flow?
USER A --> KamailioA --> KamailioB --> User B
to resolve this kind of problem or is there other available option?
Thank you
--
I'm SoCIaL, MayBe
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
On 13/07/2021 15:41, Social Boh wrote:
Hello,
If I have to use path protocol or other routing logic to share REGISTER between the Two Kamailio so I can call From USERA on KamailioA to USERB on KamailioB, I think I don't need to still use DMQ_USRLOC module.
Can you offer a practical use of this module, please?
For example, if you had an active/standby kamailio setup with a floating IP managed by e.g. Keepalived then when a failover event occurs, the usrloc is up to date and the failover is completely transparent.
Hope this helps
-Barry Flanagan
Thank you
Regards
I'm SoCIaL, MayBe
El 13/07/2021 a las 9:01 a. m., Alex Balashov escribió:
To replicate knowledge of the registration contact bindings automatically.
It doesn’t provide magic routing to reach them. It just shares the knowledge. :-)
— Sent from mobile, with due apologies for brevity and errors.
On Jul 13, 2021, at 9:46 AM, Social Boh social@bohboh.info wrote:
If I have to use Path or other solution, which is the main idea behind the DMQ_USRLOC module?
Regards
I'm SoCIaL, MayBe
El 13/07/2021 a las 8:36 a. m., Alex Balashov escribió: Yes, you need the Path module and special logic for lateral routing of requests received from A and transiting through a Path hop of B.
— Sent from mobile, with due apologies for brevity and errors.
On Jul 13, 2021, at 8:47 AM, Social Boh social@bohboh.info wrote:
Hello,
I'm testing DMQ_USRLOC modulo between two Kamailio servers (A) and (B)
The two servers share the same domain and using Amazon Route53 to distributes 50% requests each Server.
The problem is when I try to make a call from user A (registered on kamailio A) and the user B (registered on Kamailio B).
The call follow this flow:
User A --> KamailioA --> UserB
go directly to userB because KamailioA know, via DMQ_USRLOC IP and port of UserB. With some Softphone the call work with audio without problem; with other Softphone USERB never answer the INVITE sends from Kamailio. Is it possible use this flow?
USER A --> KamailioA --> KamailioB --> User B
to resolve this kind of problem or is there other available option?
Thank you
--
I'm SoCIaL, MayBe
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Thank you Barry,
I'll try.
Regards
--- I'm SoCIaL, MayBe
El 13/07/2021 a las 9:48 a. m., Barry Flanagan escribió:
On 13/07/2021 15:41, Social Boh wrote:
Hello,
If I have to use path protocol or other routing logic to share REGISTER between the Two Kamailio so I can call From USERA on KamailioA to USERB on KamailioB, I think I don't need to still use DMQ_USRLOC module.
Can you offer a practical use of this module, please?
For example, if you had an active/standby kamailio setup with a floating IP managed by e.g. Keepalived then when a failover event occurs, the usrloc is up to date and the failover is completely transparent.
Hope this helps
-Barry Flanagan
Thank you
Regards
I'm SoCIaL, MayBe
El 13/07/2021 a las 9:01 a. m., Alex Balashov escribió:
To replicate knowledge of the registration contact bindings automatically.
It doesn’t provide magic routing to reach them. It just shares the knowledge. :-)
— Sent from mobile, with due apologies for brevity and errors.
On Jul 13, 2021, at 9:46 AM, Social Boh social@bohboh.info wrote:
If I have to use Path or other solution, which is the main idea behind the DMQ_USRLOC module?
Regards
I'm SoCIaL, MayBe
El 13/07/2021 a las 8:36 a. m., Alex Balashov escribió: Yes, you need the Path module and special logic for lateral routing of requests received from A and transiting through a Path hop of B.
— Sent from mobile, with due apologies for brevity and errors.
> On Jul 13, 2021, at 8:47 AM, Social Boh social@bohboh.info wrote: Hello,
I'm testing DMQ_USRLOC modulo between two Kamailio servers (A) and (B)
The two servers share the same domain and using Amazon Route53 to distributes 50% requests each Server.
The problem is when I try to make a call from user A (registered on kamailio A) and the user B (registered on Kamailio B).
The call follow this flow:
User A --> KamailioA --> UserB
go directly to userB because KamailioA know, via DMQ_USRLOC IP and port of UserB. With some Softphone the call work with audio without problem; with other Softphone USERB never answer the INVITE sends from Kamailio. Is it possible use this flow?
USER A --> KamailioA --> KamailioB --> User B
to resolve this kind of problem or is there other available option?
Thank you
--
I'm SoCIaL, MayBe
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hello,
in an active/stanby kamailio setup with keepalived I'm using Database replication primary/primary so I don't need DMQ_USRLOC
I'm testing just now and when active kamailio go down, I can make calls between extensions without connection problems with the stanby kamailio.
So my question is: where I "NEED" to use DMQ_USRLOC?
Regards
--- I'm SoCIaL, MayBe
El 13/07/2021 a las 9:48 a. m., Barry Flanagan escribió:
On 13/07/2021 15:41, Social Boh wrote:
Hello,
If I have to use path protocol or other routing logic to share REGISTER between the Two Kamailio so I can call From USERA on KamailioA to USERB on KamailioB, I think I don't need to still use DMQ_USRLOC module.
Can you offer a practical use of this module, please?
For example, if you had an active/standby kamailio setup with a floating IP managed by e.g. Keepalived then when a failover event occurs, the usrloc is up to date and the failover is completely transparent.
Hope this helps
-Barry Flanagan
Thank you
Regards
I'm SoCIaL, MayBe
El 13/07/2021 a las 9:01 a. m., Alex Balashov escribió:
To replicate knowledge of the registration contact bindings automatically.
It doesn’t provide magic routing to reach them. It just shares the knowledge. :-)
— Sent from mobile, with due apologies for brevity and errors.
On Jul 13, 2021, at 9:46 AM, Social Boh social@bohboh.info wrote:
If I have to use Path or other solution, which is the main idea behind the DMQ_USRLOC module?
Regards
I'm SoCIaL, MayBe
El 13/07/2021 a las 8:36 a. m., Alex Balashov escribió: Yes, you need the Path module and special logic for lateral routing of requests received from A and transiting through a Path hop of B.
— Sent from mobile, with due apologies for brevity and errors.
> On Jul 13, 2021, at 8:47 AM, Social Boh social@bohboh.info wrote: Hello,
I'm testing DMQ_USRLOC modulo between two Kamailio servers (A) and (B)
The two servers share the same domain and using Amazon Route53 to distributes 50% requests each Server.
The problem is when I try to make a call from user A (registered on kamailio A) and the user B (registered on Kamailio B).
The call follow this flow:
User A --> KamailioA --> UserB
go directly to userB because KamailioA know, via DMQ_USRLOC IP and port of UserB. With some Softphone the call work with audio without problem; with other Softphone USERB never answer the INVITE sends from Kamailio. Is it possible use this flow?
USER A --> KamailioA --> KamailioB --> User B
to resolve this kind of problem or is there other available option?
Thank you
--
I'm SoCIaL, MayBe
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
No, you don’t need to, but it is a vastly superior replication mechanism to database replication. It was created in order to get around some of the common technical and architectural limitations of the database replication pattern.
— Sent from mobile, with due apologies for brevity and errors.
On Jul 13, 2021, at 4:37 PM, Social Boh social@bohboh.info wrote:
Hello,
in an active/stanby kamailio setup with keepalived I'm using Database replication primary/primary so I don't need DMQ_USRLOC
I'm testing just now and when active kamailio go down, I can make calls between extensions without connection problems with the stanby kamailio.
So my question is: where I "NEED" to use DMQ_USRLOC?
Regards
I'm SoCIaL, MayBe El 13/07/2021 a las 9:48 a. m., Barry Flanagan escribió:
On 13/07/2021 15:41, Social Boh wrote:
Hello,
If I have to use path protocol or other routing logic to share REGISTER between the Two Kamailio so I can call From USERA on KamailioA to USERB on KamailioB, I think I don't need to still use DMQ_USRLOC module.
Can you offer a practical use of this module, please?
For example, if you had an active/standby kamailio setup with a floating IP managed by e.g. Keepalived then when a failover event occurs, the usrloc is up to date and the failover is completely transparent.
Hope this helps
-Barry Flanagan
Thank you
Regards
I'm SoCIaL, MayBe
El 13/07/2021 a las 9:01 a. m., Alex Balashov escribió: To replicate knowledge of the registration contact bindings automatically.
It doesn’t provide magic routing to reach them. It just shares the knowledge. :-)
— Sent from mobile, with due apologies for brevity and errors.
On Jul 13, 2021, at 9:46 AM, Social Boh social@bohboh.info wrote:
If I have to use Path or other solution, which is the main idea behind the DMQ_USRLOC module?
Regards
I'm SoCIaL, MayBe
El 13/07/2021 a las 8:36 a. m., Alex Balashov escribió: Yes, you need the Path module and special logic for lateral routing of requests received from A and transiting through a Path hop of B.
— Sent from mobile, with due apologies for brevity and errors.
>> On Jul 13, 2021, at 8:47 AM, Social Boh social@bohboh.info wrote: > Hello, > > I'm testing DMQ_USRLOC modulo between two Kamailio servers (A) and (B) > > The two servers share the same domain and using Amazon Route53 to distributes 50% requests each Server. > > The problem is when I try to make a call from user A (registered on kamailio A) and the user B (registered on Kamailio B). > > The call follow this flow: > > User A --> KamailioA --> UserB > > go directly to userB because KamailioA know, via DMQ_USRLOC IP and port of UserB. With some Softphone the call work with audio without problem; with other Softphone USERB never answer the INVITE sends from Kamailio. Is it possible use this flow? > > USER A --> KamailioA --> KamailioB --> User B > > to resolve this kind of problem or is there other available option? > > Thank you > > -- > --- > I'm SoCIaL, MayBe > > > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions > * sr-users@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to the sender! > Edit mailing list options or unsubscribe: > * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Hello Alex,
thank you for your answer... now I understand a little bit more.
Thank you
Reagrds
--- I'm SoCIaL, MayBe
El 13/07/2021 a las 3:40 p. m., Alex Balashov escribió:
No, you don’t need to, but it is a vastly superior replication mechanism to database replication. It was created in order to get around some of the common technical and architectural limitations of the database replication pattern.
— Sent from mobile, with due apologies for brevity and errors.
On Jul 13, 2021, at 4:37 PM, Social Boh social@bohboh.info wrote:
Hello,
in an active/stanby kamailio setup with keepalived I'm using Database replication primary/primary so I don't need DMQ_USRLOC
I'm testing just now and when active kamailio go down, I can make calls between extensions without connection problems with the stanby kamailio.
So my question is: where I "NEED" to use DMQ_USRLOC?
Regards
I'm SoCIaL, MayBe El 13/07/2021 a las 9:48 a. m., Barry Flanagan escribió:
On 13/07/2021 15:41, Social Boh wrote:
Hello,
If I have to use path protocol or other routing logic to share REGISTER between the Two Kamailio so I can call From USERA on KamailioA to USERB on KamailioB, I think I don't need to still use DMQ_USRLOC module.
Can you offer a practical use of this module, please?
For example, if you had an active/standby kamailio setup with a floating IP managed by e.g. Keepalived then when a failover event occurs, the usrloc is up to date and the failover is completely transparent.
Hope this helps
-Barry Flanagan
Thank you
Regards
I'm SoCIaL, MayBe
El 13/07/2021 a las 9:01 a. m., Alex Balashov escribió:
To replicate knowledge of the registration contact bindings automatically.
It doesn’t provide magic routing to reach them. It just shares the knowledge. :-)
— Sent from mobile, with due apologies for brevity and errors.
On Jul 13, 2021, at 9:46 AM, Social Boh social@bohboh.info wrote:
If I have to use Path or other solution, which is the main idea behind the DMQ_USRLOC module?
Regards
I'm SoCIaL, MayBe
> El 13/07/2021 a las 8:36 a. m., Alex Balashov escribió: > Yes, you need the Path module and special logic for lateral > routing of requests received from A and transiting through a > Path hop of B. > > — > Sent from mobile, with due apologies for brevity and errors. > >>> On Jul 13, 2021, at 8:47 AM, Social Boh social@bohboh.info >>> wrote: >> Hello, >> >> I'm testing DMQ_USRLOC modulo between two Kamailio servers (A) >> and (B) >> >> The two servers share the same domain and using Amazon Route53 >> to distributes 50% requests each Server. >> >> The problem is when I try to make a call from user A >> (registered on kamailio A) and the user B (registered on >> Kamailio B). >> >> The call follow this flow: >> >> User A --> KamailioA --> UserB >> >> go directly to userB because KamailioA know, via DMQ_USRLOC IP >> and port of UserB. With some Softphone the call work with audio >> without problem; with other Softphone USERB never answer the >> INVITE sends from Kamailio. Is it possible use this flow? >> >> USER A --> KamailioA --> KamailioB --> User B >> >> to resolve this kind of problem or is there other available >> option? >> >> Thank you >> >> -- >> --- >> I'm SoCIaL, MayBe >> >> >> __________________________________________________________ >> Kamailio - Users Mailing List - Non Commercial Discussions >> * sr-users@lists.kamailio.org >> Important: keep the mailing list in the recipients, do not >> reply only to the sender! >> Edit mailing list options or unsubscribe: >> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions > * sr-users@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply > only to the sender! > Edit mailing list options or unsubscribe: > * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Path doesn’t share registrations. It just allows routing from B back through A in order to reach the endpoint, rather than trying to reach the endpoint directly. It’s just a header that says “when contacting this registrant, hop/detour through the original registrant”.
But, Path doesn’t do anything else. So, if you want registrar B to know that the registrant is registered anywhere at all — A or B — and the Contact/URI at which to reach it (whether directly or through a Path hop), you need some means of replicating the registration database. dmq_usrloc provides this aspect.
Path and dmq_usrloc do entirely different things, of different degrees of significance to the overall process. The “heavy” part is done by usrloc/dmq_usrloc.
— Sent from mobile, with due apologies for brevity and errors.
On Jul 13, 2021, at 10:43 AM, Social Boh social@bohboh.info wrote:
Hello,
If I have to use path protocol or other routing logic to share REGISTER between the Two Kamailio so I can call From USERA on KamailioA to USERB on KamailioB, I think I don't need to still use DMQ_USRLOC module.
Can you offer a practical use of this module, please?
Thank you
Regards
I'm SoCIaL, MayBe
El 13/07/2021 a las 9:01 a. m., Alex Balashov escribió: To replicate knowledge of the registration contact bindings automatically.
It doesn’t provide magic routing to reach them. It just shares the knowledge. :-)
— Sent from mobile, with due apologies for brevity and errors.
On Jul 13, 2021, at 9:46 AM, Social Boh social@bohboh.info wrote:
If I have to use Path or other solution, which is the main idea behind the DMQ_USRLOC module?
Regards
I'm SoCIaL, MayBe
El 13/07/2021 a las 8:36 a. m., Alex Balashov escribió: Yes, you need the Path module and special logic for lateral routing of requests received from A and transiting through a Path hop of B.
— Sent from mobile, with due apologies for brevity and errors.
On Jul 13, 2021, at 8:47 AM, Social Boh social@bohboh.info wrote:
Hello,
I'm testing DMQ_USRLOC modulo between two Kamailio servers (A) and (B)
The two servers share the same domain and using Amazon Route53 to distributes 50% requests each Server.
The problem is when I try to make a call from user A (registered on kamailio A) and the user B (registered on Kamailio B).
The call follow this flow:
User A --> KamailioA --> UserB
go directly to userB because KamailioA know, via DMQ_USRLOC IP and port of UserB. With some Softphone the call work with audio without problem; with other Softphone USERB never answer the INVITE sends from Kamailio. Is it possible use this flow?
USER A --> KamailioA --> KamailioB --> User B
to resolve this kind of problem or is there other available option?
Thank you
--
I'm SoCIaL, MayBe
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Sorry,
I explained myself wrong. I know how using PATH and what PATH do.
Thank you
Regards
--- I'm SoCIaL, MayBe
El 13/07/2021 a las 10:02 a. m., Alex Balashov escribió:
Path doesn’t share registrations. It just allows routing from B back through A in order to reach the endpoint, rather than trying to reach the endpoint directly. It’s just a header that says “when contacting this registrant, hop/detour through the original registrant”.
But, Path doesn’t do anything else. So, if you want registrar B to know that the registrant is registered anywhere at all — A or B — and the Contact/URI at which to reach it (whether directly or through a Path hop), you need some means of replicating the registration database. dmq_usrloc provides this aspect.
Path and dmq_usrloc do entirely different things, of different degrees of significance to the overall process. The “heavy” part is done by usrloc/dmq_usrloc.
— Sent from mobile, with due apologies for brevity and errors.
On Jul 13, 2021, at 10:43 AM, Social Boh social@bohboh.info wrote:
Hello,
If I have to use path protocol or other routing logic to share REGISTER between the Two Kamailio so I can call From USERA on KamailioA to USERB on KamailioB, I think I don't need to still use DMQ_USRLOC module.
Can you offer a practical use of this module, please?
Thank you
Regards
I'm SoCIaL, MayBe
El 13/07/2021 a las 9:01 a. m., Alex Balashov escribió: To replicate knowledge of the registration contact bindings automatically.
It doesn’t provide magic routing to reach them. It just shares the knowledge. :-)
— Sent from mobile, with due apologies for brevity and errors.
On Jul 13, 2021, at 9:46 AM, Social Boh social@bohboh.info wrote:
If I have to use Path or other solution, which is the main idea behind the DMQ_USRLOC module?
Regards
I'm SoCIaL, MayBe
El 13/07/2021 a las 8:36 a. m., Alex Balashov escribió: Yes, you need the Path module and special logic for lateral routing of requests received from A and transiting through a Path hop of B.
— Sent from mobile, with due apologies for brevity and errors.
> On Jul 13, 2021, at 8:47 AM, Social Boh social@bohboh.info wrote: Hello,
I'm testing DMQ_USRLOC modulo between two Kamailio servers (A) and (B)
The two servers share the same domain and using Amazon Route53 to distributes 50% requests each Server.
The problem is when I try to make a call from user A (registered on kamailio A) and the user B (registered on Kamailio B).
The call follow this flow:
User A --> KamailioA --> UserB
go directly to userB because KamailioA know, via DMQ_USRLOC IP and port of UserB. With some Softphone the call work with audio without problem; with other Softphone USERB never answer the INVITE sends from Kamailio. Is it possible use this flow?
USER A --> KamailioA --> KamailioB --> User B
to resolve this kind of problem or is there other available option?
Thank you
--
I'm SoCIaL, MayBe
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
On 7/13/21 11:26 AM, Social Boh wrote:
Sorry,
I explained myself wrong. I know how using PATH and what PATH do.
Your question was:
"Is it possible use this flow?
USER A --> KamailioA --> KamailioB --> User B
to resolve this kind of problem or is there other available option?"
And Path is the answer.
-- Alex
I usually put an "edge" proxy (another set of kamailio instances) in front of sip registrars. the edge proxies add the path header, this allows your sip registrars to remain "connectionless" to the UAC. This allows an INVITE to be sent to the UAC from any sip registrar in your cluster, the user location data will have a "path" value which tells which edge proxy to use when trying to reach the UAC.
On Tue, Jul 13, 2021 at 11:32 AM Alex Balashov abalashov@evaristesys.com wrote:
On 7/13/21 11:26 AM, Social Boh wrote:
Sorry,
I explained myself wrong. I know how using PATH and what PATH do.
Your question was:
"Is it possible use this flow?
USER A --> KamailioA --> KamailioB --> User B
to resolve this kind of problem or is there other available option?"
And Path is the answer.
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: