Open Source Sip: Inconsistency Problems ...

Previous Next Up to Discussions in OpenSBC

This Question is Not Answered

1 "correct" answer available (5 pts) 2 "helpful" answers available (1 pts)

31 Replies Last post: Nov 18, 2009 11:01 AM by mparadis 1 2 3 Previous Next

mparadis

95 posts since
Oct 2, 2009

Oct 27, 2009 12:50 PM

Inconsistency Problems

We have been suffering inconsistency problems since day one. With or without poking hopes in the remote users firewalls, the results are always the same. Sometimes they register instantly, most of the time they don't. When they do register fine, sometimes we'll get one way audio, sometimes the call is perfect. Yet, if they disconnect and try to re-register, again, they can't register.

We are using two vyatta/opensbc servers with DNS SRV records which low balance between the two. At this point, I've taken one out of the picture to simplify things and the behavior is the same. We had been wondering if perhaps the pbx (sipxecs) might be getting confused as to whom to send the packets back to.

I am more than willing and happy to give more information but I thought I would post my config to start with and wonder if perhaps it could be too restrictive or something else which might not be so obvious to us at this point. I would welcome any input you might have on this and thanks for taking a look.

Mike

[Solegy]
RTTS-Client-Address=(gets populated automatically with outside IP, this is of no use)

[OpenSBC-General-Parameters]
SIP-Log-Level=2
PTRACE-Log-Level=5
Log-File-Prefix=b2bua
SBC-Application-Mode=B2BUpperReg Mode
Interface-Address Array Size=0
Enable-Backdoor-Port=True
Enable-Trunk-Port=True
Enable-Calea-Port=True
RTP-Min-Port=10000
RTP-Max-Port=20000
Enable-Local-Refer=True
Max-Forwards=70
Encryption-Mode=XOR
Encryption-Key=GS
Transaction-Thread-Count=10
Session-Thread-Count=10
Alerting-Timeout=30000
Seize-Timeout=60000
SIP-Timer-B=Default
SIP-Timer-H=Default
Session-Keep-Alive=1800
Session-Max-Life-Span=10800
Max-Concurrent-Session=100
Max-Call-Rate-Per-Second=10
NAT-Keep-Alive-Interval=15
Send-OPTIONS-NAT-Keep-Alive=True
Send-Responses-Using-New-Socket=True
Disable-Refer-Optimization=False

[Upper-Registration]
Enable-Stateful-Reg=False
Rewrite-TO-Domain=False
Rewrite-FROM-Domain=False
Route-List Array Size=0
All-Reg-As-Upper-Reg=False

[Internal-DNS-Mapping]
Internal-DNS-Map Array Size=0

[Proxy-Relay-Routes]
Drop-Routes-On-Ping-Timeout=False
Proxy-Resolve-To-URI=True
Route-List Array Size=0

[B2BUA-Routes]
Enable-Route-Scripting=False
Route-Script=b2bua-route.cscript
Route-List Array Size=1
Route-List 1=[sip:*@mydomain.com] sip:mydomain.com
Insert-Route-Header=True
Rewrite-TO-URI=True
Prepend-ISUP-OLI=False
Route-By-Request-URI=True
Route-By-To-URI=False
Drop-Routes-On-Ping-Timeout=False
Use-External-XML=False
External-XML-File=b2bua-route.xml

[Media-Server]
Enable-Media-Server=False
Media-Server-Number=5000
Codec-List Array Size=0
No-RTP-Proxy-On-All-Transfers=False
Enable-Announcement-Service=False
4xx-Error-Map=prompts/basic/cant_complete.wav
5xx-Error-Map=prompts/basic/cant_complete.wav
6xx-Error-Map=prompts/basic/cant_complete.wav
Announcement-Error-Map Array Size=0

[Outbound-Proxies]
Outbound-Proxies Array Size=0

[Local-Domain-Accounts]
Accept-All-Registration=True
Account-List Array Size=0

[SIP-Transports]
Main-Interface-Address Array Size=0
Backdoor-Interface-Address=sip:192.168.1.5:5062
Trunk-Interface-Address=sip:*:5064
Media-Server-Interface-Address=sip:*:5066
CALEA-Interface-Address=sip:*:5068
Auxiliary-Interface-Address=sip:*:5070
Interface-Route-List Array Size=1
Interface-Route-List 1=[sip:192.168.1.*] sip:192.168.1.5

Get_The_Fish

20 posts since
Apr 25, 2009

1. Oct 27, 2009 9:49 PM

in response to: mparadis

Re: Inconsistency Problems

At first blush this sounds exactly like NAT issues on the remote end. I am not trying to point fingers off on the remote users, but I have experienced this many times in the past. Since you say that you have OSBC installed on Vyatta (I have the same), are you pointing the remote users to Vyatta's WAN address and not one in the NAT range? What are the firewall rules on that Vyatta device for this WAN IP address?

