Hello, I have a weird issue with Dispatcher module. When I do a ds_list I get some of my destinations returned with flag=P. It appears that when they are in this state, they are not included in the list of destinations to send traffic to.
I have tried restarting Kamailio, and these certain servers always return to flag=P.
I have confirmed the servers are up and running fine. They are communicating without issue at the SIP and network level.
Any idea what could cause this?
Thanks,
As a side note, i have enabled sip tracing on the machines which are being flagged as "P", and no SIP packets are ever arriving. I am positive there is no firewall or other device in the middle which would be stopping the flow of traffic.
On Wed, Mar 3, 2010 at 10:58 PM, Geoffrey Mina geoffreymina@gmail.com wrote:
Hello, I have a weird issue with Dispatcher module. When I do a ds_list I get some of my destinations returned with flag=P. It appears that when they are in this state, they are not included in the list of destinations to send traffic to.
I have tried restarting Kamailio, and these certain servers always return to flag=P.
I have confirmed the servers are up and running fine. They are communicating without issue at the SIP and network level.
Any idea what could cause this?
Thanks,
Hello,
On 03/04/2010 07:33 AM, Geoffrey Mina wrote:
As a side note, i have enabled sip tracing on the machines which are being flagged as "P", and no SIP packets are ever arriving. I am positive there is no firewall or other device in the middle which would be stopping the flow of traffic.
On Wed, Mar 3, 2010 at 10:58 PM, Geoffrey Minageoffreymina@gmail.com wrote:
Hello, I have a weird issue with Dispatcher module. When I do a ds_list I get some of my destinations returned with flag=P. It appears that when they are in this state, they are not included in the list of destinations to send traffic to.
I have tried restarting Kamailio, and these certain servers always return to flag=P.
I have confirmed the servers are up and running fine. They are communicating without issue at the SIP and network level.
Any idea what could cause this?
P is probing mode and destination should go in this state if one call couldn't be routed via it.
Do you see OPTIONS messages sent to those gateways while in P mode?
Cheers, Daniel
No, I am not seeing any options messages. It doesn't appear to be doing anything while in probing mode. How often should an OPTIONS message go out?
One thing to note, i have two public IP addresses on eht0, so I have eht0 and eth0:1. I also have eth1 which is a private network interface. I have nothing specified in the kamailio.cfg "listen", so Kamailio just listens on all IP addresses. I do not believe this happened before I added the 2nd IP to eth0. At that time, i also had explicit listen parameters specifying the internal and external IP addreses. When the configuration was in it's previous state, this never happened.
One additional bit of info, the servers that are in "P" state are on a different public subnet. The servers in "A" state are all in the same public subnet as the Kamailio.
On Thu, Mar 4, 2010 at 11:28 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 03/04/2010 07:33 AM, Geoffrey Mina wrote:
As a side note, i have enabled sip tracing on the machines which are being flagged as "P", and no SIP packets are ever arriving. I am positive there is no firewall or other device in the middle which would be stopping the flow of traffic.
On Wed, Mar 3, 2010 at 10:58 PM, Geoffrey Minageoffreymina@gmail.com wrote:
Hello, I have a weird issue with Dispatcher module. When I do a ds_list I get some of my destinations returned with flag=P. It appears that when they are in this state, they are not included in the list of destinations to send traffic to.
I have tried restarting Kamailio, and these certain servers always return to flag=P.
I have confirmed the servers are up and running fine. They are communicating without issue at the SIP and network level.
Any idea what could cause this?
P is probing mode and destination should go in this state if one call couldn't be routed via it.
Do you see OPTIONS messages sent to those gateways while in P mode?
Cheers, Daniel
-- Daniel-Constantin Mierla Kamailio SIP Router Masterclass, Berlin, March 22-26, 2010
Hello,
On 03/05/2010 12:33 AM, Geoffrey Mina wrote:
No, I am not seeing any options messages. It doesn't appear to be doing anything while in probing mode. How often should an OPTIONS message go out?
One thing to note, i have two public IP addresses on eht0, so I have eht0 and eth0:1. I also have eth1 which is a private network interface. I have nothing specified in the kamailio.cfg "listen", so Kamailio just listens on all IP addresses. I do not believe this happened before I added the 2nd IP to eth0. At that time, i also had explicit listen parameters specifying the internal and external IP addreses. When the configuration was in it's previous state, this never happened.
One additional bit of info, the servers that are in "P" state are on a different public subnet. The servers in "A" state are all in the same public subnet as the Kamailio.
do you have mhomed turned on? http://www.kamailio.org/dokuwiki/doku.php/core-cookbook:3.0.x#mhomed
You need it if there is no routing bridging between the two IP interfaces.
Cheers, Daniel
On Thu, Mar 4, 2010 at 11:28 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 03/04/2010 07:33 AM, Geoffrey Mina wrote:
As a side note, i have enabled sip tracing on the machines which are being flagged as "P", and no SIP packets are ever arriving. I am positive there is no firewall or other device in the middle which would be stopping the flow of traffic.
On Wed, Mar 3, 2010 at 10:58 PM, Geoffrey Minageoffreymina@gmail.com wrote:
Hello, I have a weird issue with Dispatcher module. When I do a ds_list I get some of my destinations returned with flag=P. It appears that when they are in this state, they are not included in the list of destinations to send traffic to.
I have tried restarting Kamailio, and these certain servers always return to flag=P.
I have confirmed the servers are up and running fine. They are communicating without issue at the SIP and network level.
Any idea what could cause this?
P is probing mode and destination should go in this state if one call couldn't be routed via it.
Do you see OPTIONS messages sent to those gateways while in P mode?
Cheers, Daniel
-- Daniel-Constantin Mierla Kamailio SIP Router Masterclass, Berlin, March 22-26, 2010
So why would not having any listen= parameters cause this to become a problem? I am guessing that is the problem... Also, I am a little concerned about the mhomed parameter, specifically this statement: "By default is off (0) - it is rather time consuming."
Also, why wouldn't Kamailio just be forwarding the request on the socket which received the incoming request? That would work fine as it's being received on the public IP and I want the forwarding to be sent on the public IP.
Do you think adding back explicit listen="X.X.X.X:5060" properties on my server would fix the issue?
On Fri, Mar 5, 2010 at 5:28 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 03/05/2010 12:33 AM, Geoffrey Mina wrote:
No, I am not seeing any options messages. It doesn't appear to be doing anything while in probing mode. How often should an OPTIONS message go out?
One thing to note, i have two public IP addresses on eht0, so I have eht0 and eth0:1. I also have eth1 which is a private network interface. I have nothing specified in the kamailio.cfg "listen", so Kamailio just listens on all IP addresses. I do not believe this happened before I added the 2nd IP to eth0. At that time, i also had explicit listen parameters specifying the internal and external IP addreses. When the configuration was in it's previous state, this never happened.
One additional bit of info, the servers that are in "P" state are on a different public subnet. The servers in "A" state are all in the same public subnet as the Kamailio.
do you have mhomed turned on? http://www.kamailio.org/dokuwiki/doku.php/core-cookbook:3.0.x#mhomed
You need it if there is no routing bridging between the two IP interfaces.
Cheers, Daniel
On Thu, Mar 4, 2010 at 11:28 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 03/04/2010 07:33 AM, Geoffrey Mina wrote:
As a side note, i have enabled sip tracing on the machines which are being flagged as "P", and no SIP packets are ever arriving. I am positive there is no firewall or other device in the middle which would be stopping the flow of traffic.
On Wed, Mar 3, 2010 at 10:58 PM, Geoffrey Minageoffreymina@gmail.com wrote:
Hello, I have a weird issue with Dispatcher module. When I do a ds_list I get some of my destinations returned with flag=P. It appears that when they are in this state, they are not included in the list of destinations to send traffic to.
I have tried restarting Kamailio, and these certain servers always return to flag=P.
I have confirmed the servers are up and running fine. They are communicating without issue at the SIP and network level.
Any idea what could cause this?
P is probing mode and destination should go in this state if one call couldn't be routed via it.
Do you see OPTIONS messages sent to those gateways while in P mode?
Cheers, Daniel
-- Daniel-Constantin Mierla Kamailio SIP Router Masterclass, Berlin, March 22-26, 2010
-- Daniel-Constantin Mierla Kamailio SIP Router Masterclass, Berlin, March 22-26, 2010
On Friday 05 March 2010, Geoffrey Mina wrote:
So why would not having any listen= parameters cause this to become a problem? I am guessing that is the problem... Also, I am a little concerned about the mhomed parameter, specifically this statement: "By default is off (0) - it is rather time consuming."
Hi Geoffrey,
this is a bit outdated, Marius did recently here some optimisations, so the performance impact should be much smaller in 1.5.4 and upcoming 3.1. We'll fix the documentation.
Also, why wouldn't Kamailio just be forwarding the request on the socket which received the incoming request? That would work fine as it's being received on the public IP and I want the forwarding to be sent on the public IP.
Normally kamailio should work this way, if you not use mhomed mode or force the send socket in the cfg.
Cheers,
Henning
Well, just for kicks, i added the
listen=208.X.X.X:5060 listen=208.X.X.X:5060 listen=10.3.200.202:5060
Into my config to explicitly listen on my three IP addresses... and magically everything started working again.
Should I file this as a bug, or is there something I'm missing here and this was really a 'feature' and not a 'bug'? :)
Either way, my problem is resolved now. Thanks everyone (especially Daniel, helpful as usual!)
On Fri, Mar 5, 2010 at 8:54 AM, Henning Westerholt henning.westerholt@1und1.de wrote:
On Friday 05 March 2010, Geoffrey Mina wrote:
So why would not having any listen= parameters cause this to become a problem? I am guessing that is the problem... Also, I am a little concerned about the mhomed parameter, specifically this statement: "By default is off (0) - it is rather time consuming."
Hi Geoffrey,
this is a bit outdated, Marius did recently here some optimisations, so the performance impact should be much smaller in 1.5.4 and upcoming 3.1. We'll fix the documentation.
Also, why wouldn't Kamailio just be forwarding the request on the socket which received the incoming request? That would work fine as it's being received on the public IP and I want the forwarding to be sent on the public IP.
Normally kamailio should work this way, if you not use mhomed mode or force the send socket in the cfg.
Cheers,
Henning
Hello Geoffrey,
On 03/05/2010 03:16 PM, Geoffrey Mina wrote:
Well, just for kicks, i added the
listen=208.X.X.X:5060 listen=208.X.X.X:5060 listen=10.3.200.202:5060
Into my config to explicitly listen on my three IP addresses... and magically everything started working again.
interesting. This one needs to be investigated a bit. I see no difference in specifying the list of sockets manually or being built from the system by auto-discovery.
Please fill an issue on sip-router.org tracker: http://sip-router.org/tracker/
Thanks, Daniel
Should I file this as a bug, or is there something I'm missing here and this was really a 'feature' and not a 'bug'? :)
Either way, my problem is resolved now. Thanks everyone (especially Daniel, helpful as usual!)
On Fri, Mar 5, 2010 at 8:54 AM, Henning Westerholt henning.westerholt@1und1.de wrote:
On Friday 05 March 2010, Geoffrey Mina wrote:
So why would not having any listen= parameters cause this to become a problem? I am guessing that is the problem... Also, I am a little concerned about the mhomed parameter, specifically this statement: "By default is off (0) - it is rather time consuming."
Hi Geoffrey,
this is a bit outdated, Marius did recently here some optimisations, so the performance impact should be much smaller in 1.5.4 and upcoming 3.1. We'll fix the documentation.
Also, why wouldn't Kamailio just be forwarding the request on the socket which received the incoming request? That would work fine as it's being received on the public IP and I want the forwarding to be sent on the public IP.
Normally kamailio should work this way, if you not use mhomed mode or force the send socket in the cfg.
Cheers,
Henning
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Issue submitted.
thanks.
On Sun, Mar 7, 2010 at 5:16 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello Geoffrey,
On 03/05/2010 03:16 PM, Geoffrey Mina wrote:
Well, just for kicks, i added the
listen=208.X.X.X:5060 listen=208.X.X.X:5060 listen=10.3.200.202:5060
Into my config to explicitly listen on my three IP addresses... and magically everything started working again.
interesting. This one needs to be investigated a bit. I see no difference in specifying the list of sockets manually or being built from the system by auto-discovery.
Please fill an issue on sip-router.org tracker: http://sip-router.org/tracker/
Thanks, Daniel
Should I file this as a bug, or is there something I'm missing here and this was really a 'feature' and not a 'bug'? :)
Either way, my problem is resolved now. Thanks everyone (especially Daniel, helpful as usual!)
On Fri, Mar 5, 2010 at 8:54 AM, Henning Westerholt henning.westerholt@1und1.de wrote:
On Friday 05 March 2010, Geoffrey Mina wrote:
So why would not having any listen= parameters cause this to become a problem? I am guessing that is the problem... Also, I am a little concerned about the mhomed parameter, specifically this statement: "By default is off (0) - it is rather time consuming."
Hi Geoffrey,
this is a bit outdated, Marius did recently here some optimisations, so the performance impact should be much smaller in 1.5.4 and upcoming 3.1. We'll fix the documentation.
Also, why wouldn't Kamailio just be forwarding the request on the socket which received the incoming request? That would work fine as it's being received on the public IP and I want the forwarding to be sent on the public IP.
Normally kamailio should work this way, if you not use mhomed mode or force the send socket in the cfg.
Cheers,
Henning
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
-- Daniel-Constantin Mierla Kamailio SIP Router Masterclass, Berlin, March 22-26, 2010
-
Daniel-Constantin Mierla -
Geoffrey Mina -
Henning Westerholt