[Home]

Summary:ASTERISK-07227: [patch] cannot transfer calls with r36148
Reporter:jmls (jmls)Labels:
Date Opened:2006-06-23 12:31:42Date Closed:2006-07-02 14:55:59
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Transfers
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_sip.patch.txt
( 1) console-20060623-1823.txt
( 2) console-20060629-1441.txt
( 3) sip-patch.txt
( 4) sip-patchv2.txt
Description:Cannot transfer a call from a sip phone to another

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

raised as asked by  vechers 06-22-06 16:07 in relation to issue ASTERISK-7189
Comments:By: jmls (jmls) 2006-06-23 12:34:05

called from my mobile to SIP/707
707 answers
707 presses transfer to 747
mobile hears MOH
707 speaks to 747
707 presses xfer again
mobile still hears MOH
747 hears nothing
707 has transfer failed
707 tries to resume call, call drops
mobile drops
By: Curt Moore (jcmoore) 2006-06-23 13:49:03

We were having a similar issue with Cisco 7960 phones where the xfer target would hear both MOH and the bridged channel.  twilson and I (mostly twilson) figured out that we needed to tell Asterisk to quiet the target channel.  The attached patch does this. It seems to have solved our attended xfer issue with the 7960s.  This was due to the 7960 trying to put the xfer target on hold immediately before completing the attended xfer.
By: jmls (jmls) 2006-06-25 01:07:20

I will test this patch tomorrow when I am back in the office. Thanks.
By: Olle Johansson (oej) 2006-06-26 14:20:40

tgrman: Please confirm your disclaimer with Digium for this patch. It is very small, but just to be on the safe side.
By: Curt Moore (jcmoore) 2006-06-26 15:03:23

oej: I have a disclaimer on file.
By: Olle Johansson (oej) 2006-06-26 15:47:36

Committed to svn trunk rev 36148. Thank you very much for contributing to Asterisk and fixing my bugs :-)
By: jmls (jmls) 2006-06-29 08:51:32

Sorry guys, just managed to get into the office and test this out. Now running on r36262, and the transfers still fail. I will attach the latest console output.

mobile calls extension 7707.
7707 presses xfer, dials 7747. 7707 talks to 7747, mobile hears MOH
7707 presses xfer again, gets "Xfer failed"
7747 gets MOH
mobile still on MOH
sometimes the call drops, other times have to press the end call button.
Event when 7707 and 7747 are hung up, mobile still has MOH
By: jmls (jmls) 2006-06-29 08:52:55

7707 is a Cisco 7960 and 7747 a 7940. We did try with a linksys 941 but had the same issues. Thought that it would be better to have a 7940/7960 pair for this report.
By: Curt Moore (jcmoore) 2006-06-29 10:25:13

jmls: Which firmware version are you running on the 7940/60?  It seems that there are always lots of gotchas with the Cisco SIP firmware.  If you're running an older version, it may be helpful to look in the Cisco release notes to see if there has been a fix for an xfer related issue since your firmware version.

http://www.cisco.com/en/US/products/sw/voicesw/ps2156/prod_release_notes_list.html

I've not seen any xfer issues, yet, with 7960s with the latest firmware, v8.3.

If you're already running the latest version just disregard this message; we'll have to dig deeper to see what's going on.
By: jmls (jmls) 2006-06-29 12:27:00

they were running 7.4. Upgraded both phones to 8.3.

Unfortunately, I still has the same errors.

Do you need a different console upload as I have changed the sip versions ?
By: Serge Vecher (serge-v) 2006-06-29 14:29:32

jmls: do a console log with firmware 8.3, compare the two, if the new log is different, then post it -- otherwise, we'll have to analyze console-20060629-1441.txt
By: Serge Vecher (serge-v) 2006-06-29 14:34:37

btw, checkout the latest revision for trunk. I wonder if Cisco will react to a=inactive stuff added by oej in 36252. Thanks.

By: jmls (jmls) 2006-06-29 16:52:33

As mentioned in my previous posting, I am already on r36262. I am updating to the latest svn trunk right now.

however, I've just tried putting a call on hold from an xlite softphone, and the mobile gets MOH, but when the xlite tries to retrieve the call, it cannot and the mobile keeps hearing moh. When you press the hold button twice more, the call drops.

