ASTERISK-05713: AgentCallbackLogin and SIP hold music doesn't work in user to agent direction.

[Home]

Summary: ASTERISK-05713: AgentCallbackLogin and SIP hold music doesn't work in user to agent direction.

Reporter: tyler (tyler) Labels:

Date Opened: 2005-11-25 20:03:44.000-0600 Date Closed: 2007-07-23 13:13:57

Priority: Minor Regression? No

Status: Closed/Complete Components: Resources/res_musiconhold

Versions: Frequency of
Occurrence

Related
Issues:

Environment: Attachments:

Description: I have a queue with agents that are callback agents using SIP phones. When a caller calls into the queue they hear the hold music just fine, however once connected to an agent, if the caller puts the agent on hold, the following scrolls on the console:

Nov 25 21:01:59 WARNING[19738]: chan_sip.c:2520 sip_write: Asked to transmit frame type 64, while native formats is 4 (read/write = 4/4)
Nov 25 21:01:59 WARNING[19738]: chan_sip.c:2520 sip_write: Asked to transmit frame type 64, while native formats is 4 (read/write = 4/4)
Nov 25 21:01:59 WARNING[19738]: chan_sip.c:2520 sip_write: Asked to transmit frame type 64, while native formats is 4 (read/write = 4/4)
Nov 25 21:01:59 WARNING[19738]: chan_sip.c:2520 sip_write: Asked to transmit frame type 64, while native formats is 4 (read/write = 4/4)
Nov 25 21:01:59 WARNING[19738]: chan_sip.c:2520 sip_write: Asked to transmit frame type 64, while native formats is 4 (read/write = 4/4)
Nov 25 21:01:59 WARNING[19738]: chan_sip.c:2520 sip_write: Asked to transmit frame type 64, while native formats is 4 (read/write = 4/4)
Nov 25 21:01:59 WARNING[19738]: chan_sip.c:2520 sip_write: Asked to transmit frame type 64, while native formats is 4 (read/write = 4/4)

-- over and over, many lines per second. The music on hold is coming from madplay, not the mpg123 default. It works everywhere else. This problem does NOT happen if I add the agents as static members (ie, member => Local/100@agents/n, etc).. The hold music works fine in this case.

Comments: By: Kevin P. Fleming (kpfleming) 2005-12-12 20:41:47.000-0600

Please provide a complete console trace of the call being placed and answered and then placed on hold. We can't really diagnose this issue without all the details requested in the bug posting guidelines.
By: Olle Johansson (oej) 2006-01-04 14:40:20.000-0600

No feedback from the reporter. Please re-open when you have traces to upload. Thank you!

/O
By: Serge Vecher (serge-v) 2006-12-01 10:31:34.000-0600

dmb reports that he can reproduce the issue and will attach the debug information shortly.
By: Joshua C. Colp (jcolp) 2007-01-22 20:10:26.000-0600

Yet again... no information here to help with this issue. If it becomes available please reopen and attach. Thanks!
By: Olle Johansson (oej) 2007-07-20 05:18:26

Re-opening on request from kaou on IRC.
By: Corentin Le Gall (clegall_proformatique) 2007-07-20 05:51:01

I encounter the same problem as the one described here.

This happens both in Asterisk 1.2 and Asterisk 1.4 versions (revision 76031).

Jul 20 11:14:42 WARNING[30738]: chan_sip.c:2587 sip_write: Asked to transmit frame type 64, while native formats is 8 (read/write = 8/8)

-------------------------------------------------------------------

the setup is rather simple :
* 2 phones 101 and 102
* 102 registers as an agent with 5102 phone code
* 101 calls 5102 through its dialplan
* 102 answers
* if 102 (the Agent) holds the call, 101 (the User) hears the music
* if 101 holds the call, 102 hears nothing and the above message is displayed

-------------------------------------------------------------------

What I found up to now :

* in the Agent to User direction (working case), the ast_set_write_format() function is called once, and sets the writetrans field of the channel, then the subclass of the frame is set to 8 in chan_sip.

* in the User to Agent direction (not working case), this function is called twice : the first one does the same as in A->U, while the second one sets this writetrans field to NULL. The subclass of the frame in chan_sip is then 64 (SLINEAR), which leads to the above warning.
So why is this variable NULL this 2nd time ? the relevant ast_set_write_format() is called by the CHECK_FORMAT #defined in res_musiconhold.c (lines 222 and 223 in chan_agent.c (svn 74719, branch 1.2)) :
if (p->chan->writeformat != ast->rawwriteformat) { \
ast_set_write_format(p->chan, ast->rawwriteformat); \
Since ast->rawwriteformat = 8 here, the previous "need for translation" is canceled.

If I remove these 2 lines, my music plays fine in both directions, but I guess they have been written on purpose. What could be done to cover all the use cases ?
By: Digium Subversion (svnbot) 2007-07-23 13:11:04

Repository: asterisk
Revision: 76653

------------------------------------------------------------------------
r76653 | file | 2007-07-23 13:11:04 -0500 (Mon, 23 Jul 2007) | 4 lines

(closes issue ASTERISK-5713)
Reported by: tyler
Do not force channel format changes when a generator is present. The generator may have changed the formats itself and changing them back would cause issues.

------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-07-23 13:12:39

Repository: asterisk
Revision: 76654

------------------------------------------------------------------------
r76654 | file | 2007-07-23 13:12:39 -0500 (Mon, 23 Jul 2007) | 12 lines

Merged revisions 76653 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2

........
r76653 | file | 2007-07-23 15:28:13 -0300 (Mon, 23 Jul 2007) | 4 lines

(closes issue ASTERISK-5713)
Reported by: tyler
Do not force channel format changes when a generator is present. The generator may have changed the formats itself and changing them back would cause issues.

........

------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-07-23 13:13:57

Repository: asterisk
Revision: 76655

------------------------------------------------------------------------
r76655 | file | 2007-07-23 13:13:56 -0500 (Mon, 23 Jul 2007) | 20 lines

Merged revisions 76654 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

................
r76654 | file | 2007-07-23 15:29:48 -0300 (Mon, 23 Jul 2007) | 12 lines

Merged revisions 76653 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2

........
r76653 | file | 2007-07-23 15:28:13 -0300 (Mon, 23 Jul 2007) | 4 lines

(closes issue ASTERISK-5713)
Reported by: tyler
Do not force channel format changes when a generator is present. The generator may have changed the formats itself and changing them back would cause issues.

........

................

------------------------------------------------------------------------