Handling DHCP in Mobicents/Tomcat

[Vladimir Vysotsky]

Hi,

this may be covered in the documentation somewhere, but I can't easily find the answer. Mobicents requires the IP address of the SIP listener to be listed in server.xml (when running under Tomcat). This works fine if the IP is static. What would be the easiest way to handle the case when the IP address assigned through DHCP changes while a Mobicents/Tomcat server is running?

Thanks for any pointers,
Vlad Vysotsky

[Amit Bhayani]

I don't think JSIP stack handles this. AFAIK, the IP has to remain the static.

[Jean Deruelle]

Indeed JSIP doesn't allow that.

AFAIK Tomcat and JBoss neither, once it is bound to an IP, you're stuck with it, but not 100% sure here.

If we could get a notification that the IP Address has changed somehow in java, I guess what would be possible is to remove the old listening point and add a new one.

Why do you need this at runtime ? you can use 0.0.0.0 if you don't need it at runtime.

Jean

[Vladimir Vysotsky]

Thanks for the comments, Amit and Jean. Yes, I would like to support DHCP if it's not too hard. We're building a multicomponent system with C++ components that already handle DHCP and multihomed configurations, and a Java component that's based on Tomcat + Mobicents SIP Servlets, so I'm trying to explore the possibility of supporting dynamic IP addresses and multihoming on both sides.

Detecting IP address changes is a separate problem, let's suppose that it's solved. How do I manage listening points programmatically?

(The solution that we can always try is to have an external monitor daemon that would stop, reconfigure and restart Tomcat when the network configuration changes, but it would be cleaner to learn how to do it from within.)

-=- Vlad

[Jean Deruelle]

Managing listening points would be through done JMX. 

Basically 3 operations :

• getListeningPoints. : This would allow you to query the current list of listening points and check which ones should be updated
• removeListeningPoint: This would allow you to remove the listening point bound to the old DHCP address 
• addListeningPoint : This would allow you to add the listening point bound to the new DHCP address 

This would be done at runtime and should allow you to continue servicing SIP Messages without restarting Tomcat. 

Just thinking out loud here, Please not that you may loose calls that were bound to the old IP Address. (Also this might be circumvented by using a Load Balancer in front of the Tomcat node)

If that would suit your needs please open an issue in our issue tracker (preferrably Customer Support Portal if you have a subscription to JBCP or through our google code issue tracker) so that we can add those methods

Jean

[Vladimir Vysotsky]

Jean - thanks, this is essentially what I would need, so having something like this would be quite helpful. I submitted issue 1019 in the Google issue tracker.

With regard to losing calls and service distruption - I believe that this will be acceptable. For the use cases that I'm concerned about, DHCP address changes will be either infrequent network reconfiguration events, or caused by losing and regaining network connectivity - in either case, some service disruption would be expected. The main reason for handling DHCP would be to reduce the manual configuration overhead.

Of course, any transactions are using, or attempt to use, the listening point that has been removed should fail gracefully, making it possible for the servlet to react and clean up its internal state.

Thanks again for considering this feature addition,
Vlad Vysotsky

[Jean Deruelle]

Can you check the Issue 1019, I added a comment to it and I committed the code that should allow you to do what you want.

Can you try it out and report back to see if that suits your needs ?

Thanks in advance

Best regards

Jean

[Vladimir Vysotsky]

Yes, thank you very much, we're trying to integrate this. I will let you know as soon as we get something working (or not working).

Regards,
Vlad

[Bartosz Baranowski]

Reading this thread makes me feel that Vladimir is doing something akward. I just cant shake off impression that what You desire is hot standby(if service disruption is acceptable) - , not IP take over,just thinking out loud.
DHCP is not desired mechanism to manage FT(unless Im missing something, had not paid attention to AS administration trends) DHCP only gives IP address based on MAC.
IIRC general trend is to use DNS hot standby - if node dies, another one takes over DNS name - hence name is resolved to different IP. jsip default router makes routing deicsion based on DNS, doesnt it?

Lets say we have two tomcat nodes, with two NICs.
 - T_N1, T_N2
 - T2_N1,T2_N2

(I think it should be done like that)
T_N2 and T2_N2 are used for replication of state data.
T_N1 and T2_N1 are used for SIP traffic - based on DNS resolution.

Now - node T fails. DNS server resolves xxx.yyy.com to T2, it takes over all operations.

Am I missing something? Vladimir?

--
Bartosz Baranowski
JBoss R & D
==================================
Word of criticism meant to improve is always step forward.

[Vladimir Vysotsky]

Bartosz,

I'm not sure I completely follow your argument. Judging by your email, you're thinking about a network service with multiple nodes, replication and DNS-based failover.

I am concerned about something that's more like an endpoint, in a sense - non-clustered, no meaningful DNS name, just a little service running unattended on some server box, or maybe even a desktop, in the background, registering with SIP infrastructure to advertise its services. For this use case, DHCP address changes are a fact of life, and I would like the Java code to be able to deal with those.

Chodzi mnie, w gruncie rzeczy, o wielki, zaawansowany SIP klient oparty na MSS + Tomcat (is this correct? My Polish is very rusty.)

-=- Vlad

[Bartosz Baranowski]

On Tue, Nov 10, 2009 at 9:23 AM, Vladimir Vysotsky <tri...@gmail.com> wrote:

Bartosz,

I'm not sure I completely follow your argument. Judging by your email, you're thinking about a network service with multiple nodes, replication and DNS-based failover.

I am concerned about something that's more like an endpoint, in a sense - non-clustered, no meaningful DNS name, just a little service running unattended on some server box, or maybe even a desktop, in the background, registering with SIP infrastructure to advertise its services. For this use case, DHCP address changes are a fact of life, and I would like the Java code to be able to deal with those.

Ok, point taken, thought YOu were trying to build something different.

Chodzi mnie, w gruncie rzeczy, o wielki, zaawansowany SIP klient oparty na MSS + Tomcat (is this correct? My Polish is very rusty.)

:)