[Home]

Summary:ASTERISK-07406: 'musicclass' setting is ignored in realtime sip table
Reporter:Adam Simpson (asimpson)Labels:
Date Opened:2006-07-27 10:30:23Date Closed:2007-03-07 12:44:23.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/DatabaseSupport
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) cli_debug.txt
Description:It does not seem to matter what you set musiconhold to for any sip user as asterisk always uses the 'default' musiconhold class when that sip user puts someone on hold.  When user A calls user B and user A tries to put user B on hold user B always hears the 'default' musiconhold.

If on the other hand you use the following dialplan:

344,1,SetMusicOnHold(classical)
344,1,Dial(SIP/UserB)

where user A calls user B and user B puts user A on hold, they will hear 'classical' music.  But if user A put user B on hold instead user B hears the 'default' music class even when both users have musiconhold=clasic in the sip table.  I was trying this using mysql drivers if that is relevant.



Comments:By: Russell Bryant (russell) 2006-07-27 13:09:34

The correct option name is "musicclass".  The option "musiconhold" does not exist anywhere in the sample sip.conf.  :)

Try renaming it to "musicclass" and see if that fixes your problem.
By: Adam Simpson (asimpson) 2006-07-27 14:56:27

Sorry, I tried that before submitting the issue but I should have made note of that in my description of the problem.  After switching the column to 'musicclass' in the sip table I still get the same problem.  If User A calls User B, and User B places the caller on hold, then you get the 'musicclass' defined in the sip table.  BUT if User A puts User B on hold asterisk always defaults to the 'default' music class rather than that defined in the sip table.  Using SetMusicOnHold(mymusicclass) before the Dial() statement seems to have no effect on the behaviour, I have tried it with and without using SetMusicOnHold() and get the same results.
By: Russell Bryant (russell) 2006-08-13 21:32:25

In the situation where A calls B, and A puts B on hold ... where do you have the musicclass option set?  Is it set for user B to something other than 'default' in the database?
By: Adam Simpson (asimpson) 2006-08-14 12:00:08

Yes, both users A and B have their musicclass set to 'classical' in the sip database table under the column 'musicclass'.
By: Joshua C. Colp (jcolp) 2006-09-07 22:55:12

Confirm using sip show peer and show channel the musicclass being used if this is still an issue.
By: Serge Vecher (serge-v) 2006-09-27 14:01:58

please reopen, if you are able to reproduce in 1.2.12.1 and confirm the issue as requested.
By: Adam Simpson (asimpson) 2006-09-27 15:56:15

I just tried it with 1.2.12.1 and it is still happening.  I am using a mysql database which has all the sip users and rtcachefriends=yes in sip.conf.
By: Serge Vecher (serge-v) 2006-09-28 09:47:26

ok, please show the output of 'sip show peer A/b' and 'show channel xxxx'

where xxxx is the channel name of A calling B. Thanks.
By: Adam Simpson (asimpson) 2006-10-04 11:20:46

I have uploaded a file cli_debug.txt which has the output that your requested from the CLI.  SIP User 100008 called SIP user 100001.  I have included both the 'sip show peer' of both of these users and the 'sip show channel' of the calling party (SIP User 100008).
By: Joshua C. Colp (jcolp) 2006-10-04 11:26:53

I actually meant "show channel" not "sip show channel" but that's okay... in 1.2 the way it works is that musiconhold specifies the class that you will hear if you are put on hold, not if you put someone else on hold. What we need to confirm is that the peer you are calling (UserB) has the correct music class set on their channel.
By: Adam Simpson (asimpson) 2006-10-04 12:14:15

Sorry, here is the correct information.  Again SIP user 100008 is calling SIP user 100001.

Connected to Asterisk 1.2.12.1 currently running on hd-t3636cl (pid = 22626)
Verbosity is at least 10
   -- Executing SetMusicOnHold("SIP/100008-08f68688", "1")
   -- Executing Dial("SIP/100008-08f68688", "SIP/100001&SIP/100006|24|r")
   -- Called 100001
Oct  4 13:11:55 NOTICE[2077]: app_dial.c:1056 dial_exec_full: Unable to create c                                                                             hannel of type 'SIP' (cause 3 - No route to destination)
   -- SIP/100001-08f50e70 is ringing
   -- SIP/100001-08f50e70 answered SIP/100008-08f68688
   -- Attempting native bridge of SIP/100008-08f68688 and SIP/100001-08f50e70
