[Home]

Summary:ASTERISK-00736: sip calls hang up when dtmfmode=info or rfc with asterisk phone
Reporter:kadarpik (kadarpik)Labels:
Date Opened:2004-01-04 16:44:53.000-0600Date Closed:2011-06-07 14:00:59
Priority:BlockerRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) ast_NO_183.txt
( 1) b13p4.39.zip
( 2) call_fail.txt
( 3) call_success.txt
Description:I realized that SIP calls hangup systematicly to some destinations through i4l driver.  Those destinations send always some dtmf information, and if dtmfmode was absent or set to rfc or info I got SIP call hangup i.e. maximum retiries exceeded seqno 102/203. The sip engine was trying to send dtmf sip packets witch were ignored by grandstream.  I also tried to struggle with grandstream setup but ontl inband seems to be working. Now I have side effect and I hear some dtmf tones suddenly.

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

if there is no dtmd answer, it would be better do not hangup the calls for those dtmf sip retries. If isdn is receiveing some dtmf there should be an option to ignore everything. I also ordered a pair of G729 codecs to be shure that the problem is not in bandwidth. Now I see that with g729 I get inband dtmf working but not with 711.
Comments:By: Brian West (bkw918) 2004-01-04 22:45:57.000-0600

Inband dtmf wont work well with g729.  I am not seeing any problems with rfc2833 or info here on my setup.
By: Brian West (bkw918) 2004-01-05 01:06:26.000-0600

Related to bug 739?
By: jrollyson (jrollyson) 2004-01-09 01:10:06.000-0600

I'll bet this is a codec negotiation problem and not a DTMF problem - I've never seen a DTMF misconfiguration cause dropped calls (although it will prevent DTMF from being picked up during a call.)
By: fcs_1 (fcs_1) 2004-01-10 14:03:23.000-0600

I am currently running CVS-01/10/04-13:30:07 on i6868 Fedora Core 1 Linux.  I have two BT102 Grandstram phones software 1.4.30.  If I call from one to the other and press the dial pad creating dtmf the call will hangup.  I am using dtmfmode=info in sip.conf and BT102 setup.

100% happens every time.

Making a call between the two phones and not pressing keypad the call remains up until I hangup one or the other telephone.
By: Brian West (bkw918) 2004-01-10 15:10:50.000-0600

cd /usr/src/asterisk
make update
recompile and try again.
By: jrollyson (jrollyson) 2004-01-10 15:16:01.000-0600

I can't duplicate this using GS 1.4.18 firmware on my BT102 phones at the office. My phones are proxied through Asterisk for # transfers.
Could it be an issue in the phone? Can anyone duplicate this under a firmware other than 1.4.30? Are the SIP phones bridged natively or proxied through Asterisk for codec translation or DTMF handling?

Are either of the phones behind NAT?
Is Asterisk behind NAT?
What codecs are configured/allowed? What codecs are actually being used?
By: fcs_1 (fcs_1) 2004-01-10 15:32:34.000-0600

Sip phones are bridged natively on local network. Asterisk is in a DMZ.
nat=yes for each phone in sip.conf
ulaw,alaw,gsm enabled seems to use ulaw all the time.
Calls and conversations are working fine.  

As a crude test I used a POTS telephone and put the ear piece to the BT102 and pressed dtmf tones.  This was to see if a voice path tone could kill the connection or just the key pad tone.  I know it is not the best dtmf test but could not get the call to drop.

It seems to me something with BT102.  I can call it from Xten-lite or SPA2000 and get the same drop call disconnect when key pressed on the non-BT102 phone.
By: fcs_1 (fcs_1) 2004-01-10 15:38:25.000-0600

Before anyone asks calling between SPA2000 and XTEN-lite does not drop the call when pressing keypad on either phone.

edited on: 01-10-04 15:24
By: jrollyson (jrollyson) 2004-01-10 15:42:30.000-0600

Try downgrading the firmware to 1.4.18 and see if you still have the problem. If it goes away, it may be in the 1.4.30 firmware - in this case, notify GS so that they can address it in their next firmware release.
By: Brian West (bkw918) 2004-01-10 16:03:40.000-0600

Asterisk is still behind nat even if its on the DMZ try apply bug ASTERISK-100 and or set externip in sip.conf.
By: Brian West (bkw918) 2004-01-10 17:07:42.000-0600

