[#XTRN-208] Polycom550 sends REFER when being blind transfered

External

Polycom550 sends REFER when being blind transfered

Created: 2008-07-22 14:28 Updated: 2008-11-21 07:52

Component/s:

Polycom - SoundPoint IP

Affects Version/s:

None

Fix Version/s:

None

Original Estimate:	Unknown	Remaining Estimate:	Unknown	Time Spent:	Unknown
File Attachments:	1. 0004f21a2296-app.log (455 kb) 2. 0004f21a2296-directory.xml (0.1 kb) 3. 0004f21a2296-sipx-phone.cfg (13 kb) 4. 0004f21a2296-sipx-sip.cfg (147 kb) 5. 0004f21a2296.cfg (0.6 kb) 6. blind_transfer_packet_trace.pcap (310 kb) 7. callTarget3.xml (5 kb) 8. DatafScs.txt (0.2 kb) 9. polycom650_xtra_refer.pcap (18 kb) 10. Polycom_cong_access_ok_sniff_trace.cap (408 kb) 11. polycom_logs.txt (33 kb)
Environment:	« Hide Polycom version: 3.0.2.0972 Proxy server: sipp script Show » Polycom version: 3.0.2.0972 Proxy server: sipp script

Description

« Hide

Background information:
Polycom 550 running version: 3.0.2.0972 has IP address 47.135.162.149.
SIPP script is running on machine 47.129.108.194

Scenario overview:
SIPP script calls Polycom phone, waits for it to answer and then blind transfers it to a conference bridge.

Detailed scenario:
We have a scenario in which we send a REFER to the polycom set for the purposes of blind transferring it to one of our conference bridges. The Polycom handles that REFER by sending an INVITE in a new dialog as expected but it also sends a REFER on the existing dialog.

Referring to attached wireshark trace, if we examine the first dialog (sip.Call-ID == "1-25770@47.129.108.194"), we see in packet #10 that a REFER is sent to the Polycom. Next, we see in packet #12 that Polycom accepts the REFER and sends a NOTIFY in packet #14 as prescribed by the spec. The puzzling packet is #20 in which we see the Polycom send a REFER back to SIPP. Even more puzzling is the fact that we see Polycom sending another REFER in packet #27 after the dialog has been terminated by SIPP (see BYE request in paclet #21).

I'm trying to find an explanation that would justify Polycom sending the REFERS in packets #20 and #27 but cannot find any. These extra REFERs are causing interop issues with some of our endpoints and were not observed in the 2.x f/w.

Perhaps I'm missing something but I do not believe these extra REFERs should be sent by Polycom phone.

I have attached wireshark traces and Polycom syslog to this tracker.

Thanks in advance.

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Paul Mossman - 2008-07-22 15:22

Polycom SondsPointIP firmware version: 3.0.2.0972. The problem is also observed on a 650.

[ Permlink | « Hide ]

Robert Joly - 2008-07-23 08:03

I'm adding the SIPP script that I used to reproduce the problem.

The command to invoke the script is as follows:

sipp <yourProxyIP>:5060 -auth_uri <yourSIPDomain> -d 5000 -inf DatafScs.txt -sf callTarget3.xml -trace_err -trace_msg -s <extensionOfPolycomSetToBeCalledByScript> -m 1

The script file is called callTarget3.xml and the data file is called DataScs.txt.

Before running the script, you need to edit Fields 0, 1 and 6 of the DataScs.txt file to match your scenario.

[ Permlink | « Hide ]

Robert Joly - 2008-07-23 08:04

SIPP script used to recreate the problem

[ Permlink | « Hide ]

Robert Joly - 2008-07-23 08:05

Data file that goes along with script.

[ Permlink | « Hide ]

Paul Mossman - 2008-07-23 08:37

The problem has also been observed with firmware versions 2.2.2.0084 and 3.0.3.0401, when tested against the SCS500 Conference Bridge. This was on scsalpha, where we use a Conference Bridge extension of 20000, and an access code of 29785.

I also notice that the problem sometimes does not occur if you enter "29785" rather than "29785#" when prompted for the conference access code.

[ Permlink | « Hide ]

Chris Parfitt - 2008-07-23 10:35

I could not re-create this issue using a Polycom 601 with 3.0.2.0972 firmware.
I was using a 3 digit range for the Bridge access (105) and a 4 digit range for the conference number (4000 to 4999)
Paul asked me to change both the Bridge access and the conference # to 6 digits
I did this using the Bridge as 200000 and the Conference number range as 400000 to 499999
After this I could reptoduce this issue

[ Permlink | « Hide ]

Dale R. Worley - 2008-07-23 11:52

Clearly, the additional REFER is incorrect.

I've been unable to reproduce this issue with Polycom firmware 3.1.0.

[ Permlink | « Hide ]

Chris Parfitt - 2008-07-24 06:09

Please ignore my comment above as I had not changed the ConfServerRule from 3 digits to 5, after I did this I cannot reproduce issue on my system

[ Permlink | « Hide ]

Chris Parfitt - 2008-07-24 06:59

Added trace of successful connection to Conference with Polycom set:
Setup:
Conference name range 20001 to 29999
ConfServerRule prefix 2 and 4 digits
ConfBridge Rule prefix is 20000 and 0 digits
Polycom 601
Firmware: 3.0.2.0972
Polycom IP: 192.122.24.186
SCS: 192.122.24.36

Scenario
From Polycom set user 7006 I dialled 20000
I hear "Please enter your conference access number"
Conference answered and I then dialled 29875#
I hear "Thank you, you are now being connected to the conference"
I am then connected and all is fine...

[ Permlink | « Hide ]

Brad Marusiak - 2008-08-14 12:32

I've been trying unsuccessfully to reproduce this myself using the callTarget3.xml sipp script.
Perhaps if you could provide the phone's configuration files you are using?

If it is reproducible at will for you could you make another attempt with the following log settings:
log.render.file.upload.append.sizeLimit="10240" * Increase the size of the max uploaded log file
log.render.level="0"
log.level.change.sip="0"
log.level.change.pps="1"
log.level.change.so="2"
all other logs can be set at the default (4)

Setting the sip=0 log level will generate a lot of logging so you'll want to remember to raise that level back up after the test is complete or you may experience issues related to high cpu load.

[ Permlink | « Hide ]

Paul Mossman - 2008-08-14 15:14

I was able to reproduce the problem. The logs and configuration files are all attached. (MAC 0004f21a2296)

One interesting thing is that with all this logging enabled, the call does not drop. But, I did a Wireshark trace, and I do see the mystery REFER being sent by the phone. (Also shown in the 0004f21a2296-app.log file.)

[ Permlink | « Hide ]

Brad Marusiak - 2008-08-15 15:51

For reference purposes, this is tracked at Polycom by VOIP-45039

[ Permlink | « Hide ]

Paul Mossman - 2008-09-12 13:04

Downgrading to Minor since the problem has only been observed during a REFER to the SCS500 2.0 conferencing, the work-around (dial the bridge directly) is good enough for that release, and SCS500 2.5 will use the FreeSwitch conferencing product.

[ Permlink | « Hide ]

Aaron Brumpton - 2008-10-08 13:23

This issue is already fixed in Polycom sw and will be available in SIP 3.1.1

[ Permlink | « Hide ]

shobha rani - 2008-11-13 08:21

Verified the issue in the build:

sipxproxy 3.10.3-013975 2008-11-11T06:58:52 oem-3.10-centos5
sipxconfig 3.10.3-013975 2008-11-11T07:08:37 oem-3.10-centos5

Used Polycom firmware version: 3.1.1.0137 to simulate the issue

Steps to reproduce:

Precondition: Registaer three Polycom Phones,201(Polycom 301),202(Polycom 301) and 203(polycom 650)

1. Call user 201 from user 202
2. Answer the call from 202 and blind transfer the call to user 203

Result: Call is established between 202 and 203

Observation: By analysing the call flow the following behaviour was observed:

when 202 Blind transfers the call to 203,
202 sends refer message to 201 stating 'Refer-to' 203 and 'refered by' 201 only ones, ie from Phone2(202) to proxy and proxy to phone1(201)

Attachment: Blind_transfer_packet_trace

[ Permlink | « Hide ]

shobha rani - 2008-11-13 08:40

Few corrections in my last comment:

User 201 is Polycom phone model 650
user 202 is Polycom phone model 301
user 203 is also polycom phone model 301

Made call from 202 to 201 and blind transferred the call from 201 to 203.

Note: I didnt observe any extra REFFER messages coming from the polycom phones.

[ Permlink | « Hide ]

Brad Marusiak - 2008-11-20 17:14

I believe this has been resolved in 3.1.1 and verified by your testers, can this be closed?