[asterisk-users] Outgoing SIP calls dropped after 30 seconds.

[Kurt Knudsen]

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.
>
> --
> Thanks,
> 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
>> not.
>>
>> 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:216.82.224.202;lr;ftag=as3ed791f3>
>>
>> Regards,
>>
>> Greyman.
>>
>> _______________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
>
>
>
>
> _______________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>