[Home]

Summary:ASTERISK-03729: [request] xfersound = beep for SIP transfers
Reporter:cherso (cherso)Labels:
Date Opened:2005-03-21 10:05:42.000-0600Date Closed:2005-04-04 23:38:24
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Is there a way to implement something similar to xfersound = beep (to indicate an attended transfer is complete) on a SIP channel transfer?

Maybe with a SetVar(SIPTRANSFERBEEP,1)?
Comments:By: Olle Johansson (oej) 2005-03-21 10:13:13.000-0600

Please file requests in the Feature requests category, thank you!
By: Mark Spencer (markster) 2005-03-21 22:26:15.000-0600

A SIP transfer has no delay to when it occurs.  What's the point?
By: Michael Jerris (mikej) 2005-03-21 22:35:38.000-0600

kpflemming and I spoke about this.  If using the transfer button from a sip phone, there is no way for * to do this as the chan to the phone is dropped.  This would require changes to the sip specification.  This could probably be done on a # transfer, but I'm not sure what the point would be really, as you know it is transfered when your end of the call is blocked.
By: cherso (cherso) 2005-03-22 02:22:15.000-0600

In the asterisk users mailing list Martin Knipper said:
"Hi @all,
I have a question concerning bridging calls in asterisk.
Person A recieves a call fom Person X. Person X wants to talk to Person B. Person A starts contacting person B and introduces person X.
Person B now transfers the call and person X is directly connected to person B.
Is it possible to play a beep to person B, just before it gets connected to person A? We have lots of confusion when the bridge is established since person X does not notice, that the bridge is already active."

This is exactly the problem I have.

We can know when a SIP call is transferred, REFER header right?
for example, this is a transferred call flow.
Someone is calling from zap or capi to sip/1, sip/1 transfers (attended) the call to sip/2. Zap is hearing the music on hold. We know that the call is a transfer 'cause the REFER header. So we can play a beep to the channel that is not hearing the music on hold before stopping the music on the zap channel (the caller)

Mar 21 15:32:01 DEBUG[9808]: Outgoing Call for 2
Mar 21 15:32:01 VERBOSE[9808]:     -- Called 2
Mar 21 15:32:02 DEBUG[9757]: (Provisional) Stopping retransmission (but retaining packet) on '406bfb
4f731465225aafa5646eae019e@192.168.0.100' Request 102: Found
Mar 21 15:32:02 DEBUG[9757]: (Provisional) Stopping retransmission (but retaining packet) on '406bfb
4f731465225aafa5646eae019e@192.168.0.100' Request 102: Found
Mar 21 15:32:02 VERBOSE[9808]:     -- SIP/2-498b is ringing
Mar 21 15:32:04 DEBUG[9757]: Acked pending invite 102
Mar 21 15:32:04 DEBUG[9757]: Stopping retransmission on '406bfb4f731465225aafa5646eae019e@192.168.0.
100' of Request 102: Found
Mar 21 15:32:04 DEBUG[9757]: build_route: Contact hop: <sip:2@192.168.0.102:5060>
Mar 21 15:32:04 VERBOSE[9808]:     -- SIP/2-498b answered SIP/1-a328
Mar 21 15:32:04 VERBOSE[9808]:     -- Attempting native bridge of SIP/1-a328 and SIP/2-498b
Mar 21 15:32:04 DEBUG[9757]: Stopping retransmission on '001192d9-8307002a-0846c906-00b2aef1@192.168
.0.101' of Response 102: Found
Mar 21 15:32:12 VERBOSE[9757]:     -- Started music on hold, class 'default', on SIP/2-498b
Mar 21 15:32:12 DEBUG[9757]: Scheduling timer at 160 sample intervals
Mar 21 15:32:12 DEBUG[9808]: Generator got voice, switching to phase locked mode
Mar 21 15:32:12 DEBUG[9808]: Scheduling timer at 0 sample intervals
Mar 21 15:32:12 DEBUG[9757]: Stopping retransmission on '001192d9-8307002a-0846c906-00b2aef1@192.168
.0.101' of Response 103: Found
Mar 21 15:32:12 DEBUG[9757]: We found a REFER!
Mar 21 15:32:12 DEBUG[9757]: Assigning Replace-Call-ID Info 001192d9-8307002a-0846c906-00b2aef1@192.
168.0.101 to REPLACE_CALL_ID
Mar 21 15:32:12 DEBUG[9757]: 202 Accepted (supervised)
Mar 21 15:32:12 VERBOSE[9757]:     -- Stopped music on hold on Zap/2-1
Mar 21 15:32:12 DEBUG[9757]: Scheduling timer at 0 sample intervals
Mar 21 15:32:12 VERBOSE[9757]:     -- Stopped music on hold on SIP/2-498b
Mar 21 15:32:12 DEBUG[9757]: Scheduling timer at 0 sample intervals
Mar 21 15:32:12 DEBUG[9757]: Planning to masquerade Zap/2-1 into the structure of SIP/1-a328
Mar 21 15:32:12 DEBUG[9757]: Done planning to masquerade SIP/1-a328 into the structure of Zap/2-1
Mar 21 15:32:12 DEBUG[9808]: Actually Masquerading Zap/2-1(6) into the structure of SIP/1-a328(6)
Mar 21 15:32:12 DEBUG[9808]: Got clone lock on 'Zap/2-1' at 0x8116d2c
Mar 21 15:32:12 DEBUG[9808]: update_user_counter(1) - decrement inUse counter
Mar 21 15:32:12 DEBUG[9808]: Putting channel Zap/2-1 in 8/8 formats
Mar 21 15:32:12 DEBUG[9808]: New owner for channel 2 is Zap/2-1
Mar 21 15:32:12 DEBUG[9808]: Updated conferencing on 2, with 0 conference users
Mar 21 15:32:12 DEBUG[9808]: Updated conferencing on 2, with 0 conference users
Mar 21 15:32:12 DEBUG[9808]: Released clone lock on 'SIP/1-a328<ZOMBIE>'
Mar 21 15:32:12 DEBUG[9808]: Done Masquerading Zap/2-1 (6)
Mar 21 15:32:12 DEBUG[9807]: Didn't get a frame from channel: SIP/1-a328<ZOMBIE>
Mar 21 15:32:12 DEBUG[9807]: Bridge stops bridging channels SIP/1-a328<ZOMBIE> and SIP/1-0fd9
Mar 21 15:32:12 DEBUG[9807]: update_user_counter(1) - decrement inUse counter
Mar 21 15:32:12 DEBUG[9807]: Exiting with DIALSTATUS=ANSWER.

