(repost - can anyone confirm whether they've seen this before, or have any tipes in debugging it?)
Hi Everyone, I was hoping someone might know why I am experiencing a problem with Asterisk logging the event: [May 3 12:07:41] WARNING[30371] chan_sip.c: Maximum retries exceeded on transmission [EMAIL PROTECTED] for seqno 669371069 (Critical Response) This is happening after: - call is setup, 2 way audio - call can function correctly for up to 5 minutes, with the external provider re-inviting every 1 minute When the problem happens - external peer re-invites asterisk - asterisk sends 200 OK - external peer sends ACK - asterisk retransmits 200 OK - external peer sends ack - .. - asterisk retransmits 200 OK (Retransmitting #6) - external peer sends ack - Asterisk logs the above message about maximum retries exceeded, and sends BYE to the inside SIP UA. The network configuration is as follows: phone <--> alternative SIP server <--> Asterisk <-NAT-> External peer The alternative SIP server is not a B2BUA, just SIP proxy. Now, sometimes a call can work without any problems, but not as often as when the above symptoms are experienced. The references I've found online about this type of problem suggest NAT as being the culprit, but in this case, Asterisk is logging it's reception of the ACK but deciding to ignore it and retransmit the 200 OK anyhow. I'm guessing in other cases people suspect is' NAT because they believe SIP isn't getting back trhough after a period of time. I was using 1.4.2, but found this changelog today for 1.4.3: ftp://ftp.digium.com/pub/asterisk/releases/ChangeLog-1.4.3 2006-09-30 16:12 +0000 [r44068-44078] Paul Cadach <[EMAIL PROTECTED]> * channels/chan_sip.c: Found some buggy SIP clients (phones Planet VIP-153T firmware 1.0, Linksys PAP2 firmware 3.1.9(LSc)) which sends ACK not on OK message only (when remote party answers) but on RINGING message too, so when we send 200 OK message, we get unidentified ACK message (because INVITE acknowledged on RINGING message already), so 200 OK retransmits within its retransmission interval then call gets dropped. If someone else knows how to provide workaround for such cases, please, fix it in correct way. Thanks to ssh from #asteriskru for provide access to his box to study and fix this case. I've upgraded to 1.4.4 but the problem still persists. The above changelog doesn't sound exactly like what I"m experiencing but maybe it's related. Attached is my sip.conf, extensions.conf, and (debug = 10) logs for one example. I don't know what else might be needed to help anyone assist me in this problem - let me know if I missed something. It *feels* like an Asterisk bug but maybe a SIP expert can spot the problem in signalling/RFC conformance.. Thanks in advance, Chris Bennett
[general] context=default allowoverlap=no bindport=5060 bindaddr=0.0.0.0 srvlookup=yes domain=proxy.myhostname disallow=all allow=alaw sipdebug = yes recordhistory=yes dumphistory=yes register => <authstuff>@sip.externalpeer.com externhost=proxy.myhostname localnet=192.168.0.0/255.255.0.0 localnet=10.0.0.0/255.0.0.0 localnet=172.16.0.0/12 localnet=169.254.0.0/255.255.0.0 nat=never canreinvite=no [authentication] auth = <authstuff>@sip.externalpeer.com [provider] type=peer username=<myusername> secret=<mysecret> fromuser=<myusername> fromdomain=sip.externalpeer.com host=sip.externalpeer.com nat=never canreinvite=no [1111] type=friend username=1111 secret=<secret> host=dynamic context=tutorial nat=never insecure=invite qualify=yes
[general] static=yes writeprotect=no clearglobalvars=no [globals] CONSOLE=Console/dsp [tutorial] exten => _XXXXXXX.,1,Dial(SIP/[EMAIL PROTECTED],,r)
asterisk.logs.example1.txt.bz2
Description: BZip2 compressed data
_______________________________________________ --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