Attachment trace1.pcap is an example.

frame 1: the phone sends INVITE, Call-ID: ae9880bc-b431eee6-a48357a7@10.1.1.41, from-tag: E4C1E60-EE08D529

frame 3: the phone receives 180 Ringing, to-tag: E5D83ABB-24DFC63A

frame 6: the phone receives 180 Ringing, to-tag: 8BCBB66F-9C327162

frame 9: the phone receives INVITE-with-Replaces. Replaces header is: Replaces: ae9880bc-b431eee6-a48357a7@10.1.1.41;to-tag=E4C1E60-EE08D529;from-tag=E5D83ABB-24DFC63A

frame 10: the phone responds to the INVITE-with-Replaces with a 481.

Beware that current versions of siptrace-merge (and hence, merge-logs) drop some of the 180 responses in call sequences like that, erroneously showing that the calling phone does not receive multiple 180 responses.

Also see with 2.1.1.0052 firmware -- see trace2.pcap.

Note that this does not explain call pick-up probems seen in systems with other types of phone (e.g., Snom).

reported to polycom - tracker id ext-538

https://jira.polycom.com:8443/browse/EXT-538

A test for this problem is http://interop.pingtel.com/#pickup-forked.

This is still an issue in the Polycom firmware 2.2.2

It was closed since there is nothing Pingtel can do about it. Ideally, this should be assigned to someone at Polycom.

This is not an issue with sipXecs.

The purpose of this issue was to track our reporting of it to Polycom. As noted in my earlier comment, it has been reported to them - I have now added the link to their tracker in the external issue reference field.

Incidentally, I happen to know for sure that they have been working on this because I've been helping the developer.

Test results I've seen on the 3.02.0972 firmware indicate that this problem has indeed been fixed.

Could you please re-test with the latest Polycom firmware and against the latest sane SCS500 2.5 build:Please close those issues that no longer exist and assign the others to Paul Mossman

Note that this is the same as the Interop Online "11. Call Pick-Up of a Forked Call" test case http://interop.sipxecs.org/#pickup-forked

To set this up on a non-Interop system you need 4 phones. "C" is the Polycom being tested, it will make the call (INVITE) that is forked and results in multiple early dialogs.

A: Configure an "At the same time" Call Forward to B
C: calls A, this will ring both A and B
D: Execute a Call Pickup by dialing "*78A", then repeat with "*78B".

C passes this test case if the Call Pickup successfully connects D and C.

As per the Paul comments verified the subjected issue on the following build with the polycom phones(firmware version 3.1.0.0084).
sipxproxy 3.11.6-013497 2008-09-23T21:40:12 oem-centos5
 sipxconfig 3.11.6-013497 2008-09-23T21:52:01 oem-centos5

My setup:

1)Registered 4 polycom phones with the extensions 800(IP301),801(IP301),802(IP301) and 803(IP650).
2)Enabled call forwarding for the extension 800 "At the same time" for 801 for ringing time 30 seconds.
3)Make a call from 802 to 800(extensions 800 and 801 starts ringing at the same time).
4)Now, try to retrieve the call from 803 by direct call pick up code "*78800"

Expected response :Call should be established between the extensions 800 and 803.

Actual result : Call fails to establish ,when verified in the call flow "481 Call Leg/Transaction Does Not Exist" response is thrown.

Observation :
1) Retrieving the call by dialing *78801 also fails.

2)When verified in the console,the corresponding details are set as expected.

1) less /var/sipxdata/sipdb/alias.xml
<items type="alias" xmlns="http://www.sipfoundry.org/sipX/schema/xml/alias-00-00">
   <item>
       <identity>800@moon.qantom.int</identity>
       <contact>&lt;sip:801@moon.qantom.int;sipx-noroute=Voicemail?expires=30&gt;;q=1.0</contact>
   </item>

2)less /etc/sipxpbx registrar-config
      SIP_REDIRECT.180-PICKUP.DIRECTED_CALL_PICKUP_CODE : *78

3) In tftp root(mac-id-sipx-sip.cfg)

< call.directedCallPickupString="*78" ....

Attachments:
callforwarding.xml
snapshot- sipx-configuration-moon.qantom.int.tar

Thanks
Ashwini

Call-id for the above scenario -"288f20c1-f24e1dd8-165f88e7@176.25.2.225"

-Ashwini

Ashwini's 3.1.0.0084 Polycom firmware findings above are completely correct. However, the root cause of the failure is actually XTRN-231 (Polycom Call Pickup fails, due to initial Dialog Event NOTIFY not sent).

The XECS-1706 kludge to work-around this Polycom bug has been submitted into 3.10.3, though not in the 3.11.6 stream Ashwini tested. I have observed this scenario working with 3.10.3-13731, which validates that the root cause of this issue is fixed, so I am resolving and closing this issue.