ok need to find kram on IRC or myself and we can ssh in and take a look at this and try to see what is wrong.  We can't reproduce this and many others can't either.  So looking at it would help.

bkw
By: fcs_1 (fcs_1) 2004-01-10 18:07:54.000-0600

bkw918 extenip is the only way things work here for external and internal sip phones. I am using a DNS resolution for all SIP phones to address the DMZ asterisk. Other problems went away with 1.4.30 so I don/t feel 1.4.18 is the answer.  I don't recall that 1.4.18 had the problem but did not do a test case for it.

Also note bkw918 that I am on current CVS  CVS-01/10/04-13:30:07 so patch 104 is not the answer.
By: Brian West (bkw918) 2004-01-10 18:38:08.000-0600

If you have phones on the public internet and asterisk is the DMZ behind NAT then you need 104 to fix this problem.  104 isn't in CVS and has been proven to fix this when asterisk is behind nat (even the DMZ is behind nat)

bkw
By: fcs_1 (fcs_1) 2004-01-10 23:09:37.000-0600

I am new to the asterisk project.  I don't understand why 104 is not already in the cvs.  It is an old patch.  Why is not part of the CVS ?
By: Brian West (bkw918) 2004-01-11 02:31:56.000-0600

104 breaks the hold button on Cisco 7960's
By: fcs_1 (fcs_1) 2004-01-11 14:16:32.000-0600

So patch 104 is not a fix to use if it breaks other functions.  I would think we want Asterisk to handle any SIP device properly.

It is not obvious to me how to tell if a patch is in CVS.  Is there a listing of patches and their status to CVS inclusion ?
By: Tilghman Lesher (tilghman) 2004-01-11 14:34:32.000-0600

If the status is resolved, that generally means the bugfix or a similar bugfix is in CVS.
By: jrollyson (jrollyson) 2004-01-12 00:32:43.000-0600

fcs_1: when a patch from the bugtracker is added to CVS this is normally bugnoted and the bug is marked "resolved"
By: fcs_1 (fcs_1) 2004-01-12 17:13:10.000-0600

thank you
By: jrollyson (jrollyson) 2004-01-14 02:47:06.000-0600

Can someone else with ISDN4Linux duplicate this?
By: jrollyson (jrollyson) 2004-01-14 03:20:06.000-0600

kadarpik: Is there a reason you are not using chan_capi? (ie hw not supported etc)
By: z_smurf (z_smurf) 2004-01-14 06:48:17.000-0600

I have tested with Budgetone version 1.0.4.17.

If "Send DTMF" is set to "via SIP INFO",
asterisk reports a new line in the console for every digit pressed:

-- Attempting native bridge of SIP/2016-af6a and SIP/2013-ae9c
-- Attempting native bridge of SIP/2016-af6a and SIP/2013-ae9c
-- Attempting native bridge of SIP/2016-af6a and SIP/2013-ae9c

A few seconds after this the call will hang up.

If the phone is set to "Send DTMF in-audio" then this does not occur all, but then the voicemail does not euther work.

This is a sip-debug of a call, starting with me pressing a 5.
It seems that asterisk reads the digit from phone 1, sends it to phone2 (which is ignoring it), and then wants an acknowledgement that is never sent from phone2?

Sip read: >
INFO sip:2013@194.237.110.162 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.4
From: <sip:2016@ltp.ath.cx;user=phone>;tag=b90a48c4-8d74-38fb-b767-a3f72b9e4c6b
To: <sip:2013@ltp.ath.cx;user=phone>;tag=as165980d9
Contact: <sip:2016@192.168.0.4;user=phone>
Proxy-Authorization: DIGEST username="2016", realm="asterisk", algorithm=MD5, uri="sip:2013@194.237.110.162", nonce="124a8b44", response="61e75d8b8ef19bd0dbdcb73607755154"
Call-ID: 938bb926-70a9-a83a-7a9a-88c9a03a5dde@192.168.0.4
CSeq: 16530 INFO
User-Agent: Grandstream SIP UA 1.0.4.17
Max-Forwards: 70
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, INFO, SUBSCRIBE
Content-Type: application/dtmf-relay
Content-Length: 22

