[Home]

Summary:ASTERISK-17897: [patch] Call shows on hold after attended transfer with a Polycom phone
Reporter:Remi Quezada (remiq)Labels:
Date Opened:2011-05-20 10:33:37Date Closed:2012-09-17 10:27:20
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Transfers
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) auth-sip-uri.patch
( 1) axfer-cli-capture.txt
( 2) axfer-cli-capture2.txt
( 3) axfer-cli-capture3.txt
( 4) extensions.conf
( 5) noauth-bye.patch
( 6) sip.conf
Description:When I do an attended transfer from a Polycom IP650 the call is transferring successfully, but the call is not releasing properly on the phone that is initiating the transfer.  Instead the call shows that it is on hold.  
Comments:By: Richard Mudgett (rmudgett) 2011-05-20 10:36:52

This may have been fixed with the -r319654 commit to v1.8:

Make sure everyone gets an unhold when a transfer succeeds

Some phones, like the Snom phones, send a hold to the transfer target after
before sending the REFER. We need to make sure that we unhold the parties
that are being connected after the masquerade. If Local channels with the /nm
option are used when dialing the parties, hold music would still be playing on
the transfer target, even after being connected with the transferee.
By: Remi Quezada (remiq) 2011-05-20 10:42:32

I tested this using the latest SVN 1.8 branch (319938) and I am having the issue.
By: Leif Madsen (lmadsen) 2011-05-23 10:30:13

Are you using the built in attended xfr or doing it on the Polycom itself?
By: Remi Quezada (remiq) 2011-05-23 10:36:03

I am not using the asterisk built in attended transfer.  I am doing the attended transfer from the Polycom phone.
By: Paul Belanger (pabelanger) 2011-05-23 11:49:43

I'm looking at this now, it would help to see a debug log too (see below).

--
We require a complete debug log to help triage the issue.

This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue:

https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information
By: Remi Quezada (remiq) 2011-05-23 12:17:28

Ok, I turned some more debugging on as requested.  Let me know if you need anything else.
By: Paul Belanger (pabelanger) 2011-05-23 12:33:35

Can you explain what extensions are involved?  EG: what you dialed
By: Malcolm Davenport (mdavenport) 2011-05-23 13:17:59

Trying to reproduce this.  Failing.  Tried 1.8 out of SVN right now, 1.6.2 out of SVN from last Friday, and 1.6.0 from way long ago.  Calling from Blink to Polycom transferring to Cisco.  On the Polycom, I answer, transfer, dial, send, answer (on the cisco), transfer (on the Polycom), and everything's just swell.

Dial string for the party I'm transferring to looks like:

exten => 202,1,Dial(SIP/cisco,,t)

Cheers.
By: Remi Quezada (remiq) 2011-05-23 13:41:15

Incoming call from SIP/mg2 to SIP/322-eng,  SIP/322-eng answers call and attend transfers to SIP/312-eng.  SIP/mg2 and SIP/312-eng transfer completes.

To initiate the transfer on the Polycom phone, I answer the incoming call then press transfer, dial (312), send, answer on SIP/312-eng, then press transfer button on polycom phone (SIP/322-eng).  Call transfers, but call stays on hold in Polycom (SIP/322-eng).
By: Malcolm Davenport (mdavenport) 2011-05-23 14:00:26

Do you have a different Polycom phone that you can drop in place for SIP/322-eng?  Maybe that particular phone is just wonky?

What model, what firmware?
By: Remi Quezada (remiq) 2011-05-23 14:14:01

I don't think its the phone itself, this is not happening when I am running asterisk 1.6.2.9.  But I can try a different phone model I do have an IP330.  

The phone is an IP650 running 3.2.3.1734.
By: Malcolm Davenport (mdavenport) 2011-05-23 14:17:59

i've got an IP601 with 3.1.6.0017 that I'm using.  I can't dupe it with 1.6.2 or 1.6.0 either.  Also can't dupe it with 3.1.7.0134.


By: Remi Quezada (remiq) 2011-05-23 14:22:58

I am able to reproduce this with IP330 as well running 3.2.3.1734.
By: Paul Belanger (pabelanger) 2011-05-23 14:24:24

