I've encountered a similar problem with Cisco equipment. The Cisco proxy was not replying to Asterisk with an ACK after * sent an OK.
Since version 1.2.14, * was changed so that not receiving an ACK to an OK is considered a FATAL error. The specific change that causes this problem is in sip_answer() in chan_sip.c: res = transmit_response_with_sdp(p, "200 OK", &p->initreq, 2); Changing the 2 to a 1 will probably fix it. Note that this is NOT a bug in * but improper implementations--either caused by latency, or a software bug (not sending an ACK). Perhaps it might be beneficial to have an option in sip.conf to change how * handles not receiving an ACK? I know... it's someone else's problem, but might help those of us stuck with buggy implementations in production environments. :) Brian. On 4/12/07, Joao Pereira <[EMAIL PROTECTED]> wrote:
Hello Thanks a lot for your reply. Im now using asterisk-1.2.10 and the problem disappeared. Thanks regards Joao Pereira Edoardo Serra wrote: > Same to me !! > > Calls from OpenSER to Asterisk > > It happens only with Asterisk versions >= 1.2.14 > > I'm going to capture some traffic > > Tnx for help > > Regards > > Alex Balashov ha scritto: >> >> Joao, >> >> It sounds like the proxy is not acknowledging the Asterisk's >> processing of the INVITE, but I could be wrong. It would be helpful >> to supply a packet capture between OpenSER and Asterisk so we could >> see the setup flow. >> >> Thanks, >> >> -- Alex >> >> On Tue, 10 Apr 2007, Joao Pereira said something to this effect: >> >>> Hello >>> My asterisk is receiving calls from OpenSER but all calls hangup in >>> 20 seconds. >>> This only happens because Im using Asterisk2Billing's AGI (without >>> A2Billing it doesnt hang up). >>> does someone knows whats the problem?? >>> >>> Here is my Asterisk debug: >>> (xxx.xxx.xxx.xxx -> the phone's IP) >>> >>> >>> >>> Apr 10 02:03:02 WARNING[6996]: res_musiconhold.c:508 monmp3thread: >>> Unable to spawn mp3player >>> Apr 10 02:04:18 NOTICE[8349]: rtp.c:331 process_rfc3389: Comfort >>> noise support incomplete in Asterisk (RFC 3389). Please turn off on >>> client if possible. Client IP: xxx.xxx.xxx.xxx >>> Apr 10 02:04:19 WARNING[7007]: chan_sip.c:1228 retrans_pkt: Maximum >>> retries exceeded on transmission >>> [EMAIL PROTECTED] for seqno 12282 >>> (Critical Response) >>> Apr 10 02:04:19 WARNING[7007]: chan_sip.c:1245 retrans_pkt: Hanging >>> up call [EMAIL PROTECTED] - no >>> reply to our critical packet. >>> Apr 10 02:06:01 NOTICE[8360]: rtp.c:331 process_rfc3389: Comfort >>> noise support incomplete in Asterisk (RFC 3389). Please turn off on >>> client if possible. Client IP: xxx.xxx.xxx.xxx >>> >>> >>> Thanks for the help >>> Regards >>> Joao Pereira >>> >>> >>> _______________________________________________ >>> --Bandwidth and Colocation provided by Easynews.com -- >>> >>> asterisk-users mailing list >>> To UNSUBSCRIBE or update options visit: >>> http://lists.digium.com/mailman/listinfo/asterisk-users >>> >> >> -- >> Alex Balashov <[EMAIL PROTECTED]> >> _______________________________________________ >> --Bandwidth and Colocation provided by Easynews.com -- >> >> asterisk-users mailing list >> To UNSUBSCRIBE or update options visit: >> http://lists.digium.com/mailman/listinfo/asterisk-users >> >> > > _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