I would strongly recommend doing a packet sniff, preferably on both ends, however with SOHO routers at the remote end this is often impossible. Some will work though. These little SOHO devices are an absolute nightmare to work with, so be forewarned.

You might also try using STUN or ICE, this might help resolve the issue. You could also experiment with the NAT keep alive, turning it down lower and see if that does anything to resolve it.

My money is on the remote end SOHO firewall though. I have none of the issues that you are experiencing with OpenSBC on Vyatta with remote registration, however I dont have soho routers on the remote end to contend with.

My $0.02. If you want to attach some pcap files I will be happy to look them over.

mparadis

95 posts since
Oct 2, 2009

2. Oct 28, 2009 12:25 AM

in response to: Get_The_Fish

Re: Inconsistency Problems

It is definitely a NAT issue, but as I said, it's because we cannot control the firewall where the remote user is while travelling. Today, we tested using gizmo5 on the same remote pc that gets inconsistent x-lite use and that worked each and every time. That means that the configuration is probably fine but I posted it in case someone might notice something we might want to change, perhaps we have things a bit too tight.

I'm using vyatta with opensbc on it and just read that openvpn is a part of vyatta so that might be something to look at for some cases.

Mike

joegen

539 posts since
Apr 28, 2007

3. Oct 28, 2009 7:28 AM

in response to: mparadis

Re: Inconsistency Problems

I do not see anything wrong with your config aside from probably setting Send-Responses-Using-New-Socket to true. You may also try setting the keep alive interval to a lower value. If you can post the level 5 log for a REGISTER that fails to get an answer, perhaps we can pinpoint what really is happening.

mparadis

95 posts since
Oct 2, 2009

4. Oct 28, 2009 10:40 AM

in response to: joegen

Re: Inconsistency Problems

I'll change the log to 5 and see if we can generate some test input.

By the way, something interesting. We had a remote user who has been using x-lite give gizmo a try and that worked right off the bat 100%. Repeatedly, registration and calls would work but when he would go back to x-lite, nothing.

I have been looking on the net trying to find information on what the difference might be between the two clients but so far, haven't found much.

Mike

mparadis

95 posts since
Oct 2, 2009

5. Oct 28, 2009 11:28 AM

in response to: mparadis

Re: Inconsistency Problems

Can you suggest a start/end section of log that would be good for posting? I am not yet familiar with much of the information in the logs.

Mike

mpicher

40 posts since
Dec 28, 2008

6. Oct 28, 2009 7:30 PM

in response to: mparadis

Re: Inconsistency Problems

Mike,

From there, /usr/local/bin/shutdown.sh

And then, /usr/local/bin/startup.sh

This will make a fresh log file in the/root/OpebSIPStack/OpebSBC_data/logs folder.

Mike

joegen

539 posts since
Apr 28, 2007

7. Oct 28, 2009 10:49 PM

in response to: mparadis

Re: Inconsistency Problems

If Gizmo works everytime and XTEN is intermittent inside exactly the same NAT, then by process of ellimination you should look at XTEN. XTEN is known for its near-end NAT traversal techniques which unfortunately may cause havoc if there are two entities trying to traverse the evil NAT. You have mentioned asterisk is also configured with NAT enabled so that makes it three entities in your setup trying to traverse NAT. That is a real bad situation. You must choose one solution and stick with it.

Now to prove this, just take a look at the Contact address XTEN is sending and compare it with Gizmo's during registration. My bet is XTEN sends the NAT address in the contact header while Gizmo uses the private address. Gizmo in this case would benefit from the farend NAT traversal of OpenSBC. XTEN, on the other hand, can only hope that whatever it puts in the contact address agrees with the actual port alloted by the NAT. Maybe it guesses correct sometimes. That's why its intermittent.

mparadis

95 posts since
Oct 2, 2009

8. Oct 28, 2009 11:26 PM

in response to: mpicher

Re: Inconsistency Problems

Hi,

I've got a lot of logs, just not sure which parts to post. I've had the remote try to log in using both a soft phone and a grandstream sip phone. If someone could tell me what part/section of the log to post, I would be happy to.

Thanks.

Mike

mparadis

95 posts since
Oct 2, 2009

9. Oct 28, 2009 11:39 PM

in response to: mparadis

Re: Inconsistency Problems

Not sure what to post but does this tell anything?

