[Home]

Summary:ASTERISK-13735: [patch] early-dial SIP 484 "incomplete address"
Reporter:vieri (vieri)Labels:
Date Opened:2009-03-12 04:40:26Date Closed:2011-07-26 14:23:07
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 10.215.146.165.log
( 1) 10.215.146.175.log
( 2) asterisk-1.4-chan_sip.diff
( 3) from_4063_TO_4064_trace.log
( 4) full.earlydial
( 5) full.earlydial.pedantic_yes.log
( 6) full.earlydial2
( 7) pedantic_debug.diff
Description:Calls in which at least one Grandstream GXP2000 or GXP280 is involved, get dropped after about 20 seconds. This happens only if the Grandstreams are configured to use "early dial" and Asterisk has pedantic=yes (with pedantic=no the calls are not dropped).

I really need pedantic=yes to encode the # digits.

Would it be possible to use pedantic=no but make the # digits "work"? (because I realize this may be a Grandstream firmware bug which I don't think will be fixed any time soon)



****** ADDITIONAL INFORMATION ******

I tried to add
insecure=very
and remove qualify=
for each sip.conf extension definition.
The faulty behavior is still the same.

I read sip_retransmit.txt but my SIP phones are on a LAN directly connected to the Asterisk server (no firewalls, no nat).

I am attaching a SIP debug where GXP2000 extension 4062 calls GXP280 extension 4060.

Using 1.4.23.2.
Comments:By: vieri (vieri) 2009-03-12 05:22:56

The attached chan_sip.diff allows me to set
pedantic=no
urlencode=yes
in sip.conf.

My Grandstream phones with the "early dial" feature work fine now as well as the # key.

By: David Vossel (dvossel) 2009-07-20 18:22:36

Do have any idea why the calls are being dropped with pedantic=yes?

------------------------------------------------------------------------------
What early dial is from http://www.grandstream.com/faqsconfiguration.html

"When you dial a number, if you do not press the "Dial" ( "Redial") or "#" key if it is configured to function as the "Send" key at the end of your dialed string, the phone will wait for about 4 seconds before timeout and then sends the actual INVITE message. If you set "Early Dial" to be YES, then the phone will attempt to send out INVITE at each key input using the entered dial string collected so far. If the SIP server supports 484 Incomplete Address response, the phone will keep trying with each new key entry until the complete dialed string is entered. This will essentially eliminate the 4-second wait time mentioned above."

By: vieri (vieri) 2009-07-21 06:35:16

If the full.earlydial log I attached does not help, I'm afraid I have no idea why calls are dropped with pedantic=yes.

I see messages such as:

[Mar 12 09:19:28] WARNING[6501] chan_sip.c: Maximum retries exceeded on transmission e09a6863f663a2aa@10.215.146.162 for seqno 55056 (Critical Response) -- See doc/sip-retransmit.txt.
[Mar 12 09:19:28] WARNING[6501] chan_sip.c: Hanging up call e09a6863f663a2aa@10.215.146.162 - no reply to our critical packet (see doc/sip-retransmit.txt).

and I've also reviewed the chan_sip implementation but I'm not an expert and just proposed a simple patch which "works for me". I'm wondering if other Grandstream "early dial" users have experienced the same issue with Asterisk.
Of course, I too would prefer to fix the root problem instead of adding yet another sip option.

By: David Vossel (dvossel) 2009-07-21 10:15:04

Can you provide a packet capture, or log output similar to the one you uploaded, of a successful call with early dial enabled and pedantic disabled?

By: vieri (vieri) 2009-07-21 12:06:25

Sure. I will post the data tomorrow.

By: vieri (vieri) 2009-07-22 11:44:56

A "pure-SIP" call was placed from 4063 to 4064. Both are Grandstream devices with early-dial enabled. Asterisk pedantic is disabled.

full.earlydial2: asterisk log

from_4063_TO_4064_trace.log: Wireshark trace with tshark -i eth0 -n -w from_4063_TO_4064_trace.log -f "host 10.215.146.165 || host 10.215.146.175 || host 10.215.147.112"

10.215.146.165.log: Grandstream syslog for ext. 4063

10.215.146.175.log: Grandstream syslog for ext. 4064

Hope this helps.

By: David Vossel (dvossel) 2009-09-09 12:55:08

Vieri, sorry it has taken me so long to get back to this issue.  Thank you for the update.  I've reviewed the log files and I'm still puzzled as to why this is happening.

For some reason when pedantic=yes, the ACK to the 200 OK indicating call setup is complete is not processed.  This results in the 200 OK being retransmitted over and over again until it times out which causes the call to fail.  There are a few places in the code that could cause a ACK to be ignored when pedantic=yes, and without debugging I really have no idea what is causing it.  

I've uploaded a patch that includes some debug output in the form of WARNING messages for the purpose of determining why the ACK in response to the 200 OK is not being processed.  If it is possible, please update to the latest 1.4 code, apply the debug patch, and provide cli output.

By: vieri (vieri) 2009-09-10 03:57:30

Hi, I've uploaded an Asterisk log when pedantic=yes and a GXP280 phone (ext. 4063) calls another GXP280 (4064). The call is dropped after about 20 seconds.
I've applied your patch to 1.4.26.2.

By: David Vossel (dvossel) 2009-10-07 16:25:06

The problem occurs in find_call().  When pedantic checking is on, for some reason the to tags of the request and the sip dialog don't match correctly.

By: Leif Madsen (lmadsen) 2011-07-26 14:23:00.665-0500

Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions

If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks!