 |
History
| Log In
|
|
|
|
Hi Michael,
I have followed the same test scenario as you mentioned in your comment and observed that when voicemail is enabled phoneB shows the call as on hold until the call is answered. Precondition: Register three Polycom phones as users 131(phoneA), 132(phoneB) and 133(phoneC) to the sipXchange. Steps followed to reproduce: Scenario1: Enable voicemail for all the phones used. 1. Make a call to 132 from 131. 2. Answer the call on 132 and blind transfer it to 133. 3. Do not answer the call on 133. Result obtained: User 133 gets disconnected after ringing for 20seconds and rolls over voicemail on user 131(caller). Note: User 132 shows call on-hold until the user 133 ends up the call later once the call gets disconnected automatically on 133, user 132 enters idle state. Call-ID: b7c71100-40e90352-4af9126d@176.25.2.229 Scenario2: Disable voicemail for all the phones. 1. Make a call to 132 from 131. 2. Answer the call on 132 and do blind transfer to 133. 3. Do not answer the call on 133. Result obtained: User 133 rings for long time and disconnects, finally all the three phones get into idle state. Call-Id: 61b28522-8aef7b54-3f37a63f@176.25.2.229 Observation: When the call is Rejected(manually) from user 133(phoneC) the user 132 shows call on-hold and at the same time user 131 keeps ringing for the remaining duration of time then both the phones disconnect, this is observed only when the voicemail is disabled. Polycom phones details: Firmware version 3.0.0.0258 and BootROM version 3.1 Verified build: sipxproxy 3.11.2-012594 2008-05-09T01:00:52 oem-centos5 Please ignore Polycom_Blindtransfer.gz file and verify in Polycom_Blindtransfer.tar.gz
The Polycom2.2.2 and Polycom3.0 firmwares works same as mentioned in the above test scenarios for 3.10.2 build.
1. Polycom3.0 firmware: Attached snapshot: Blindtransfer_Polycom3.0.tar Call id when voicemail is enabled: Call-Id: fe326bb8-48b4da6-e943c079@176.25.2.229 Call id when voicemail is Disabled Call-Id: e568db4c-9725615a-3fbe0e7d@176.25.2.229 2. Polycom2.2.2 firmware: Attached snapshot: Blindtransfer_Polycom2.2.2.tar Call id when voicemail is enabled: Call-Id: 66495070-41da41e6-387246cb@176.25.2.230 Call id when voicemail is Disabled Call-Id: 774185e4-9e0e815a-48f2e13f@176.25.2.230 Verified build: sipxconfig 3.10.2-012659 2008-05-15T21:15:03 oem-rhel4 sipxproxy 3.10.2-012659 2008-05-15T20:56:59 oem-rhel4 The issue can be reproducible with the following setup:
Polycom IP501 as caller Polycom IP601 as blind transfer controller. Polycom IP330 as callee without voicemail permission. Make a call from user 131 (IP501) to 132 (IP601), answer the call and do blind transfer to 133 (IP330). Do not answer the call on 133. Obtained result: When the user 133 stops ringing, user 132(Blind transfer controller) shows call on-hold and does not hang up until it is manually ended. Call-Id: ebb46540-5acfb056-fabd3be7@176.25.2.221 Expected result: When the user 133 ends up the call simultaneously other two users should also end the call and get into idle state. >> Whereas this issue is not seen when the voicemail is enabled for the callee i.e., user133. Polycom firmware version used is 2.2.2 and BootROM version is 3.1 and 3.2 Verified build: sipxconfig 3.10.2-012682 2008-05-18T22:15:50 oem-rhel4 Attachment: Polycom_Blindtrnf.int.tar. Any status on the tests?
The reason I am asking is that there is another Pingtel customer that has reported the same issue. We will capture the scenario and verify the version of firmware being used. I moved this JIRA issue from EXTNL to XECS, since it only seems to happen with sipx 3.10. Even if the root cause is a Polycom issue, there appears to have been a regression related to 3.10 so it seems like something we should be able to address in sipx.
First, please review http://track.sipfoundry.org/browse/XTRN-155 which describes what I think Polycoms _should_ do. In particular, it is not correct for the controller to release the call before it has be answered. Please restate what the observed behavior is with sipXecs 3.10.1 (please DO NOT include any more information on other revisions at this time). Specify exactly what is observed at the phones, and how that differs from expectations. Yes. The expected behavior from a user perspective is what has been documented in
In the scenarios we documented above which all were executed using v3.10.1, when the Blind Transfer key is pressed, the call apperas to be "On Hold" as the target phone rings. Once the target phone is answered or the call rolls to voicemail, the call disappears from the display and returns to its "idle" state". I should note that this only occurs when three Polycom phones are involved with the scenario. If the originating call comes from the PSTN. and is received via an Ingate SBC or Audiocodes media gateway, the behavior works as the expected behavior. Scott, the reason for this bug is that the behavior changed between sipx 3.8 and 3.10. So, regardless of any onus on Polycom (as per
Note that our QA group has reproduced the behavior in 3.10, as per previous comments in this bug report. This issue has missed the 3.10.2 window and is now scheduled for the 4.0 release.
Regarding this:
"When I reviewed the two traces, I see that in v3.10, sipX is adding a tag at the end of the Refer-To: in the REFER - ?X-Sipx-Authidentity=%3Csip%3Atjones%40ares.isdomain.net%3Bsignature%3D482B5 33A%253A%253Acbdd344dbfae40e20f467f1be18e0abc%3E>. The subsequent INVITE generated by the Polycom phone who originated the call incorporates the tag on the To: of the INVITE." The "tag" is a header specification. When a phone goes to generate an INVITE whose URI has a header specification, it must remove the header specification and turn it into an additional header line in the INVITE. In that particular case, the header would be: X-Sipx-Authidentity=<sip:tjones@ares.isdomain.net;signature=482B5 33A%3A%3Acbdd344dbfae40e20f467f1be18e0abc> (Note the removal of %-escaping.) This process is described in RFC 3261 section 19.1. Dale implies (without quite explicitly saying so) that the Polycom's handling of the tag is incorrect. If that's the case we should try really hard to work around their behavior in the current release (3.10). Whether it's fair or not, customers are will not happily accept us writing off a perceived functional regression in behavior between 3.8 and 3.10 as being Polycom's fault. Even if we can get Polycom to fix this in v3.0.x of their firmware (which, btw, we should be trying hard to expedite via our Engineering-to-Engineering relationship with Polycom) our customers will be unhappy to find that they can't use sipx 3.10 as they expect without also upgrading their Polycoms to 3.0 firmware. Upgrading phones is a non-trivial endeavor for many customers, and some Polycom models won't even run 3.0.
Some additional information. Per Alex's request, we tested this issue using Polycom sip.ld v2.1.1. The Blind Transfer functioned as expected using this release.
I noticed this morning that Polycom has a new release of software (v3.0.3b). We are testing that release this afternoon. Dave Deutschman writes:
You are correct, the blind transfer worked correctly with v3.10.1 when we downgraded the phones to sip.ld v2.1.1. We did test with v3.0.3b with v3.10.1 and the problem exists in that release. retest please with new firmware and current main build
Verified the above issue on the following build with the polycom phones 3.1.0.0084 firmware version
sipxproxy 3.11.6-013497 2008-09-23T21:40:12 oem-centos5 sipxconfig 3.11.6-013497 2008-09-23T21:52:01 oem-centos5 Registered 3 polycom phones with the user 600(IP600),601(IP650) and 602(IP301) Scenario1: Enable voicemail for all the phones used. 1. Make a call to 601 from 600. 2. Answer the call on 601 and blind transfer it to 602 3. Do not answer the call on 602. Response : - User 602 gets disconnected after ringing for 20seconds and rolls over voicemail on user 600(caller).Blind transfer controller (601) disconnects immediately after pressing "Send" button while blind transferring the call.which is as expected behavior. Scenario2: Disable voicemail for all the phones. 1. Make a call to 601 from 600. 2. Answer the call on 601 and do blind transfer to 602. 3. Do not answer the call on 602. Response : User 602 gets disconnected after ringing for 20 seconds.Blind transfer controller (601) disconnects immediately after pressing "Send" button while blind transferring the call.which is as expected behavior. Scenario 3 Disable voice mail permission only for 602 user 1. Make a call to 601 from 600. 2. Answer the call on 601 and do blind transfer to 602. 3. Do not answer the call on 602. Response : User 602 gets disconnected after ringing for 20 seconds.Blind transfer controller (601) disconnects immediately after pressing "Send" button while blind transferring the call.which is as expected behavior. As all the scenario's worked as expected , hence the issue can be closed. Thanks, Ashwini Closing the issue as per my previous comments.
Thanks Ashwini |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
Blind Transfer issue with Polycom phones [in sipx 3.10]
PhoneA calls PhoneB.
PhoneB does a blind transfer to PhoneC
PhoneC does not answer at all.
At this stage, we need to verify whether PhoneB comes back to idle state (gets released) or shows the call as on hold until the call is answered or rolls to VM.