[Home]

Summary:ASTERISK-07242: [patch] A transfer SIP call present one way audio problem until hold and resume the call
Reporter:Fernando Romo (el_pop)Labels:
Date Opened:2006-06-27 17:18:51Date Closed:2006-09-01 12:39:32
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_sip.c.patch
( 1) debug1.txt
( 2) debug2.txt
( 3) sip_27062006.debug
Description:When the call is transfer (blind or supervised) the destination party ear the audio of the call, but the originator of the call can't ear the destination conversation.

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

Is a "one way audio" scenario, the only way to restablis the audio of the call is puting on hold the call and resume and the conversation work fine again.

I attach the SIP debug to see the protocol flow in the error.
Comments:By: Fernando Romo (el_pop) 2006-06-27 17:34:18

We are testing with Polycom, Aastra Phones and with X-pro Softphones, we note this problem initialy using Polycom IP600 phones and later using Aastra 480i phones.
By: Serge Vecher (serge-v) 2006-06-28 09:14:33

el_pop: something is stange with your log. Can you please make sure that verbose is set to 4, debug set 4 and, sip debug and capture this again from the console? Thanks.
By: Olle Johansson (oej) 2006-06-28 10:02:38

Please also document if you are using SIP transfer or Asterisk transfer.
By: Fernando Romo (el_pop) 2006-06-29 00:51:35

oej:

we are using SIP transfers. The scenario is easy:

1) We receive a call from PSTN in a Zap channel
2) The IVR take the call and routing to Opertaor extension or user extension
3) The user answer the call, talk few moments and decide to transfer to another user.
4) Then Start to transfer the call, if is a "atended" transfer, the person who start the transfer talk with the destination user without problems
5) The the person who start the transfer make the transfer and the destination user ear the caller person, but the caller can ear the destination user.
6) If the user press "hold" and "resume" the call, tha audio work again.

in a "blind transfer" scenario, all the points apply except the number 4.


In few hours i make a more verbose sip debug to attach here.


By: Serge Vecher (serge-v) 2006-06-29 08:42:10

el pop: this is a very basic scenario and works well in many installations, including mine. We don't have Aastra phones, but that probably should not matter. Are using SVN 1.2 or SVN trunk? Report is marked with 1.2, but that revision # indicates trunk.

Will be looking out for your debug.
By: Serge Vecher (serge-v) 2006-07-12 13:43:59

el pop: you have marked this issue as major, but provide no response to questions for over 2 weeks. You already have -6 points in negative karma. If you continue this way, your credibility in the community will stand at even lower level.

When you are ready to provide answers, please feel free to reopen the issue.
By: Tass Iliopoulos (tass) 2006-07-16 22:51:57

I am able to reproduce this bug, I will attach 2 outputs.
The first is with verbose 3, core 4, sip debug on the 2 peers used.

The second is the same as the first, but also RTP debugging on the 2 IPs, and before the call is completed it is put on hold, then resumed which resumes two-way audio.

I'm not sure why the RTP log stops... if this is a problem (or even required) I will attempt to log again.

This problem happens consistently between the two peers being logged.


By: Serge Vecher (serge-v) 2006-07-17 08:56:46

what revision/release of Asterisk can you reproduce this on?
By: Tass Iliopoulos (tass) 2006-07-17 09:00:12

This is on release 1.2.10, Zaptel 1.2.7.
I've since downgraded to 1.2.9.1 (but left Zaptel on the latest) and this no longer occurs.
By: Fernando Romo (el_pop) 2006-07-18 01:49:26

Verchers: I am out several days and i take care of the issue again, i can't have all the time for follow the issue... :(
By: Olle Johansson (oej) 2006-08-07 10:07:38

Anyone that has tested this on svn trunk?
By: Stephen Marron (soloflyer) 2006-08-13 20:39:38

I have been able to reproduce this issue using asterisk 1.2.10 and as previous mentioned reverting to older versions solves the problem
By: Stephen Marron (soloflyer) 2006-08-15 04:27:52

Removing the patch for issue 7294 fixed this issue for me

http://bugs.digium.com/view.php?id=7294
http://svn.digium.com/view/asterisk/branches/1.2/channels/chan_sip.c?r1=33235&r2=34306


This issue is related to
Issue 0007294 - Patch for this issue caused the problem
and 0007707 - Also broken by Patch for issue 0007294


By: Fernando Romo (el_pop) 2006-08-23 17:46:11

SoloFlyer:

Thanks, i only remove the "codecs" validation and work fine, we test 4 full days with a full operation and the problem appear to be resolved.

-       if (codecs && !ast_test_flag(p, SIP_GOTREFER)) {
+       if (!ast_test_flag(p, SIP_GOTREFER)) {

What is the purpose of the codecs validation?

I added the file chan_sip.c.patch only to simplify the patch describe in your message.


By: Stephen Marron (soloflyer) 2006-08-23 19:00:08

The reason for the check to see if codecs was set, was to fix bug 0007294 they made the assumption that if codecs wasnt set, that there wasnt a valid sip channel... unfortunatly it appears that codecs isnt always set when a valid channel exists (IE when the conversation is with a zaptel channel or in the case of bug 0007707)

PS i have been running 1.2.10 with the patch for bug 0007294 remove since 08-15-06 and i havent had any problems
By: Kevin P. Fleming (kpfleming) 2006-09-01 12:39:31

I have committed the proper patch from ASTERISK-7237294, which should solve this problem in the correct way. The fix was committed in revision 41716 of branch-1.2; please update and retest your issue and request this issue to be reopened if needed. Sorry for the problems :-(