Signal=5
Duration=640
13 headers, 2 lines
Receiving DTMF!
DTMF received: '5'
Transmitting (NAT):
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.0.4;received=212.73.172.237
From: <sip:2016@ltp.ath.cx;user=phone>;tag=b90a48c4-8d74-38fb-b767-a3f72b9e4c6b
To: <sip:2013@ltp.ath.cx;user=phone>;tag=as165980d9
Call-ID: 938bb926-70a9-a83a-7a9a-88c9a03a5dde@192.168.0.4
CSeq: 16530 INFO
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:2013@194.237.110.162>
Content-Length: 0


to 212.73.172.237:32784
set_destination: Parsing <sip:2013@192.168.0.6;user=phone> for address/port to send to
set_destination: set destination to 192.168.0.6, port 5060
Reliably Transmitting:
INFO sip:2013@192.168.0.6 SIP/2.0
Via: SIP/2.0/UDP 194.237.110.162:5060;branch=z9hG4bK244d03a2
From: "2016" <sip:2016@194.237.110.162>;tag=as0549a40c
To: <sip:2013@212.73.172.237:32787>;tag=1bb61662-7a41-af2e-e2db-a5f2ba39e105
Contact: <sip:2016@194.237.110.162>
Call-ID: 43382fb65be435eb4e6dcb0914e9d34e@194.237.110.162
CSeq: 103 INFO
User-Agent: Asterisk PBX
Content-Type: application/dtmf-relay
Content-Length: 24

Signal=5
Duration=250
(NAT) to 212.73.172.237:32787
Retransmitting #1 (NAT):
INFO sip:2013@192.168.0.6 SIP/2.0
Via: SIP/2.0/UDP 194.237.110.162:5060;branch=z9hG4bK244d03a2
From: "2016" <sip:2016@194.237.110.162>;tag=as0549a40c
To: <sip:2013@212.73.172.237:32787>;tag=1bb61662-7a41-af2e-e2db-a5f2ba39e105
Contact: <sip:2016@194.237.110.162>
Call-ID: 43382fb65be435eb4e6dcb0914e9d34e@194.237.110.162
CSeq: 103 INFO
User-Agent: Asterisk PBX
Content-Type: application/dtmf-relay
Content-Length: 24

Signal=5
Duration=250

to 212.73.172.237:32787
11 headers, 0 lines

*snip*

Retransmitting #2 (NAT):
INFO sip:2013@192.168.0.6 SIP/2.0
Via: SIP/2.0/UDP 194.237.110.162:5060;branch=z9hG4bK244d03a2
From: "2016" <sip:2016@194.237.110.162>;tag=as0549a40c
To: <sip:2013@212.73.172.237:32787>;tag=1bb61662-7a41-af2e-e2db-a5f2ba39e105
Contact: <sip:2016@194.237.110.162>
Call-ID: 43382fb65be435eb4e6dcb0914e9d34e@194.237.110.162
CSeq: 103 INFO
User-Agent: Asterisk PBX
Content-Type: application/dtmf-relay
Content-Length: 24

Signal=5
Duration=250

to 212.73.172.237:32787
Retransmitting #3 (NAT):
INFO sip:2013@192.168.0.6 SIP/2.0
Via: SIP/2.0/UDP 194.237.110.162:5060;branch=z9hG4bK244d03a2
From: "2016" <sip:2016@194.237.110.162>;tag=as0549a40c
To: <sip:2013@212.73.172.237:32787>;tag=1bb61662-7a41-af2e-e2db-a5f2ba39e105
Contact: <sip:2016@194.237.110.162>
Call-ID: 43382fb65be435eb4e6dcb0914e9d34e@194.237.110.162
CSeq: 103 INFO
User-Agent: Asterisk PBX
Content-Type: application/dtmf-relay
Content-Length: 24

Signal=5
Duration=250

to 212.73.172.237:32787

edited on: 01-14-04 07:54
By: fcs_1 (fcs_1) 2004-01-14 08:28:10.000-0600

Do you have Early Dial set to yes ?
GS config:
Early Dial:    No      Yes (use "Yes" only if proxy supports 484 response)  

I have it set to NO, I do not have the problem you are having with 1.0.4.30.  I have senddtmf=INFO

edited on: 01-14-04 08:14
By: z_smurf (z_smurf) 2004-01-14 09:49:57.000-0600

I have Early Dial set to No.

I have three gs-phones vith versions 1.0.4.17, 1.0.4.30 and 1.0.4.39.
All of them makes asterisk hangup (after a few seconds) because none of them answers to asterisks "INFO - hello phone, here comes a digit to you!".

