[asterisk-users] Outgoing SIP calls dropped after 30 seconds.
kurt.knudsen at gmail.com
Sat Nov 8 09:20:16 CST 2008
Not using the CDR for billing, but I do use it to see usage and to
know if it's cheaper to purchase a provider with unlimited incoming
and pay-per-minute outgoing. I disabled 'SIP Transformation' in the
SonicWall and so far so good (10/10 calls worked, more testing to be
had, stay tuned.)
On Sat, Nov 8, 2008 at 5:12 AM, Steve Totaro
<stotaro at totarotechnologies.com> wrote:
> Usually, calls terminating at 30 seconds is a sure sign that you need to add
> an Answer() in your dialplan. Try dropping that in before you dial out. I
> have seen this so many times and Answer() has always fixed the issue. The
> magic number is 30 seconds.
> Depending on if you use your CDRs for anything, especially billing, you may
> need to figure a way around that, since even if a call rings out, the CDR
> will reflect Answered.
> Steve Totaro
> +18887771888 (Toll Free)
> +12409381212 (Cell)
> +12024369784 (Skype)
> On Fri, Nov 7, 2008 at 10:38 PM, Grey Man <greymanvoip at gmail.com> wrote:
>> To get to the bottom of it I'd recommend determining why the ACKs are
>> not getting through to Asterisk rather than trying to work around it.
>> I'm actually suprised Asterisk terminates the call by default when it
>> doesn't get the ACK to it's 200 Ok response that must be new for
>> 1.4.22 as I haven't seen that behaviour in earlier versions. In my
>> opinion it's unwarranted behaviour, if Asterisk is getting RTP then it
>> should leave the call up irrespective of whether it gets an ACK or
>> From the original SIP trace the ACK does not appear to be arriving at
>> your Asterisk server at all. Try doing a packet trace on the network
>> segment where the calling SIP agent is and see where it's trying to
>> send the ACK to. My guess would be your firewall is incorrectly
>> handling the SIP messages. Generally it's very bad news to use an ALG
>> or firewall to mangle SIP packets as they almost always get it wrong.
>> In your case there is a Record-Route header in the response so the ACK
>> request should be being sent to that address. Perhaps your firewall is
>> not correctly mangling that to allow the request to find its way back
>> to your Asterisk server.
>> Record-Route: <sip:22.214.171.124;lr;ftag=as3ed791f3>
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
More information about the asterisk-users