[Home]

Summary:ASTERISK-01429: During conversation of two sip agents on put other on hold, other can take it off hold by pressing hold.
Reporter:albor (albor)Labels:
Date Opened:2004-04-19 00:56:36Date Closed:2011-06-07 14:10:50
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) buglog3
Description:I am using two budge tone 100.
Phone A calls B. (OK)
B answers -> conversation started(OK)
A press hold -> B on hold (Ok)
B press hold -> B off hold (Bug)



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

In order to put on hold budge tone send INVITE with ip 0.0.0.0 to asterisk, which causes asterisk to switch "hold" to itself. The second hold from other side with 0.0.0.0 causes asterisk invite side which "first pressed hold" and removes hold. In case if reinvite enabled asterisk acts as if it is in the beginning of regular call and reinvites both sides with their IP addresses. As a result hold removed by the side which did not started it. :(
Comments:By: Brian West (bkw918) 2004-04-19 01:01:12

Ok this has got to be a crapstream issue becuase it doesn't happen that way on my 7960's.

bkw
By: Brian West (bkw918) 2004-04-19 01:03:31

Just double checked.. No bug here with 7960's with canreinvite=no


bkw
By: twisted (twisted) 2004-04-19 01:03:53

Please provide relevant sip debug for this..  Otherwise it sounds like a gs issue.
By: Mark Spencer (markster) 2004-04-19 10:56:17

It is almost definitely a grandstream issue, because our sending an INVITE does not change what their parameters are.  Using "canreinvite=no" will probably make theissue go away.  bkw_ can you test with canreinvite=yes?
By: Brian West (bkw918) 2004-04-19 11:41:48

Tried with can reinvite=yes it works fine

bkw
By: albor (albor) 2004-04-19 17:33:11

comments for log:
I believe
line 347 first hold
line 536 second hold

I agree that 7960 is better. It is also 4 times more expensive. I will work with GS people if you can point me what need to be changed in GS SIP stack.

Thanks,
Alex
By: Mark Spencer (markster) 2004-04-19 18:13:13

albor:

The bug is that the Grandstream should not consider the hold state to be removed when it gets a new invite from us.  it can just send us a 200 OK still with the 0.0.0.0 address if it wants to stay on hold.

as a place holder for the grandsteram fix, you should be able to use "canreinvite=no" and that should symptomatically fix it with the obvious performance hit that asterisk will continue to hold the media.

mark
By: Mark Spencer (markster) 2004-04-19 18:17:22

Going by the attached debug, Asterisk *must* send a new INVITE in order to activate the MOH.  That doesn't give any reason for the Grandstream to consider a change in the call state on its side.  So, I'm resolving this as "not a bug" but if you find any evidence in any RFC to the contrary feel free to reopen it.
By: albor (albor) 2004-04-19 19:50:49

Mark:

Let's call it a new feature.
1. A puts on hold B. A rx silence; B rx MOH
2. B puts on hold * (MOH). A rx silence; B rx silence
3. A removes hold. A rx MOH; B rx silence
4. B removes hold. Voice channel restored

I think that in this area asterisk and GS are not "Interoperable". I will try to work GS end, however after your explanation I think that it is Asterisk problem.

Alex
By: twisted (twisted) 2004-04-19 20:16:11

albor - I attempted to recreate your issue using a GS budgetone 100 series and my Cisco 7905.  If the problem was with Asterisk, as you stated, this scenario would have produced the same results:

I called my Cisco 7905G with the Grandstream Budgetone.  After answering the call with the Cisco, I placed the Cisco on Hold from the GS.  I then pressed the hold button on the Cisco, placing the GS phone on hold.  The GS was STILL on hold when I hit the hold button on the Cisco.  I removed the hold from the GS by pressing the hold button on the GS,removed the hold from the cisco, and resumed a conversation.  Then, For arguments sake, I placed the GS on hold from the cisco.  I then placed the Cisco on hold from the grandstream.  I released the hold from the Cisco, and I was still on hold from the grandstream.

In no way was I able to reproduce your results.  I Also attempted this test in the opposite direction.  (Called the GS from the Cisco).   The problem here is NOT with *, as it is operating according to RFC.    

I think the problem is with the GS firmware not wanting to deal with Invites to operate MOH.

edited on: 04-19-04 19:13
By: twisted (twisted) 2004-04-19 20:23:02

Using the above demonstration, I am using the following:

Product Model:
 BT100
Software Version:
 Program--1.0.4.50    Bootloader--1.0.0.14    HTML--1.0.0.22


Check your firmware revision, as the more recent firmware for GS fix a few issues.
By: albor (albor) 2004-04-19 21:16:18

twisted:

I tested with version
Program--1.0.4.17    Bootloader--1.0.0.11    HTML--1.0.0.19

I will get and test it with
Program--1.0.4.50 Bootloader--1.0.0.14 HTML--1.0.0.22

thank you

bkw918:

I think that "patriotism" cannot help in fixing bugs.  I think, that suggestions to send GS back to china is ill advise. I am surprised that I get such &ASTERISK-7999;support&ASTERISK-8000; recommendation. Global economy is a fact. It is hard to argue with that.

regards,
Alex
By: Brian West (bkw918) 2004-04-19 22:45:28

sorry didn't mean it like that.. I just dislike the product!

bkw
By: Mark Spencer (markster) 2004-04-19 22:48:40

albor: can you confirm that with reinvites disabled it works properly?
By: Brian West (bkw918) 2004-04-19 22:55:42

I looked at this closer and I don't see this in your debug output or something similar:

   -- Executing NoOp("SIP/10-719a", "") in new stack
   -- Executing Macro("SIP/10-719a", "stdexten|20|SIP/20") in new stack
   -- Executing Dial("SIP/10-719a", "SIP/20|20") in new stack
   -- Called 20
   -- SIP/20-1180 is ringing
   -- SIP/20-1180 answered SIP/10-719a
   -- Attempting native bridge of SIP/10-719a and SIP/20-1180
   -- Started music on hold, class 'default', on SIP/20-1180
   -- Started music on hold, class 'default', on SIP/10-719a
   -- Stopped music on hold on SIP/20-1180
   -- Started music on hold, class 'default', on SIP/20-1180
   -- Stopped music on hold on SIP/10-719a
   -- Stopped music on hold on SIP/20-1180
 == Spawn extension (macro-stdexten, s, 1) exited non-zero on 'SIP/10-719a' in macro 'stdexten'
 == Spawn extension (default, 20, 2) exited non-zero on 'SIP/10-719a'

This is with canreinvite=no
By: albor (albor) 2004-04-20 21:21:47

mark:
I checked canreinvite=no. Functionally works fine. If you need a trace I can capture it.

bkw918:

I know that I did not configure correctly music on hold for internal extensions.
It should not be a problem, should it?

Alex
By: Brian West (bkw918) 2004-04-20 21:23:58

It well it would be dead air but thats fine... :)  but seems something isn't right.. have you tried the new firmware that was released today.. someone was jumping up and down in #asterisk about it today.

bkw
By: twisted (twisted) 2004-04-26 10:01:42

Update?
By: Mark Spencer (markster) 2004-05-01 18:57:37

This is not an asterisk bug.