[asterisk-dev] [SOLVED]] Outgoing international calls getting dropped 30 seconds into call

[Eloy Paris]

Hello,

On Mon, Dec 10, 2007 at 10:04:33PM +0100, Klaus Darilion wrote:

> Eloy Paris wrote:
> > dropped after about 30 seconds into the
> 
> This is usually an ACK problem. Often SIP gateways which do not receive 
> the ACK (after the 200 ok) hang up after 30 seconds (retransmission time 
> out)

You were partly right - yes, Asterisk was not sending the ACK. However,
the peer was not sending the 200 OK either, so in reality there was
nothing to ACK.

After comparing sniffer traces for a successful call placed by a Linksys
PAP2 ATA and for an unsuccessful call placed by Asterisk, and doing a
bit of research and I was able to determine what the problem is. I think
other people are bound to get hit by this problem at some point, with
BroadVoice or with any other provider, so I'll try to document what
I saw so people don't have to waste as much time as I did trying to
troubleshoot the problem.

Background:

International calls through BroadVoice placed by Asterisk were getting
disconnected about 30 seconds into the call. I only noticed this when
placing calls to Venezuela. I don't know if it happens when calling
other countries since I didn't try. It was not happening with domestic
US calls. In the 30 seconds or so before getting disconnected I could
hear the other party and the other party could hear me.

What I Saw:

1. I was getting the following messages in Asterisk's log:

rtp.c: Comfort noise support incomplete in Asterisk (RFC 3389). Please turn off on client if possible. Client IP: <some BroadVoice IP>

I thought this had to do with the problem but it turns out that it had
nothing to do with the problem. After I resolved the problem I still get
this message but things work just fine.

2. Comparing successful and unsuccessful sniffer traces I saw that in
the case of the unsuccessful call with Asterisk there was a media
attribute that only Asterisk was sending, and that the ATA was not:

silenceSupp:off - - - -

Looking at the source code I found out that Asterisk can be made to not
send this attribute if internal timing is used. I then configured
Asterisk to use internal timing via the ztdummy driver and Asterisk
stopped sending this attribute, but this did not solve the problem.

3. Finally, besides the different codecs being used by Asterisk and
the ATA, the last major difference between calls placed by Asterisk
and the Linksys ATA was that Asterisk was enabled for SIP video, while
the ATA was not. This caused the video session to be described by the
Session Description Protocol in the SIP INVITE from Asterisk. In other
words, there was an additional "Media Description, name and address
(m)" section in the SDP part of the INVITE from Asterisk that specifies
video. This was missing from the INVITE sent by the ATA in a successful
call.

As soon as I turned video support off in Asterisk by setting
"videosupport" to no in sip.conf, the problem went away and the
BroadVoice proxy returned a 200 OK that in turn was ACKed by Asterisk.

I have found users experiencing problems with BroadVoice and video
support.
http://lists.digium.com/pipermail/asterisk-users/2005-March/085203.html
is an example. However, what I think made my case unique is that: 1.
everything was working fine *but* international calls to Venezuela.
Domestic calls had no problems. 2. My setup worked fine for several
months, including international calls to Venezuela. It just broke all of
the sudden.

My conclusion is that this is a problem on BroadVoice's side, or with
someone BroadVoice peers with. I see no reason why a call would have to
be terminated just because a peer tries to establish a video session in
addition to the audio session. BroadVoice is offering now video service
so I would think that if I use one of those devices they offer that
supports video, then I would experience the same problem I experienced
when I used Asterisk, at least when placing international calls to
Venezuela.

Sorry for the longish email, and I hope this helps someone at some
point.

Cheers,

Eloy Paris.-