Are you able to reproduce this with a minimal extensions.conf and sip.conf?  If so, attached them too please.
By: Remi Quezada (remiq) 2011-05-23 14:49:21

Yes I am.  I attached the files.
By: Malcolm Davenport (mdavenport) 2011-05-23 16:19:42

I still can't duplicate this.  I can create an issue when defining my Cisco 7960 (7.2 SIP firmware) with nat=yes if I don't set pedantic=no in the general section of sip.conf - because my Cisco phone doesn't properly format its SIP requests.  So, if I've got Cisco phones in the mix, pedantic=no is a good idea.

I don't have the SIP devices you have to try and fully re-create your setup.

That said, where  Phone A = Cisco 7960 (SIP 7.2), Phone B = Polycom 670 (3.3.1.0933), Phone C = Polycom 450 (3.3.1.0933).

I can call from Phone A to Phone B.
Phone B answers.
Phone B initiates attended transfer to Phone C.
Phone C answers.
Phone B completes transfer.
Phones A & C converse.
Phone B hangs up.
By: Remi Quezada (remiq) 2011-05-24 08:22:04

I tried running 3.3.1.0933 on the IP650 and I am still able to reproduce.  

Note: I am not able to reproduce this in asterisk 1.6.2.
By: Malcolm Davenport (mdavenport) 2011-05-24 08:35:18

Have you tried pedantic=no in the general section of sip.conf?
By: Remi Quezada (remiq) 2011-05-24 08:58:05

Yes I have still able to reproduce.
By: Malcolm Davenport (mdavenport) 2011-05-24 10:49:20

Can anyone else reproduce this?  If so, can you shed any additional light on your situation?
By: Remi Quezada (remiq) 2011-05-24 11:07:26

I noticed that the line only goes on hold when I transfer the call to a Linksys phone (SPA942) or Cisco phone (SPA303g).

When I transfer the call to another Polycom phone (IP330) the call does not go on hold instead it shows the line as active.  If the person doing the transfer was using a handset, this will not be a problem since the person can just hang up after the transfer is complete.  But if the person was doing a transfer while on speaker phone then the line will stay up and the person will have to press the speaker button after the transfer to fully hangup the line on the phone.  

Do you happen to have a Linksys/Cisco phone you can transfer the call to?
By: Malcolm Davenport (mdavenport) 2011-05-24 12:04:35

I have a Cisco 7960 phone.  I can place a call from either Polycom phone to the other Polycom phone.  Then transfer from the intermediary Polycom phone to the Cisco phone.  I'm doing the transferring from speakerphone mode - I don't even have a handset hooked to the Polycom (or I can use one with a handset and the result is the same).  No issues.

I don't have an SPA942 or an SPA303g.
By: Stephen A. Brandli (stevebrandli) 2011-05-24 13:15:08

remiq: The polycom to polycom phone transfer (using the transfer button) is supposed to keep the line up at first.  The line, at first, should be between the transferror and the transferree (to allow anouncing the call).  Then, when the transferror hangs up, the incoming call is transferred to the transferror.  This works perfectly for me (variety of Polycom phones, all latest firmware).  However, my Dial() has the 't' option, even though I am not using the Asterisk transfer codes.

I can't speak to transfer to other phone makes.
By: Malcolm Davenport (mdavenport) 2011-05-24 14:38:26

Maybe you can take this to the -users list and someone else can duplicate it or shed some additional light on it?
By: Remi Quezada (remiq) 2011-05-25 09:50:31

I figured out why you are not able to reproduce.  I have a Adtran 908 router and I have the sip proxy enabled.  When I have the sip proxy enabled I am able to reproduce this, but once I hook up the phones directly to the asterisk (no sip proxy) I am not getting any call on hold for attended transfers.
By: Remi Quezada (remiq) 2011-05-25 10:05:37

After further investigation it looks like the SIP proxy is not liking the BYE message after the transfer, it's returning with a '400 SIP Parser Error':