Seems as if it's not just a problem with cisco 79XX. I also previously tried a Sipura 941 with the same results.
By: jmls (jmls) 2006-06-29 17:18:10

I think that this is still relating to ASTERISK-7189.

If I call my xlite softphone from my mobile, put the call on hold and attempt to take it off hold, it will not (but as far as xlite is concerned, it htinks that it has retrieved the call). Eventually the call drops.

I've just rolled back (only) chan_sip.c to r33706 and I can call the xlite, put it in hold and retrieve the call.

Roll back (only) chan_sip.c to r33890 and it is all broken.
r35336 is broken
By: jmls (jmls) 2006-06-29 17:37:52

if I call the xlite, put the call on hold, and then hangup the mobile still has moh
By: jmls (jmls) 2006-06-30 06:19:44

guys, think that I've found it !! Please have a look at sip-patch.c. With this patch applied, both my on hold problem (ASTERISK-7189) and this transfer problem are fixed.
By: Serge Vecher (serge-v) 2006-06-30 09:41:56

Hmm, nice catch, jmls! Looks like this line was indeed added in r33890. Marking this for oej to look at.
By: Curt Moore (jcmoore) 2006-06-30 15:23:46

I tried the patch submitted by jmls in "sip-patch.txt" and am now getting a segfault.  If you look at what the code is actually doing there, this fix is incorrect.  The previous code was doing an assignment there and the if statement was assessing the truth value of that assignment, ie. if bridgepeer was NULL or not after the assignment.  With its current logic this cannot be a "==" for a truth test, it must be an "=" for an assignment.


By: jmls (jmls) 2006-06-30 16:10:09

What I don't understand then (my C coding is *very* dodgy) is that without this I cannot retrieve a call on hold, not transfer, but with the patch I can ?
By: jmls (jmls) 2006-06-30 16:17:52

With that one line change I have had my system up all day with 100+ phone calls and transfers and holds (it is a test system). Without it I simply cannot transfer calls.

I cannot make it segfault with this.

perhaps the "fix" is actually highlighting a problem elsewhere. What I don't understand is that other people cannot reproduce the problems that I am having.

I got to this line of code by commenting out changes between 33706 and 36374 until I got to a point where it was narrowed down to this block of code.

I actually commented out all code in the block of
} else if p->t38.state == T38_DISABLED) {
}

and changed it to
} else if p->t38.state == T38_DISABLED) {
transmit_response_with_sdp(p, "200 OK", req, XMIT_CRITICAL)
}

and it worked

so perhaps something is going awray and the transmit_response_with_sdp(p, "200 OK", req, XMIT_CRITICAL) is not being sent ?
By: jmls (jmls) 2006-06-30 16:23:35

I've uploaded another patch (sip-patchv2.txt) which also fixes my problem. I'm not saying that this is right either, but I think that it idiciates that there must be a missing

transmit_response_with_sdp(p, "200 OK", req, XMIT_CRITICAL)

somewhere.

Thanks for your patience with this guys.
By: jmls (jmls) 2006-06-30 16:37:28

just one other thing - are you guys running with T38 passthrough enabled / disabled or is it a permanent setting ? I was just wondering if yuo are running *with* T38 and don't see the problems because of the T38 improvements / handling and my problems stem from the possibility of me not having T38 configured ?

Or am I talking out of my posterior ?
By: Curt Moore (jcmoore) 2006-06-30 16:48:38

jmls: Thus far, your most recent patch seems to be holding up on one of my servers.  I can't attest to its functionality with regard to xfers as I was never seeing the behavior you described originally.

It's entirely possible this section of the code was missing a "transmit_response_with_sdp" but I'm not the one to say for sure.  I'd like one of the more senior developers, such as oej, to speak up and make that determination after an examination of the intended logic in this section of the code.  It's a relatively new block of code merged in from the T38 branch so there could be some lingering bugs.

I'm not running with T38 enabled.

Thanks for your determination to get this issue resolved.
By: Olle Johansson (oej) 2006-07-02 14:54:16

Committed a similar patch to svn trunk. Many thanks for a good job debugging and finding the problem, jmls!!!
By: Olle Johansson (oej) 2006-07-02 14:55:44

Committed to svn trunk 36679. Thanks to everyone for a good job!