I dont think you understand that the problem only occurs when asterisk forwards the digits from ome gs-phone to another.
By: fcs_1 (fcs_1) 2004-01-14 10:11:37.000-0600

z_smurf: correct I did not understand your report.  It was not clear to meyou setup a call before dialing digits.  I have the same result with 1.0.4.30 as well as 1.0.4.17.  Two GS phones A-party in conversation with B-party.  Press any digits on the key pad you hear digits on the other phone then the call will drop.  Dialing # received transfer prompt and completed transfer.

In the verbose console ouput it complains:
chan_sip.c:2365 __transmit_response: unable to determine sequence number from ''
By: z_smurf (z_smurf) 2004-01-14 10:27:56.000-0600

Further research, the phone upgraded to 1.0.4.30 acts really wierd now...
I am not sure if this is GS, Netgear och Asterisk-issue, but when calling another gs-phone from 1.0.4.30, this will appear in the log, and then the line is cut.
Anyone else experiencing the same?

Jan 14 16:53:42 WARNING[5126]: File chan_sip.c, Line 480 (retrans_pkt): Maximum retries exceeded on call 42ef90ee38d722c8@192.168.0.4 for seqno 26860 (Response)
Jan 14 16:53:42 WARNING[5126]: File chan_sip.c, Line 2375 (__transmit_response): Unable to determine sequence number from ''
Jan 14 16:53:42 WARNING[5126]: File chan_sip.c, Line 2375 (__transmit_response): Unable to determine sequence number from ''
Jan 14 16:53:42 WARNING[5126]: File chan_sip.c, Line 2375 (__transmit_response): Unable to determine sequence number from ''
Jan 14 16:53:42 WARNING[5126]: File chan_sip.c, Line 2375 (__transmit_response): Unable to determine sequence number from ''


Further, then this has happend to Asterisk, it has forgotten that 1.0.4.30-phone is a NAT-phone, so asterisk tries to send everything to a local IP.

Is there any more detailed way to see what information asterisk has about each sip-extensions than "sip show peers"?

//Andreas
By: z_smurf (z_smurf) 2004-01-14 13:18:30.000-0600

I believe this problem can be solved by configuration:

in sip.conf, set dtmfmode=rfc2833 on all GS-phones and you may press digits during the call as you please, no more hangup will occur.

Please note, you must still have "Send DTMF" to "via SIP INFO" in the phones setup.

Voicemail will still work as expected.

Please can anyone confirm this?
By: fcs_1 (fcs_1) 2004-01-14 15:03:54.000-0600

z_smurf: With the latest CVS I can not hold a conversation with two GS phones. I am getting the failure without hitting any dtmf digits.

Your suggested change above does not fix the problem.


It also looks like any call with a GS in the mix.  I justed called SPA2000 analog from the GS BT102 and the conversation terminated just like it used to only when I pressed the dtmf keys.

edited on: 01-14-04 14:55
By: z_smurf (z_smurf) 2004-01-14 16:51:45.000-0600

fcs_1:
I cannot hold a conversation if a call starts from gs 1.0.4.30, but it works if call starts from version 1.0.4.17 and 1.0.4.39.
Too bad I cannot find where to download 1.0.4.39, though this issue seems to be solved there.

While debuging this, I see that the root of this issue once again is that the GS does not reply on asterisk "200 OK"-messages. Asterisk expects an "ACK" from the phone.

I am not sure, but I think that an option in asterisk saying "dont expect replies on 200-ok-messages" would be great.
By: fcs_1 (fcs_1) 2004-01-14 17:06:01.000-0600

z_smurf: I was working fine execpt for DTMF disconnect prior to CVS update last night or maybe today not sure which cvs broke.  I know I saw 200 OK and ACK messages using 1.0.4.30.
By: fcs_1 (fcs_1) 2004-01-15 07:05:53.000-0600

Can the priority of this bug be raised to determine if it is * or GS ?  This problem currently makes GS phones unuseable with current firmware 1.0.4.30.
By: z_smurf (z_smurf) 2004-01-16 03:54:27.000-0600

I have tested to upgrade/downgrade between 1.0.4.18 and 1.0.4.30.
The 1.0.4.18 SOMETIMES answers with an ACK on the "SIP/2.0 200 OK", sometimes not. (Mostly after reboot, the ack does not work?)
When not, the call will hang up in a few seconds.
1.0.4.30 does not ever answers with an ACK.

