Summary:	ASTERISK-09625: 1.4.4 sends Re-INVITE twice, resulting in code 491 "Request pending" and call termination by Asterisk
Reporter:	Fabian Hoppe (fabianhoppe)	Labels:
Date Opened:	2007-06-08 04:42:19	Date Closed:	2007-07-05 08:27:41
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Interoperability
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) failed_hold.pcap ( 1) trace_failed_reinvite.txt
Description:	Dear All, I'm using Asterisk v1.4.4 with the lastet patch level (as of 27.04.07). Several Polycom phones in a remote location are connected to the Asterisk server via the Internet with IPCoP and siproxd 0.5.13 serving as outbound proxy. All outbound traffic is routed via SIP to a local SIP provider, running a TELES iSwitch as softswitch. My sip.conf is listed below under "additional information". In this setup I run into the following, reproducable problem: When I place an outbound call, the call setup works fine and the reinvites take place, RTP streams a setup between the Polycom and the SIP provider directly. Placing the call on HOLD then results in a re-invite to the SIP-provider who answers with "100 trying". Immediately Asterisk resends an identical re-invite (with an incremented CSeq), resulting in a "491 Request Pending" from the SIP provider (this is the correct answer, as the first INVITE is not yet fully processed). This gets acknowledged by Asterisk and then Asterisk simply terminates the call!! You can find the SIP DEBUG output from the Asterisk server as attachment. I can provide a wireshark capture on request. Please let me know, if more data / logs are needed. ****** ADDITIONAL INFORMATION ****** sip.conf [general] context=from-SIP allowguest=no realm=nfon.net bindport=5060 bindaddr=<IP address * Server> srvlookup=yes pedantic=no tos_sip=cs3                    ; Sets TOS for SIP packets. tos_audio=ef                   ; Sets TOS for RTP audio packets. tos_video=af41                 ; Sets TOS for RTP video packets. maxexpiry=180 minexpiry=60 defaultexpiry=120 t1min=100 checkmwi=10 disallow=all allow=alaw allow=gsm allow=ulaw mohinterpret=default mohsuggest=default language=de progressinband=never useragent=nfon.net dtmfmode = rfc2833 alwaysauthreject = yes rtptimeout=60 rtpholdtimeout=300 allowsubscribe=yes subscribecontext = from-SIP notifyringing = yes notifyhold = yes limitonpeers = yes t38pt_udptl = yes            ; Default false registertimeout=20 registerattempts=0 externip = <IP address * Server> nat=no canreinvite=yes ignoreregexpire=yes ; ; several register statements here ! ; #include "ext/KUNDE0001_sip.conf" [SIP-<SIP-provider>-in] type=peer host=<SIP-provider> context=from-SIP canreinvite=yes insecure=invite nat=no
Comments:	By: Fabian Hoppe (fabianhoppe) 2007-06-08 05:13:04 Patch published with bug 0009305 didn't solve the problem. By: Joshua C. Colp (jcolp) 2007-06-08 10:32:19 Can you please provide a sip debug (the attached is something else...) and try 1.4 SVN? Thanks. By: Fabian Hoppe (fabianhoppe) 2007-06-11 17:41:57 I'm currently getting subversion configured and prepare to compile the SVN. Preparing the logs will require another day, so please be patient. Additionally, I'm getting nervous as I've been struggling to reproduce the problem today. I haven't changed a thing but the double INVITEs didn't happen today. If there weren't several wiresharks documenting the issue. Stay tuned, please. By: Joshua C. Colp (jcolp) 2007-07-02 09:49:07 Any update with this? Been a few weeks. By: Fabian Hoppe (fabianhoppe) 2007-07-03 07:55:40 Gentlemen, I couldn't reproduce the bug described above - neither with the original version nor with the svn trunk. Please have a look at the attached pcap around packet no 246 to see that the bug really exists. We decided to use reinvites for internal calls and to disable reinvites on SIP trunks. Please close this bug report, bug report 9305 probably covers this issue too. Best Regards, Fabian Hoppe By: Joshua C. Colp (jcolp) 2007-07-05 08:27:41 Closed per request, please reopen if this creeps up again.