BYE sip:322-eng@209.191.39.117:5060;adtnpxyid-1i2c6kcj=bbecf4 SIP/2.0^M
Via: SIP/2.0/UDP 64.19.145.13:5060;branch=z9hG4bK229eab44^M
Max-Forwards: 70^M
From: <sip:312@64.19.145.13;user=phone>;tag=as0868ad46^M
To: "Poly_test ENG"<sip:322-eng@64.19.145.13>;tag=E7EA8417-AA13A95A^M
Call-ID: dd352991-ef95b5a4-7585dccf@10.0.15.105^M
CSeq: 102 BYE^M
User-Agent: Asterisk PBX SVN-branch-1.8-r319997^M
Proxy-Authorization: Digest username="322-eng", realm="asterisk", algorithm=MD5, uri="64.19.145.13", nonce="", response="eac3218b89666699bb97133fa8966982"^M
X-Asterisk-HangupCause: Normal Clearing^M
X-Asterisk-HangupCauseCode: 16^M
Content-Length: 0^M


<--- SIP read from UDP:209.191.39.117:5060 --->
SIP/2.0 400 SIP Parser Error : Unexpected '\"', line 9, column 99
From: <sip:312@64.19.145.13;user=phone>;tag=as0868ad46
To: "Poly_test ENG"<sip:322-eng@64.19.145.13>;tag=E7EA8417-AA13A95A
Call-ID: dd352991-ef95b5a4-7585dccf@10.0.15.105
CSeq: 102 BYE
Via: SIP/2.0/UDP 64.19.145.13:5060;branch=z9hG4bK229eab44
Max-Forwards: 70
User-Agent: Asterisk PBX SVN-branch-1.8-r319997
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Proxy-Authorization: Digest username="322-eng" realm="asterisk" algorithm=MD5 uri="64.19.145.13", nonce="", response="eac3218b89666699bb97133fa8966982"
Content-Length: 0

<------------->

Any clue why?
By: Malcolm Davenport (mdavenport) 2011-05-25 10:16:46

Can you get a similar capture when running 1.6.2.x with the problem not happening?  Does the BYE look different?
By: Remi Quezada (remiq) 2011-05-25 10:42:45

Here is the BYE from asterisk 1.6.2.9:

Reliably Transmitting (no NAT) to 209.191.39.117:5060:
BYE sip:322-eng@209.191.39.117:5060;adtnpxyid-1i2c6kcj=8cg8ia SIP/2.0
Via: SIP/2.0/UDP 64.19.145.13:5060;branch=z9hG4bK6e12c410;rport
Max-Forwards: 70
From: <sip:312@64.19.145.13;user=phone>;tag=as671e9719
To: "Poly_test ENG"<sip:322-eng@64.19.145.13>;tag=23813484-136FC2B
Call-ID: 8ced1f50-60723397-d9a44366@10.0.15.101
CSeq: 102 BYE
User-Agent: Asterisk PBX 1.6.2.9
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0


<--- SIP read from UDP:209.191.39.117:5060 --->
SIP/2.0 200 OK
From: <sip:312@64.19.145.13;user=phone>;tag=as671e9719
To: "Poly_test ENG"<sip:322-eng@64.19.145.13>;tag=23813484-136FC2B
Call-ID: 8ced1f50-60723397-d9a44366@10.0.15.101
CSeq: 102 BYE
Via: SIP/2.0/UDP 64.19.145.13:5060;rport=5060;branch=z9hG4bK6e12c410
Contact: <sip:322-eng@209.191.39.117:5060;adtnpxyid-1i2c6kcj=8cg8ia>
User-Agent: PolycomSoundPointIP-SPIP_650-UA/3.2.3.1734
Accept-Language: en
Content-Length: 0


<------------->
By: Paul Belanger (pabelanger) 2011-05-25 11:33:34

