[Home]

Summary:ASTERISK-21690: Asterisk sends SIP 481 after REFER
Reporter:Peter Grace (petergrace)Labels:
Date Opened:2013-04-25 09:49:12Date Closed:2013-05-30 11:56:21
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Transfers
Versions:1.8.15.1 Frequency of
Occurrence		Frequent
Related
Issues:
Environment:Server is Dell PowerEdge R610 running CentOS 6.4 Phones are Polycom VVX600's with the following software versions: Platform: Model=VVX 600, Assembly=3111-44600-001 Rev=A Region=0 Platform: Board=3111-44600-001 3 0 Platform: MAC=0004f2aef0ff Platform: BootBlock=3.0.4.0061 (44600-001) 13-Sep-12 09:09 Platform: BootL1=1.0.0.0041 (44600-001) 13-Sep-12 10:01 Application, main: Label=Updater, Version=Peridot 5.1.2.0651 07-Nov-12 21:44 Application, main: P/N=3150-11069-512 Attachments:( 0) 8287-20130426-TransferFailedButSucceeded.pcap
( 1) 8287-20130426-TransferFailedButSucceeded-debug.txt
( 2) 8289-DebugLog.txt
( 3) 8289FailedTransfer.pcap
( 4) petebart-blind-combined.pcap
Description:Frequently when our users are attempting to transfer a call, their transfer will fail.  One of the instances of the failure is shown in the attached pcap.  I am confused as to how the 481 is being produced since the code comment (and ticket #17521 seems to reiterate) that this only occurs if the call legs are not found, however both Call-ID's described in the REFER exist.  I don't see any debug information in the debug log that hints at why I'm getting a 481.
Comments:By: Peter Grace (petergrace) 2013-04-25 09:49:45.119-0500

pcap of failed call in question
By: Peter Grace (petergrace) 2013-04-25 09:51:47.078-0500

log of call in question
By: Peter Grace (petergrace) 2013-04-25 09:52:20.065-0500

I've noticed that the log I've attached is not, in fact, a debug log.  I've adjusted my logger settings and will wait for a further recurrence to give more information.
By: Peter Grace (petergrace) 2013-04-25 15:03:44.493-0500

There was another transfer failure,there were no debug entries in the debug logs that would indicate why I was getting a 481 response on the REFER.
By: Michael L. Young (elguero) 2013-04-25 15:13:31.104-0500

What debug level are you using?  Is SIP debug enabled as well?
By: Peter Grace (petergrace) 2013-04-25 15:18:36.139-0500

Michael, I didn't realize I needed to up the core debug level when I specified the debug file in logger.  I've now upped the debug to level 9 for chan_sip.c and channel.c, and also set "sip set debug peer 8289" to try to catch the problem again.
By: Peter Grace (petergrace) 2013-04-26 08:13:18.165-0500

Hi Michael,

I don't think this is the issue, because I have a pcap (attaching now) of a properly working transfer, and that REFER also contains the URL-encoded Replaces header.

<sip:8297@10.110.3.20:5060;user=phone?Replaces=4a10ad25-65e7b642-68ed2257%4010.110.3.133%3Bto-tag%3Das2a16bca1%3Bfrom-tag%3DBF96437A-FFED2CF>
By: Peter Grace (petergrace) 2013-04-26 08:14:39.254-0500

pcap of a successful call transfer, this transfer has a SIP 200 OK on the NOTIFY in spite of there being a url-encoded Replaces header.
By: Michael L. Young (elguero) 2013-04-26 10:14:02.235-0500

Peter,

Yep, I deleted my comment because after re-looking at the code and trying to see if we were decoding (which I thought we would have been doing) I saw that we were.  I had missed it upon looking over it the first time.  So, that is probably not the problem then.

As soon as we can get a debug log of when it fails, it may prove useful in knowing why this is happening.
By: Peter Grace (petergrace) 2013-04-26 14:10:29.453-0500

In this trace, the call id illustrated had two REFER attempts, both returning 481 back to the phone, though apparently the transfer still worked this time.
By: Peter Grace (petergrace) 2013-04-26 14:11:58.714-0500

Debug level 9 information from the same call referenced in 8287-20130426 pcap.
By: Peter Grace (petergrace) 2013-04-26 14:14:03.391-0500

Hi Michael!

I've attached another pcap and the level9 debug log for the call shown in the pcap.  In this case the user attempted the transfer once and received "Transfer Failed", then tried a subsequent time and got the same "Transfer Failed" but then she said the call disappeared and it actually transferred to the remote party!

So I'm not exactly sure what's going on, but it seems like the only commonality between the Polycom showing the "transfer failed" message is the occurence of this 481 on the NOTIFY after the REFER.

Let me know if you need any other info!
By: Peter Grace (petergrace) 2013-05-06 13:44:39.044-0500

Hello Michael,

We tried some off-the-wall fixes and I believe I found what caused the issue.  Our Polycom's dialplan was arranged such that for some extensions, the number would begin sending after two digits.  The phone sent the two digits and then began sending digits-as-received.  The final extension that was entered was indeed correct, but for some reason we were getting the 481 at response to the REFER.  We changed the logic so that we send all 4 digits at once regardless of extension and the problem hasn't recurred.

If more information is required beyond what's already been posted, let me know -- I can try to get more debug information later this week.
By: Rusty Newton (rnewton) 2013-05-13 18:58:42.761-0500

Can you attach a debug log with DTMF message types enabled as well? (see logger.conf)
By: Rusty Newton (rnewton) 2013-05-30 11:56:10.412-0500

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.  Further information can be found at http://www.asterisk.org/developers/bug-guidelines