Cbeyond drop call every ten minutes

Asterisk Asterisk Support
1

There are a few posts about phone calls being drop after 10 minutes (and a few seconds) systematically, none address this issue.
I’m using Asterisk 11.4.0 FPBX-2.8.1(11.4.0).
After hours with Cbeyond level-2 support, they told me that their system ([color=#804040]Broadworks[/color]) send a test message (or something like that) every ten minutes and expect a reply from Asterisk.
The request is coming from the ‘sip-proxy’ server, but our reply (that indeed exists) is being sent to the ‘sipconnect’ server. (?)
I’m lost. Everything else works fine: incoming calls are routed and processed without problem (any length). Outgoing calls using other (non Cbeyond) vendors also works fine (Callcentric, Skype and using SPA3102 boxes)

host=sipconnect.mia0.cbeyond.net fromdomain=sipconnect.mia0.cbeyond.net outboundproxy=sip-proxy.mia0.cbeyond.net
Help is appreciated,
fcm

2

sip set debug on

We’re going to need to see the Contact and Via headers before we can work out where the bug lies.

3

Thanks for your help, indeed the log is quite large and i trim about 30 mins.
the trunk info is

type=peer username=305xxxxxxx host=sipconnect.mia0.cbeyond.net fromdomain=sipconnect.mia0.cbeyond.net outboundproxy=sip-proxy.mia0.cbeyond.net secret=XXXXXX remotesecret=XXXXXX qualify=60 nat=never insecure=port,invite dtmfmode=auto dtmf=rfc2833 disallow=all allow=ulaw context=from-trunk canreinvite=no defaultexpiry=30

and the user information is

type=peer rfc2833compensate=yes host=sip-proxy.mia0.cbeyond.net dtmf=auto context=from-pstn qualify=yes

(Partial) log file
http://www.superwake.com/log/cbeyond.txt

Thanks,

4

You didn’t start at the beginning (the incoming INVITE).

Asterisk is dropping the first call because it isn’t getting an ACK.

It is replying to where the request came from, which I think is correct.

There seems to be a Trying after the first OK, which is very wrong.

5

I hope this is a complete log. I filtered most of the noise (I hope not too much)…
http://www.superwake.com/log/cbeyondfiltered.txt
I can see that asterisk try first to place a call without authentication and when fails, try again with credentials.
The originator is not on the same site than the PBX, using NAT. However, the end result is the same if the call is originated on the same LAN.

6

Can you please delete all the OPTIONS requests and their responses, as there is still too much noise.

5558 is unauthorised because there was no Authorization header on the INVITE. That is standard as you need the 401 response to know how to construct that header.

7

David55, thanks four your help.
I spent another two hours today with cbeyond support, that makes almost 5 hours total, with no luck. They think we are missing a SIP package, however, every other is OK. They have a paper that describes some issue on a CISCO router that may create this issue; will post if they find a solution.
in the mean time, a new trace http://www.superwake.com/log/Jul-30-13_07-00.txt
I’m puzzled on why only us are having this Broadworks/Asterisk issue. Maybe longer than 10 minutes calls are not that common after all.
Also I found a few timeouts like this,

chan_sip.c: Header 5 [ 22]: CSeq: 445467441 INVITE chan_sip.c: Ignoring SIP message because of retransmit (INVITE Seqno 445467441, ours 445467441) and finally:

fc

8

Without going into the trace again, drops at around 10 minutes could be due to a failure to respond to session timers. If that is the case, setting them to refuse may be enough.

9

I tried each of the following and then both, with no success.

session-timers=refuse disallowed_methods=UPDATE
Maybe if you can tell me what are we looking for I can do the search…
Thanks,

10

Did you get this solved? I am having the same issue with 11.4. I have isolated it to CBeyond sending an invite from its proxy after 10 minutes of communication (it is a timer they have in place to make sure the conversation is still valid). Asterisk is sending a reply to the host instead of the proxy. The proxy does not see receive an OK and thus sends a BYE shortly after. I think this is a simple setting that I have missed.

11

No solution yet.
I can confirm that Cbeyond support also pointed out to the handshake issue, however, I still can’t figure out a way to fix or to work around it.
I hope that someone in the Asterisk community have a similar experience and will advise us on the subject.

12

I think this is now working. The fix was to add the force option to the trunk configuration - it wasn’t an easy find. a working config for the trunk is below. You need the “,force” at the end of the outboundproxy configuration

disallow=all
allow=ulaw&g729
context=from-pstn
type=peer
canreinvite=no
insecure=invite,port
qualify=yes
sendrpid=yes
trustrpid=yes
dtmfmode=auto
username=XXXXXXXXXX – This is usually the phone number
secret=PASSWORD
host=sipconnect.XXXX.cbeyond.net
fromdomain=sipconnect.XXXX.cbeyond.net
outboundproxy=sip-proxy.XXXX.cbeyond.net,force
nat=never

13

Just wanted to do a follow up to explain the issue in case someone else runs into this (I can provide traffic sniffs if anyone is interested). CBeyond uses a PROXY for call set up and tear down and the RTP traffic is routed through a separate HOST (please forgive me if the terminology is not 100% correct). CBeyond’s PROXY sends an invite to set up the call originally and then another invite from the PROXY every 10 minutes into a conversation to make sure it is still running. Asterisk 11.4, by default appears to negotiate with the SIP PROXY for call setup, but is replying to the SIP HOST when receiving the invites from the PROXY at the 10 minute intervals. The force option on the outbound proxy is forcing Asterisk to push all SIP communications through the PROXY. I do not know if the reason Asterisk is replying to the HOST instead of to the PROXY is from a malformed header from CBeyond or not (the URI in the CBeyond packet did denote the PROXY) and I am not versed enough on the packet structure to tell. Hope this helps.

14

Work like a charm!! Thanks a lot for your research.
The only new issue for me was that a RELOAD is -[color=#FF4000]NOT[/color]- enough to change the trunk parameters. Only a CORE RESTART makes the trick. (This indeed answer me a few old issues :blush: )
Thanks again

15

Glad to hear everything worked. A bug trac has been submitted to the asterisk team, but it may not be a bug depending on the standard. It is great to have a workaround. What release of asterisk are you running? I am on 11.4 and the reload works.