sudden call disconnected

[kingston]

1. Brekeke Product Name and version:

Brekeke SIP Server v2.0.7.2/217

2. Java version:

1.5.0_11

3. OS type and the version:

Linux 2.6.9-42.ELsmp

4. UA (phone), gateway or other hardware/software involved:

UA: eyeBeam v1.5.5.1 build 30037
Gateway:
- Radvision N30 SIP Gateway
- Radvision P25M 3G Gateway

5. Select your network pattern from http://www.brekeke-sip.com/bbs/network/ ... terns.html :

Similar to pattern 3 with the following additional network components:

1. Public IP is assigned to eyeBeam. All SIP Requests from UA will be submitted to NAT router first, and then forward it to OSS. NAT router port forwarding information as follow:

- Router's global IP address: 202.xxx.xxx.xxx
- SIP exchanger: UDP 5060
- RTP exchanger: 16384 - 65535

SIP server Interface Addresses:
- Interface address 1: 192.168.99.122
- Interface address 2: 192.168.96.7

2. When the request reached NAT Router, they will be forwarded to SIP Server. Routing path as follow:

Code: Select all

UA <=> NAT Router (202.xxx.xxx.xxx) <=> OSS (192.168.99.122 & 192.168.96.7)

I have assigned Router's global IP, Interface address 1 & 2 to "Configuration > System > Network > Interface address 1, 2, & 3". Also, I have changed the Minimum Port & Maximum Port under "Configuration > System > RTP" to 16384 & 65535 correspondingly;

2. I am using the dial plan in OSS to forward all INVITE requests to N30 SIP-GW. SIP-GW will then forward request to P25M. Finally an outbound call will be made to 3G handset. Both calling & called parties will be joined up together if the call success;

Finally the routing path will be as follow:

Code: Select all

UA (public IP) <=> NAT Router (202.xxx.xxx.xxx) <=> OSS (192.168.99.122 & 192.168.96.7) <=> N30 (192.168.96.4) <=> P25M (192.168.96.3) <=> 3G phone

6. Your problem:

I found no problem in making call from UA to 3G phone. The call was success, and both party can view and listen each other. However, after the call was answered for around 2 minutes. The OSS will suddenly disconnect the call, and no media will be transmitted between two parties. In fact, neither eyeBeam nor 3G handheld did hang up the call. The call-log in OSS indicated the call result was “Disconnected by system”, and the talking-length was 31 seconds. The end users still in conversation when the call was closing. 2 minutes later, the call was completely disconnected, and the active session in OSS ended. The following is the status shown in active-session:

Code: Select all

From (eyebeam): sip:61234567@<Router's global IP> (<eyeBeam’s public IP>:20972)
To (3G): sip:67654321@<Router's global IP> (<N30 SIP-GW IP>)
Time: 2007-03-30 17:06:03.582
Status: Closing

Even though call was ended, the OSS didn’t submit any BYE command to UA. So the call status shown in UA was still established. Since the session no longer existed, both party couldn’t communicate with each other.

I have tried enabling/disabling the “NAT traversal > Keep address/port mapping” but it didn’t help much. The call still dropped after 31 seconds.

Please suggest how I resolve this issue. I will provide you more details for investigation if the above information is not enough.

Thanks a lot.

[voipwell.com]

Hi,

I'm sorry but I'm not clear what the N30 and P25 are and what they are doing in between the internet and your phone. I would put the RTP port range in sip server back to 10000-10999. Make sure your force rtp relay to on in the sip server config. Make sure the router is forwarding ports 5060 and the above port range to sip server. You interface entries in the sip server should be 1) internal lan address, 2) external wan address only. Nat traversal should be ON in the sip server. The Disconnected by the system message sounds like an RTP Session Timeout. Brekeke is trying to send the bye message but it can't get thru because some path is not open. After a while it times out and writes the "disconnected by system".

A word of advice to solve your problem is to isolate it. Try removing devices from the path until your call works properly. You have a Ua with public address going to to a router then to Brekeke. Register a device on the brekeke sip server to complete the call. Then add devices one at a time between brekeke and your phone until it fails to see where the problem is.

Brkeke works very well with nat traversal. The only time it doesn't is when you lan address is numbered with wan ip addresses. That will confuse Brekeke. Although, they have a new configuration string that will now force nat traversal even if you are using wan addresses in your lan. I believe this is available in Version 2.