hd-t3636cl*CLI> show channel SIP/100008-08f68688
-- General -->
          Name: SIP/100008-08f68688
          Type: SIP
      UniqueID: 1159981915.48
     Caller ID: 225
Caller ID Name: Nancy Bates
   DNID Digits: 289
         State: Up (6)
         Rings: 0
  NativeFormat: 4
   WriteFormat: 4
    ReadFormat: 4
1st File Descriptor: 29
     Frames in: 856
    Frames out: 853
Time to Hangup: 0
  Elapsed Time: 0h0m19s
 Direct Bridge: SIP/100001-08f50e70
Indirect Bridge: SIP/100001-08f50e70
--   PBX   --
       Context: internal-1
     Extension: 289
      Priority: 2
    Call Group: 1
  Pickup Group: 0
   Application: Dial
          Data: SIP/100001&SIP/100006|24|r
   Blocking in: ast_waitfor_nandfds
     Variables:
BRIDGEPEER=SIP/100001-08f50e70
DIALEDPEERNUMBER=100001
DIALEDPEERNAME=SIP/100001-08f50e70
SIPCALLID=d60b6b016bb92a28@192.168.2.11
SIPUSERAGENT=Grandstream GXP2000 1.1.0.16
SIPDOMAIN=sipproxy1.easyofficephone.com
SIPURI=sip:100008@65.92.51.122:60478

 CDR Variables:
level 1: clid="Nancy Bates" <225>
level 1: src=225
level 1: dst=289
level 1: dcontext=internal-1
level 1: channel=SIP/100008-08f68688
level 1: dstchannel=SIP/100001-08f50e70
level 1: lastapp=Dial
level 1: lastdata=SIP/100001&SIP/100006|24|r
level 1: start=2006-10-04 13:11:55
level 1: answer=2006-10-04 13:11:57
level 1: end=2006-10-04 13:11:57
level 1: duration=0
level 1: billsec=0
level 1: disposition=ANSWERED
level 1: amaflags=BILLING
level 1: accountcode=1
level 1: uniqueid=1159981915.48

hd-t3636cl*CLI>
By: YLB (ylebihan) 2006-10-11 03:53:51

Hello, :)

I got the same matter. I'm currently running 1.2.12.1 with extensions.conf like this:

[toto-internal]
exten => 601,1,Answer
exten => 601,2,SetMusicOnHold(toto)
exten => 601,3,Dial(SIP/sr601,20,t)
exten => 601,4,Voicemail(u601@toto)
exten => 601,5,Hangup

[toto-out]
exten => _0[1-6].,1,SetMusicOnHold(toto)
exten => _0[1-6].,2,Dial(SIP/${EXTEN}@toto-out1,240,j)
exten => _0[1-6].,3,Hangup
exten => _0[1-6].,103,Busy

When someone calls *, it's sent to 601 and gets "toto" moh when put on hold.
But when * calls someone outside (using the "toto-out" context to reach the PSTN via our SIP operator), like 0123456789, there's no way to get the "toto" moh: it's always "default" moh, which is played! :-/ any idea?...

(of course, the sip entry for "toto-out1" is set with musicclass=toto in sip.conf...)
By: jmls (jmls) 2006-11-08 05:39:38.000-0600

ping. housekeeping. I know that MOH has changed in 1.4 / trunk, but is this a confirmed / fixabe bug in 1.2.xx ?
By: Adam Simpson (asimpson) 2006-11-08 07:49:30.000-0600

Yes this is a confirmed bug, its easy to reproduce.  How easy it is to fix, I am not sure.  I have not tested to see if this bug exists under 1.4 yet, I but I will check.
By: Russell Bryant (russell) 2006-11-13 14:53:57.000-0600

I have no idea why this was assigned to me.  This bug is reported against Asterisk 1.2, which means it has nothing to do with my recent rework of musiconhold signalling for 1.4.  I very busy with school right now, and there are many developers just as capable as me in testing and resolving this issue.
By: Olle Johansson (oej) 2007-02-14 15:06:44.000-0600

Is this still a problem in the latest 1.2?
By: Serge Vecher (serge-v) 2007-03-07 12:44:22.000-0600

no response for almost a month. If still reproducible with 1.2.16, please reopen the issue.