Looks like an issue with your proxy parsing uri="64.19.145.13" within the Proxy-Authorization.  From the looks of it, it maybe trying to escape the quote (").
By: Remi Quezada (remiq) 2011-05-26 08:33:38

I patched asterisk and I can now confirm that the issue goes away once I remove the Proxy-Authorization from the BYE message.  I attached the patch in case anyone is interested.  I have a ticket open with Adtran to have this looked at and resolved.
By: Remi Quezada (remiq) 2011-05-31 09:38:34

According to Adtran, the uri in the Proxy-Authorization header is not within specs according to the RFC 3261.  Here is the response I got from Adtran #RQST00001208043:

The TA 900 is rejecting the BYE because there is a syntax error in the Proxy-Authorization header. For reference, here is that header:

Proxy-Authorization: Digest username="322-eng", realm="asterisk", algorithm=MD5, uri="64.19.145.13", nonce="", response="eac3218b89666699bb97133fa8966982"

Per RFC 3261 Section 25.1, the digest-uri portion of the header is defined as follows:

digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT

Section 22.4 of RFC 3261 defines digest-uri-value as follows:

3. The BNF for digest-uri-value is:

digest-uri-value = Request-URI ; as defined in Section 25

Section 25.1 of RFC 3261 defines Request-URI as follows:

Request-URI = SIP-URI / SIPS-URI / absoluteURI

SIP-URI = "sip:" [ userinfo ] hostport
uri-parameters [ headers ]

SIPS-URI = "sips:" [ userinfo ] hostport
uri-parameters [ headers ]

hostport = host [ ":" port ]

absoluteURI = scheme ":" ( hier-part / opaque-part )

scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )


Based on these definitions, the uri parameter in the Proxy-Authorization header is not valid. It would be valid as the following:

uri="sip:64.19.145.13"

which would give a full header that looked like this:

Proxy-Authorization: Digest username="322-eng", realm="asterisk", algorithm=MD5, uri="sip:64.19.145.13", nonce="", response="eac3218b89666699bb97133fa8966982"
By: Paul Belanger (pabelanger) 2011-05-31 10:07:37

I believe your summary is correct.
By: Remi Quezada (remiq) 2011-06-02 07:40:56

I patched asterisk to include 'sip:' in the uri.  I confirmed attended transfers are working now with my sip proxy.  Here is the BYE message:


Reliably Transmitting (no NAT) to 209.191.39.117:5060:
BYE sip:322-eng@209.191.39.117:5060;adtnpxyid-1i2c6kcj=8cg9c2 SIP/2.0
Via: SIP/2.0/UDP 64.19.145.13:5060;branch=z9hG4bK1c20e4ae
Route: <sip:209.191.39.117;lr>
Max-Forwards: 70
From: <sip:312@64.19.145.13;user=phone>;tag=as06bd6aa9
To: "Poly_test ENG"<sip:322-eng@64.19.145.13>;tag=8F24444A-B00E699F
Call-ID: 7f8fe88-8db45e5d-55791ff2@10.0.15.101
CSeq: 102 BYE
User-Agent: Asterisk PBX SVN-branch-1.8-r321155M
Proxy-Authorization: Digest username="322-eng", realm="asterisk", algorithm=MD5, uri="sip:64.19.145.13", nonce="", response="f8f04d4adff65548b5cb6b17f791f768"
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0


---

<--- SIP read from UDP:209.191.39.117:5060 --->
SIP/2.0 200 OK
From: "Remi Quezada"<sip:176@64.19.145.13>;tag=as39b0a74b
To: "Poly_test ENG"<sip:322-eng@209.191.39.117:5060;adtnpxyid-1i2c6kcj=8cg9c2>;tag=7E86B3E1-C3C48076
Call-ID: 763fcb0214fe7c230c228aa15e1eda74@64.19.145.13:5060
CSeq: 105 NOTIFY
Via: SIP/2.0/UDP 64.19.145.13:5060;branch=z9hG4bK195c1cac
Contact: <sip:322-eng@209.191.39.117:5060;adtnpxyid-1i2c6kcj=8cg9c2>
Record-Route: <sip:209.191.39.117;lr>
Event: refer;id=2
User-Agent: PolycomSoundPointIP-SPIP_650-UA/3.2.3.1734
Accept-Language: en
Content-Length: 0


<------------->
By: Matt Jordan (mjordan) 2012-09-17 10:27:00.495-0500

This ended up getting fixed in an unrelated commit (r326681):

{noformat}

------------------------------------------------------------------------
r326681 | mnicholson | 2011-07-07 10:25:49 -0500 (Thu, 07 Jul 2011) | 3 lines

make the uri parameter used in reply digests more standards compliant in
certain cases by prepending "sip:" or "sips:" to it

------------------------------------------------------------------------
{noformat}

This should be resolved as of Asterisk 1.8.6.0.