[asterisk-users] Maximum retries exceeded on transmission

[Brian Jones]

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 <joao.pereira at fccn.pt> 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
> >>> CAB5E4C9-8B95-42D4-9A93-FB996EDC43A2 at xxx.xxx.xxx.xxx for seqno 12282
> >>> (Critical Response)
> >>> Apr 10 02:04:19 WARNING[7007]: chan_sip.c:1245 retrans_pkt: Hanging
> >>> up call CAB5E4C9-8B95-42D4-9A93-FB996EDC43A2 at xxx.xxx.xxx.xxx - 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 <sasha at presidium.org>
> >> _______________________________________________
> >> --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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20070413/251dfda7/attachment.htm