009/10/29 03:33:53.351 DBG: [CID=0xe24e6485] Finding transaction for REGISTER sip:mydomain.com SIP/2.0
2009/10/29 03:33:53.351 DBG: [CID=0xe24e6485] Setting Transaction ID to 80721da693a5bcd45995cc2392f4fff2@24.117.250.211|z9hG4bKec47a0d30df48637|REGISTER
2009/10/29 03:33:53.351 DTL: [CID=0xe24e6485] Found NIST|80721da693a5bcd45995cc2392f4fff2@xx.xx.xx.xx|z9hG4bKec47a0d30df48637|REGISTER for REGISTER sip:mydomain.com SIP/2.0
2009/10/29 03:33:53.351 DTL: [CID=0xe24e6485] NIST(1253355895) Event(SIPMessage) - REGISTER sip:mydomain.com SIP/2.0
2009/10/29 03:33:53.351 DBG: [CID=0xe24e6485] TRANSACTION: (NIST) REGISTER sip:mydomain.com SIP/2.0 State: 3
2009/10/29 03:33:53.352 INF: [CID=0xe24e6485] >>> SIP/2.0 401 Unauthorized Method(REGISTER) DST: xx.xx.xx.xx:5060:UDP src=173.8.107.76:5061 enc=0 bytes=669
2009/10/29 03:33:53.352 DBG: [CID=0xe24e6485]
2009/10/29 03:33:53.352 DBG: [CID=0xe24e6485] SIP/2.0 401 Unauthorized
2009/10/29 03:33:53.352 DBG: [CID=0xe24e6485] From: "aztest" <sip:2824 at mydomain dot com;user=phone>;tag=cd355665f124d1d4
2009/10/29 03:33:53.352 DBG: [CID=0xe24e6485] To: <sip:2824 at mydomain dot com;user=phone>;tag=de8b9d12
2009/10/29 03:33:53.352 DBG: [CID=0xe24e6485] Via: SIP/2.0/UDP 24.117.250.211:5060;branch=z9hG4bKec47a0d30df48637;rport=5060;received=xx.xx.xx.xx
2009/10/29 03:33:53.352 DBG: [CID=0xe24e6485] CSeq: 10001 REGISTER
2009/10/29 03:33:53.352 DBG: [CID=0xe24e6485] Call-Id: 80721da693a5bcd45995cc2392f4fff2@xx.xx.xx.xx
2009/10/29 03:33:53.352 DBG: [CID=0xe24e6485] Date: Thu, 29 Oct 2009 03:33:30 GMT
2009/10/29 03:33:53.352 DBG: [CID=0xe24e6485] User-Agent: sipXecs/4.0.2 sipXecs/registry (Linux)
2009/10/29 03:33:53.352 DBG: [CID=0xe24e6485] WWW-Authenticate: Digest realm="mydomain.com", nonce="90cb1c7649fc36541786541c73a990484ae90d0a"
2009/10/29 03:33:53.352 DBG: [CID=0xe24e6485] Accept-Language: en
2009/10/29 03:33:53.352 DBG: [CID=0xe24e6485] Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, REGISTER, SUBSCRIBE
2009/10/29 03:33:53.352 DBG: [CID=0xe24e6485] Supported: gruu, path
2009/10/29 03:33:53.352 DBG: [CID=0xe24e6485] Content-Length: 0

joegen

539 posts since
Apr 28, 2007

10. Oct 29, 2009 12:37 AM

in response to: mparadis

Re: Inconsistency Problems

[CID=0xe24e6485] will remain constant for the lifespan of the registration. simply grep that and post the result of your log. You are masking your IP addresses so I wont get the entire feature. If you want you can simply mail me the log privately at joegen at opensipstack dot org so you don't have to mask the ip addresses.

mparadis

95 posts since
Oct 2, 2009

11. Oct 29, 2009 12:51 AM

in response to: joegen

Re: Inconsistency Problems

Emailed you the log directly. Didn't want to edit it just in case I missed something.

Thanks very much for your input on this.

Mike

joegen

539 posts since
Apr 28, 2007

12. Oct 29, 2009 1:15 AM

in response to: mparadis

Re: Inconsistency Problems

Ok for this particular log that you sent, the culprit is that opensbc is using a new socket to send responses back. Thus the response from sipx is not reaching your grandstream phone.

Have you been listening all along? I said Send-Responses-Using-New-Socket might be causing it. Set that to false. Current CVS code already has that thing set to false by default. Get back to me if that doesnt solve your problem with the grandstream phone.

mparadis

95 posts since
Oct 2, 2009

13. Oct 29, 2009 8:42 AM

in response to: joegen

Re: Inconsistency Problems

Yes, I have been listening but didn't want to change anything too quickly until you had a chance to look. Plus, this setting was something which was suggested to set to the other setting to see what would happen so had left it as such for now.

I have changed it back.

I will have the phones and x-lite testing again and report.

Mike

PS: Only one of the two remote grandstream phone are not working. One was connecting just fine, making calls, the other was not. After the change requested, the behavior appears to remain the same. Should I send you additional log?

joegen

539 posts since
Apr 28, 2007

14. Oct 29, 2009 11:07 AM

in response to: mparadis

Re: Inconsistency Problems

Mike,

I sincerely apologize for the tone. There was suppose to be smiley after the question mark. didnt mean to sound like your 1st grade teacher :-). Sure send the log. However ,would you be able to grep the specific call-id this time so I dont have to guess which messages are culprit and which ones to ignore.

Joegen

Go to original post 1 2 3 Previous Next

Go to original post

This Question is Not Answered

Oct 27, 2009 12:50 PM

Inconsistency Problems

Actions

More Like This