Summary: | ASTERISK-04885: Problems with forward when busy on using sip phones | ||
Reporter: | Knut-Håvard Aksnes (knut-haavard aksnes) | Labels: | |
Date Opened: | 2005-08-24 04:09:51 | Date Closed: | 2011-06-07 14:03:22 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | Core/Configuration |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) asterisklog ( 1) extensions.conf | |
Description: | I have made a small extensions.conf to ilustrate this problem. Four phones are needed to ilustrate the bug. I am using linphone for aparatus 1 and 2 and SNOM 360 and 320 for aparatus 3 and 4. The important point is that aparatus 1 reports busy when it is busy. Edit extensions.conf to match your sip.conf 1) Dial from phone 1 to phone 2 2) Answer phone 2 and leave it of hook. 3) Dial from phone 3 to phone 1. 4) At this point phone 4 is ringing and phone 1 is disconnected. The disconnect at point 4 is not what I intended and probably a nasty bug. In real life this hits me when impelmenting forward when busy. | ||
Comments: | By: Michael Jerris (mikej) 2005-08-24 04:16:46 As stated in the bug guidelines, please include a full sip debug of the call causing this problem, also include verbose in that debug please. By: Knut-Håvard Aksnes (knut-haavard aksnes) 2005-08-24 05:19:21 A small typo in the extensions.conf (Doesn't change the result) In line 25 substitute 4 for 3 as extension By: Knut-Håvard Aksnes (knut-haavard aksnes) 2005-08-24 05:41:54 The bug might be linphone spesific, I will ask them to have a look at the bugreport. By: Michael Jerris (mikej) 2005-08-24 08:52:41 can you reproduce the same issue using some other softphone or other device? By: Kevin P. Fleming (kpfleming) 2005-08-26 17:25:32 I seriously doubt this is a problem with Asterisk itself, people make SIP calls to busy phones all day long here at Digium and thousands of other places. If you can conclusively prove that this problem happens with SIP endpoints _other_ than linphone and that the problem is not in the endpoint itself, then reopen the bug with the requested debug traces. |