You could also download wireshark/ethereal to put on the brekeke server to see where the sip messages are having trouble getting thru.

Nick

[kingston]

Dear Nick,

Thank you for your prompt reply. I am so glad you gave me so many suggestions. It does help me a lot to figure out the root caused of the issue.

Please see my comment below:

Hi,

I'm sorry but I'm not clear what the N30 and P25 are and what they are doing in between the internet and your phone.

KingstonN30 is a SIP Gateway & P25M is an ISDN gateway. Using N30 & P25M to achieve connectivity between IP and ISDN networks, i.e. PC => 3G.

I would put the RTP port range in sip server back to 10000-10999. Make sure your force rtp relay to on in the sip server config. Make sure the router is forwarding ports 5060 and the above port range to sip server. You interface entries in the sip server should be 1) internal lan address, 2) external wan address only.

KingstonI have two internal lan addresses in SIP server, i.e. 192.168.96.7 & 192.168.99.122. Should I put only the 192.168.99.122 or I should add both of them plus the Router’s global IP address (202.xxx.xxx.xxx)?

Nat traversal should be ON in the sip server. The Disconnected by the system message sounds like an RTP Session Timeout. Brekeke is trying to send the bye message but it can't get thru because some path is not open. After a while it times out and writes the "disconnected by system".

KingstonAfter I used ethereal to capture the network packets. I found that the OSS (192.168.99.122) submitted a “Status: 200 OK” message to eyebeam UA (public ip). Afterwards eyebeam returned a “Request: ACK sip:<Router's global IP>” back to OSS, and it was successfully delivered to the OSS. But when OSS received this ACK packet, i.e. “Status: 200 OK” from 3G handset (N30-GW, 192.168.96.4), OSS somehow couldn’t properly response with ACK. Instead, it send out an ACK packet as “Request: ACK sip:67654321@<Router's global IP>” back to NAT router (202.xxx.xxx.xxx). And then when NAT router received this ACK, it again forwarded it back to the OSS. So looping occurred.

Code: Select all

1.	OSS (192.168.99.122 lan1) == “Status: 200 OK” ==> eyebeam UA
2.	eyebeam UA == “Request: Ack sip:<Router’s IP>:5060” ==> OSS (192.168.99.122 lan1)
3.	3G N30-GW (192.168.96.4) == “Status: 200 OK” ==> OSS (192.168.96.7 lan2)
4.	OSS (192.168.99.122 lan2) == “Request: Ack sip:67654321@<Router's global IP 202.xxx.xxx.xxx>” ==> NAT Router (202.xxx.xxx.xxx)
5.	NAT Router (202.xxx.xxx.xxx) == “Request: Ack sip:67654321@<Router's global IP 202.xxx.xxx.xxx>” ==> OSS (192.168.99.122)
6.	<keep on repeating the ACK forwarding>

[/color]

A word of advice to solve your problem is to isolate it. Try removing devices from the path until your call works properly. You have a Ua with public address going to to a router then to Brekeke. Register a device on the brekeke sip server to complete the call. Then add devices one at a time between brekeke and your phone until it fails to see where the problem is.

KingstonI found no problem in making direct peer-to-peer call from one eyebeam in public address to another eyebeam UA behind NAT without any IP-ISDN Gateways involve. SO I guess the issue is due to OSS couldn't properly handle the "request: 200 OK" SIP request from Gateway side.

Brkeke works very well with nat traversal. The only time it doesn't is when you lan address is numbered with wan ip addresses. That will confuse Brekeke. Although, they have a new configuration string that will now force nat traversal even if you are using wan addresses in your lan. I believe this is available in Version 2.

You could also download wireshark/ethereal to put on the brekeke server to see where the sip messages are having trouble getting thru.

Nick

[/color]

Could you please give me some advices to resolve this issue? Again, Thanks a lot.

[voipwell.com]

Kingston,

I can not visualize your setup but I am concerned about the two lans you have connected to your brekeke server. Let's eliminate that as a problem by binding Brekeke to the lan you want to use for this problem call and restricting Brekeke from using the other lan address. In your sv.properties file in Program Files\Brekeke\pbx\webapps\proxy\WEB-INF\work\sv directory put the following lines in then reboot the server to make sure they get picked up.