Also found this link:
http://mail.iptel.org/pipermail/serusers/2003-December/004555.html

So, this is an GS-issue, but since GS seems to be quite unsatble at the moment, I would really like to introduce some special threatment in * to be GS-friendly.

If I succeed, Ill come up with an patch.
By: fcs_1 (fcs_1) 2004-01-16 05:43:45.000-0600

I think the ability to add some special case logic for any phone seems to be a good idea. All of the vendors seem to have differing ideas on implementing the specs. It would be a grand idea to have the * SIP implementation use an XML file for the transactions mapping for each phone type, software version.  Then if a phone gets off course one could change the expected sequence for that phone.

I don't know why my 1.0.4.30 was at least having conversation with out drops until CVS changes sometimes after Monday. I have my * in a DMZ and GS in the private network and I was watching 200 ok and Acks.  But maybe the acks were for a different reason then your looking at.  I am no expert on SIP.  Also the link above mentions that if they did not use port 5060 they saw the problem.  All of my ports on all of my phones and * are 5060 for tcp/udp inital contact.

I did receive from GS 1.0.4.39 but have not had a chance to try it to see if it fixes the problem. Let you know.
By: fcs_1 (fcs_1) 2004-01-17 08:32:54.000-0600

I have loaded firmware 1.0.4.39 beta into two bt102 telephones.  It made a major difference and I have had calls 1.5hrs long between the two phones.  I have not looked at all the SIP messages etc nor have I tested every feature.  

The following from GS Technical Support
"1.0.4.39, as with other beta firmware, reflects our hard work to try to fix the reported bugs.  But as they have not passed our QA test, we have not published them as official release.  As a result, we certainly welcome technically savvy users to try the new firmware and give us feedbacks so we can further improve our firmware but other ordinary users may not feel comfortable to try and do the diagnostic/troubleshooting jobs."

I have attached file b13p4.39.zip to this bug.

edited on: 01-17-04 15:21

edited on: 01-17-04 15:22
By: z_smurf (z_smurf) 2004-01-17 10:34:34.000-0600

Ah great...
My debugging has shown that the problem that phones hung up after 5 sec was related to a flaw in GS that it did not repond to some SIP-messages.
I found that you cound configure * to send different messages (type=friend or type=peer in sip.conf), and if type=peer on the called peer, the calling phone correctly ACK...
Never mind, there is no need to dig deeper if 1.0.4.39 solves this.
By: z_smurf (z_smurf) 2004-01-17 10:35:09.000-0600

http://www.cngpros.com/b13p4.39.zip is a 0 byte size file :-(
By: fcs_1 (fcs_1) 2004-01-17 11:27:54.000-0600

Sorry fixed now.  Unzip the file and load into your tftp and boot your GS phone that points to this version.

edited on: 01-17-04 11:14
By: z_smurf (z_smurf) 2004-01-17 12:24:57.000-0600

Ok, 1.0.4.39 tested. Problem is not solved.
ACK is still randomly missing in some circumstances.
This version works just as well as 1.0.4.18 does.
By: fcs_1 (fcs_1) 2004-01-17 14:02:57.000-0600

Well like I said I did not review all the SIP transations.  All I know that My * box is in a DMZ, My GS phones are on the protected LAN and I have conversation with no errors reported and tha call is not dropping like before.  Maybe you can report bug to GS support@grandstream.com

I have noticed that the GS phone that makes the call sends an ACK when the call is answered by the b-party and in conversation.  I have watched about 6 calls and everytime the GS phone initiated the call it also sends an ACK but does not send an ACK if it receives the call.

edited on: 01-17-04 15:10
By: Brian West (bkw918) 2004-01-21 01:16:24.000-0600

ok is your asterisk box talking to phones outside of the local network.  Even if your asterisk box is in the DMZ its still going thru NAT.
By: z_smurf (z_smurf) 2004-01-21 04:16:29.000-0600

I saw something that may explain all this...

Sometime the GS sends a extra INFO-sip-packet in the middle of another transaction , with the SAME seq-number as current transaction...

For example,
* --> gs  SIP180 Ringing...  seq 1
gs --> * INFO blah blah .. .seq 1 (for example, info about a key pressed)
gs --> * SIP200 OK... seq 1 (referring to 180 ringing)
* --> GS ACK blah blah ... seq 1 (referring to INFO)