edited on: 03-22-05 07:55
By: Kevin P. Fleming (kpfleming) 2005-03-22 08:39:47.000-0600

So you want the "xfersound" to be played to the _recipient_ of the transfer before they are bridged to the caller?
By: cherso (cherso) 2005-03-22 11:39:02.000-0600

yes, because I can't know when the bridge is established so I don't know when I have to say: "Hello Mr. X" :-)

can we add xfersound = beep to sip.conf?

Should be good to have a variable to activate or deactivate the xfersound in the dialplan so I can decide to get it on for internal transfers (outside -> secretary phone -> my phone with a beep) and off for external transfer (me->secretary-> mr. X no beep required)
By: cherso (cherso) 2005-03-26 04:43:25.000-0600

Can you please take a look to this code?
It is working, but I get a warning message
Mar 26 11:38:53 WARNING[16898]: channel.c:1022 ast_waitfor_nandfds: Thread 147465 Blocking 'SIP/2-e312', already blocked by thread 213005 in procedure ast_waitfor_nandfds

handle_request function
if (!ignore) {
if (p->refer_call) {
ast_log(LOG_DEBUG,"202 Accepted (supervised)\n");
c = p->refer_call->owner;
transfer_to = ast_bridged_channel(c);
ast_log(LOG_NOTICE, "Transfer to %s\n",transfer_to->name);
attempt_transfer(p, p->refer_call);
if (p->refer_call->owner)
ast_mutex_unlock(&p->refer_call->owner->lock);
ast_mutex_unlock(&p->refer_call->lock);
p->refer_call = NULL;
ast_set_flag(p, SIP_GOTREFER);

if (transfer_to) {
/* transfer_to = ast_bridged_channel(c); */
ast_log(LOG_WARNING, "Playing courtesy tone on %s\n",transfer_to->name);
if (!ast_strlen_zero(xfersound) && !ast_streamfile(transfer_to, xfersound, transfer_to->language)) {
if (ast_waitstream(transfer_to, "") < 0) {
ast_log(LOG_WARNING, "Failed to play courtesy tone!\n");
}
}
ast_stopstream(transfer_to);
}


} else {
ast_log(LOG_DEBUG,"202 Accepted (blind)\n");
By: Kevin P. Fleming (kpfleming) 2005-03-31 15:06:02.000-0600

No, that will not work properly. When you are processing the REFER, there are already threads listening and handling media (audio) traffic for the channels involved, so you can't just jump onto the channel and play audio.

Doing this properly will be quite involved... If you are really interested in getting it done, you should probably post a bounty on the wiki and see if one of the developers who know this code can help you get it done.
By: cherso (cherso) 2005-04-01 03:23:56.000-0600

It's ok.
I've changed my mind about it. I'm using the sip_senddigit to play a DTMF beep on transfer. This is fast and a really clean solution.
Maybe that is usefull for other users.
I'm planning to add dtmfbeepontransfer = on to sip.conf to enable or disable it
I'm still having an issue on cisco 7960. It seems not to play incoming RFC2833 DTMF tones. The cisco 7905 is working good. That is why I was patching the ast_rtp_senddigit as reported in the bug http://bugs.digium.com/bug_view_page.php?bug_id=0003910

my quick patch to add this feature
                       if (!ignore) {
                               if (p->refer_call) {
                                       ast_log(LOG_DEBUG,"202 Accepted (supervised)\n");
                                       c = p->refer_call->owner;
                                       if (c) {
                                               transfer_to = ast_bridged_channel(c);
                                               if (transfer_to) {
                                                       ast_verbose(VERBOSE_PREFIX_3 "Beep on transf
er to %s\n",transfer_to->name);
                                                       sip_senddigit(transfer_to,'1');
                                               }
                                       }
                                       attempt_transfer(p, p->refer_call);
By: Kevin P. Fleming (kpfleming) 2005-04-01 10:05:22.000-0600

I have found a number of SIP phones do not play incoming DTMF, so this will not be a good general solution. Unless you (or someone else) can come up with a solution that works for a wide variety of SIP UACs, this cannot be merged into the tree :-(
By: Kevin P. Fleming (kpfleming) 2005-04-04 23:38:17

It's the consensus here that the difficulty in implementing this properly is not worth the small potential gain it would provide. The known problems are:

- you can't use senddigit() to send the tone, because some SIP phones won't play it, so you have to stream a file, which is much harder to do right

- for REFER transfers, it would be impossible to do properly, because Asterisk does not have a channel open to the transferee at the proper time