net.net1.interface-restrict=xx.xx.xx.xx (where xx.xx.xx.xx) is the lan address that is not part of the call. This is a starting point since I can't see what is going on. If you would like to help me visualize it then put the situation in the following format for me.

This is what it should do.

eybeam(299.998.000.22) to ondo router (22.22.22.22) to ondo(192.168.1.22).

This is what it is doing.

eybeam to ondo router back to eyebeam.

thanks!

[kingston]

Kingston,

I can not visualize your setup but I am concerned about the two lans you have connected to your brekeke server. Let's eliminate that as a problem by binding Brekeke to the lan you want to use for this problem call and restricting Brekeke from using the other lan address. In your sv.properties file in Program Files\Brekeke\pbx\webapps\proxy\WEB-INF\work\sv directory put the following lines in then reboot the server to make sure they get picked up.

net.net1.interface-restrict=xx.xx.xx.xx (where xx.xx.xx.xx) is the lan address that is not part of the call. This is a starting point since I can't see what is going on. If you would like to help me visualize it then put the situation in the following format for me.

This is what it should do.

eybeam(299.998.000.22) to ondo router (22.22.22.22) to ondo(192.168.1.22).

This is what it is doing.

eybeam to ondo router back to eyebeam.

thanks!

Dear Nick,

The following is the PC to 3G call flow:

1. eyebeam (public ip) to NAT router (202.255.255.255)
2. NAT router port forward to Ondo SIP Server (192.168.99.122)
3. OSS forwards only ^INVITE request (by using dialplan) to N30 SIP-GW (192.168.96.4)
4. N30 SIP-GW (192.168.96.4) to P25M ISDN-GW (192.168.96.3) to 3G handheld

In eyebeam, I have to define the sip-proxy address as 202.255.255.255:5060 in order make eyebeam able to do registration and out-dial to 3G handheld through OSS.

NAT router can only do port forwarding to the 192.168.99.xxx lan segment. So I need to define 192.168.99.122 lan address in OSS in order to receive the packets from NAT router. After the packet reached OSS, the OSS will implement the dial-plan rule to identify and forward only ^INVITE request to N30 (i.e. $request=^INVITE deploy $target=192.168.96.4). Because N30 (192.168.96.4) & P25M (192.168.96.3) are located in different lan segment (192.168.96.xxx). Hence I cannot directly forward the ^INVITE request to N30 gateway. I need to define another lan address 192.168.96.7 in OSS in order to make OSS & N30 locate under the same lan segment and they are inter-communicable.

If I restrict the 192.168.96.7 lan address in OSS, the ^INVITE request will not be able to forward to N30 SIP-GW (192.168.96.7). On the other hand, if I restrict lan address 192.168.99.122 in OSS. Packets from NAT router will not be able to forward to OSS. For this reason, I need to use both lan addresses in OSS, so that the packet received from Nat router can be forwarded to OSS & GW and vice versa.

As I study the ethereal log, I found that the “200 ok” request submitted by OSS (192.168.99.122) can be properly received and acknowledged by eyebeam.

Oss (192.168.99.122) to eyebeam (public ip) to oss (192.168.99.122)

However, the “200 ok” request from N30 (192.168.96.4) cannot be handle properly by OSS (192.168.96.7). OSS acknowledges the “200 OK” by sending the ACK to NAT router instead of N30. When the NAT router received this ACK packet, it re-forwards it back to OSS. As a result, looping happen between NAT router and OSS, and the ACK packet can never submit to N30.

1. N30 (192.168.96.7) submit “200 ok” to oss (192.168.96.7);
2. oss (192.168.99.122) submit ACK to NAT router (202.255.255.255);
3. NAT router (202.255.255.255) to oss (192.168.99.122);
4. ack looping.

I hope the information provided could help you to figure out the root caused. Please kindly inform me if you do need more details.

Thanks a lot.

Kingston

[voipwell.com]

Kingston,

So the problem appears to be that the N30 sends an OK to Brekeke and Brekeke sends the Ack to the router instead of back to the N30 right?

It might be possible that the nat traversal is confused by the dual lan's. If that is the case then turn off rtp relay and nat traversal in the dial plan for the invites to N30. That may help.