Now, because the GS has already given a SIP200 OK on SEQ 1, it wont send it again, but I thinl * expects a 200OK on its latest packet...

I believe the GS really should have another seq on its INFO-packet, but it does not... So maybe *  could be changed to not expect double 200OK at the same SEQ?
By: fcs_1 (fcs_1) 2004-01-21 06:44:13.000-0600

z_zmurf: I don't know the SIP protocol very well but should the GS be sending a 200OK on Ringing or the ACK or both ? Do you know when seq numbers are supposed to start over ? Like would INVITE be a seq number 1, but since INFO would not be part of the INVITE seq of messages it could be a new first seq number for an INFO seq of transactions ? If two transaction sequences are legal at the sametime independent of each other then each device must follow the seq number seq per the transaction set. Is this correct or not ?

bkw918: yes * in DMZ, GS phones are on my local LAN behind the firewall but GS phones show (Software Version: Program--1.0.4.39 Bootloader--1.0.0.13 HTML--1.0.0.20  detected firewall/NAT type is open Internet)
By: jrollyson (jrollyson) 2004-01-24 16:12:58.000-0600

I think this is still entirely GS brokenness. 1.0.4.17 and 1.0.4.18 firmwares don't seem to exhibit this problem, at least not in my testing.
By: z_smurf (z_smurf) 2004-01-24 20:39:05.000-0600

You can make this crash every time on all versions of GS-firmwares (even 1.0.4.18) if you try this:

1) two sip-phones, both set to send dtmf via SIP-info.
2) The same in sip.conf (dtmf=info on both peers)
3) Dial from peer 1 to 2. Answer the call.
4) On any of the phones, press a digit. Now, Asterisk *WILL* hung up after 5 seconds. Every time. Due to lack of response to an sip info-packet.
By: z_smurf (z_smurf) 2004-01-24 20:40:37.000-0600

jrollyson: Download my patch about sip-debug[peer], and set to debug only one of your GS-phones with the scenario above, and you will get a clear picture of what really is happening.
By: z_smurf (z_smurf) 2004-01-25 20:51:58.000-0600

I've proveded a patch that disables the "183 Progress" message.
With this patch, and the correct settings in sip.conf (dtmfmode=rfc2833 on every GS-phone), there is no more known suspicious hangups on the GS-phones.

Plsease see the debug-outputs "call_fail.txt" and "call_success.txt". The first is when * sends a 183 and GS ignores that, the second is without 183.

This patch is not ment to be in CVS, but I think we can mark this case as SOLVED now, and just wait and see if GS comes up with a firmware that comunicates to us without any patches.
By: robertm (robertm) 2004-01-26 09:38:30.000-0600

I have made a patch to add a bugfix option to sip.conf to allow this function to be turned on and off am still testing. First try seemed to work but I want to test a few other things first.

Would anyone else like to take a look at this. But I warn you my C is lacking at times. If so I will post up a patch later today
By: robertm (robertm) 2004-01-26 15:05:26.000-0600

After doing alot of checking this is what I came up with. I have my GS phone defined as such in sip.conf Am using CVS-1/26/04-2:14:13. Not using any patch

[600]
type=friend
username=603
secret=603
host=dynamic
mailbox=603
dtmfmode=rfc2833
canreinvite=no

The phones are configured to use info for DTMF output. With this configuration I dont get any dropouts from keypad use.
By: z_smurf (z_smurf) 2004-01-26 15:31:00.000-0600

robertm: Correct, the patch I uploaded is not for fixing the keypad-hangup you are talking about.
It is for fixing that GS-phones randomly misbehaves on sending "183 Call progress", which also makes the phones to hangup.
If you do not know how to see if you need the patch or not, just wait and see. Try call another GS from your GS, and then another NON-GS extensions, and then back to a GS extension again. Try keep each call for more than 15 seconds. Suddenly it will misbehave and drop a calls, I promise you :)

edited on: 01-26-04 17:45
By: Mark Spencer (markster) 2004-02-08 12:22:13.000-0600

You're not seriously suggesting that we not send 183 Session Progress in general because the grandstream occasionally blows up on it right?  I assume this is just a "here's a work around for people that need it" bug?
By: z_smurf (z_smurf) 2004-02-08 18:48:01.000-0600

Yep. Workaround for GS-users.
By: Mark Spencer (markster) 2004-02-08 23:42:09.000-0600

I'm resolving this as "not a bug" since it seems to be a grandstream issue.