In the deploy pattern for dial plan that invites N30 put
$nat = false
&net.rtp.follow.remoteaddr = false

If that doesn't work , then turn off nat traversal and rtp relay in the sip config. (reboot) then use the above two lines for the from and to pbx dial plans with true on both variables and in both dial plans. This will force rtp and nat traversal off on everthing except the to and from pbx which the eyebeam will use. You shouldn't have to do this though and it is not advisable to leave it this way since it does not accomdate all scenarios.

Nick

[kingston]

Dear Nick,

Kingston,

So the problem appears to be that the N30 sends an OK to Brekeke and Brekeke sends the Ack to the router instead of back to the N30 right?

Sorry, the error case I gave you previously was not completely correct. The situation should be as follow:

Kingston

Code: Select all

1. eyebeam (public ip) INVITE to N30;
2. N30 responsed back Trying, Ring & INVITE OK to eyebeam;
3. eyebeam send INVITE-ACK back to N30;
4. OSS (192.168.99.122) received INVITE-ACk and forward it to NAT router (202.255.255.255) instead of N30 (192.168.96.4);
5. NAT router (202.255.255.255) received INVITE-ACK and forward it back to OSS (192.168.99.122). INVITE-ACk looping occurred, and N30 never recieved the INVITE-ACK from eyebeam;
6. N30 (192.168.96.4) submitted a "200 ok" to OSS (192.168.96.7);
7. OSS (192.168.99.122) received "200 ok" and forward it to eyebeam via NAT router (202.255.255.255);
8. eyebeam receive "200 ok" and submitted an ACK back to N30;
9. ACK reached NAT router (202.255.255.255) and forward to OSS (192.168.99.122);
10. OSS (192.168.99.122) received the ACK, and forward it to NAT router again instead of forward to N30
11. NAT received ACK, and again forward it to OSS;
12. Again, ACK looping occurred between NAT router & OSS, "200 ok" ACK can never receive from eyebeam.

[/color]


It might be possible that the nat traversal is confused by the dual lan's. If that is the case then turn off rtp relay and nat traversal in the dial plan for the invites to N30. That may help.

In the deploy pattern for dial plan that invites N30 put
$nat = false
&net.rtp.follow.remoteaddr = false

If that doesn't work , then turn off nat traversal and rtp relay in the sip config. (reboot) then use the above two lines for the from and to pbx dial plans with true on both variables and in both dial plans. This will force rtp and nat traversal off on everthing except the to and from pbx which the eyebeam will use. You shouldn't have to do this though and it is not advisable to leave it this way since it does not accomdate all scenarios.

Nick

Hi Nick,

I tried the first configuration but it doesn't work.

Could you please give me a dial-plan example for the second configuration?

Currently the dial plan I am using for ^INVITE is as follow:

Pattern:
$request=^INVITE
To=sip:6(.+)@

Deploy:
$auth=false
$target=192.168.96.4

I found that it is no problem for N30 to submit SIP request packet to eyebeam;
But the SIP request packet from eyebeam can never reach N30, and such packet will be sending back and forth between NAT router and OSS.
I guess it was because I only allowed ^INVITE request forward to N30, so all ACK, BYE and other SIP request can never be forwarded to N30. Is it possible to define SIP request type to wildcard in dial-plan pattern, e.g. $request=*. So that all requests besides ^INVITE can be forwarded to N30 Gateway?

Thanks a lot.

Kingston

[kingston]

Dear Nike,

The issue is fixed. What I do is defined the dial plan and explicitly defined the destination ip as 192.168.96.4 as follow:

Matching Patterns

Code: Select all

$request=^INVITE
To=sip:(.+)@

Deploy patterns:
$auth=false
$target=192.168.96.4
[color=red]To=sip:%1@192.168.96.4[/color]

All requests including ACK & BYE from eyebeam can now forwarded to N30 (192.168.96.4) and vise versa.

You do help me a lot in solving the problem. Thanks a lot.

[voipwell.com]

Kingston,

Your welcome. Helping you exposes me to more ways that people use Brekeke. Being able to modify the sip headers which is what you did to solve your problem, is one of the most powerful features that seperate Brekeke from the rest of the market. You have obtained enough knowledge to see you thru most problems you will encounter. I look forward to seeing you back here helping others when you have time.

Thanks for using Brekeke!

Nick