Setup:
Phone 206 is at 10.1.1.123.
Phone 207 (Polycom 650 firmware 3.1.0) is at 10.1.1.171.
Phone 208 (Polycom 330 firmware 3.1.0) is at 10.1.1.124.
sipX is at 10.1.1.68, victoria.pingtel.com.
Phone sip:
207@victoria.pingtel.com has BLF subscription to
sip:~~rl~C~
207@victoria.pingtel.com, which is a resource list with one
element, sip:
208@victoria.pingtel.com.
Subscriptions from 207 to ~~rl~C~207 go to the sipX Resource List
Server (RLS). The RLS is nearly a pure resource list server, in that
the aggregated dialog events it generates are composed from the dialog
events it receives from the extensions it monitors. The primary
exception is that if the monitored phone does not show any current
dialogs, the RLS adds a terminated dialog as a place-holder. This
synthesized dialog can be identified by an 'id' attribute of ';'.
Phone 207 subscribes to the RLS at ~~rl~C~207. The call-ids of these
subscriptions are first
59e9cf01-3eb32220-4789a6d7@10.1.1.171 and
later
f8274285-5919cf44-bd6bd69b@10.1.1.171.
The RLS subscribes to 208. The call-id of this subscription is
s-293749793d9ff064-15.
Trace files:
A Wireshark trace of all packets to/from (the addresses of) 207 and
208 is pcom310.pcap.
The full merged siptrace is merged.xml
The siptrace of the subscriptions from 207 to RLS is in rl207.xml.
The siptrace of the subscription from RLS to 208 is in s208.xml.
Problem 1: BLF indicator on screen does not show initially.
When I boot 207, I do not see the BLF indicator for 208. (In the
trace, the phone subscribes to the RLS, and the RLS sends its NOTIFY,
but the phone does not respond to the NOTIFY.)
About 30 minutes later, the BLF indicator for 208 appears. (In the
trace, 207 tries to renew the subscription, but receives a 481
response. 207 then sends a new SUBSCRIBE, and receives a NOTIFY that
is very similar to the previous NOTIFY. This time, 207 responds with
200.)
This pattern is somewhat repeatable, although in some tests, the BLF
indicator has not appeared at all.
Problem 2: Phone does not provide dialog events showing an incoming
call as ringing.
In the traces, I make two calls between 208 and 206. One call is made
from 208 and one is made from 206. 208 sends all the expected dialog
events to the RLS, except that no event shows the incoming call
ringing on 208 (direction = incoming, state = recipient). (I have not
checked whether no events are generated due to the incoming call, or
the events have incorrect information.)
Bug
Resolved
Major
Problems with BLF in Polycom 3.1.0
I'll refer to the packet numbers in polycom_repro.pcap
Before we start, this is my means of reproduction.
1) Alter the BLF configuration on the sipX server by adding or removing a presence subscribed speed dial. Apply changes.
2) wait for the polycom phone to receive the new NOTIFY with the changed BLF list.
3) immediately restart the polycom unit.
Step 3 is linked to the fact that there is a 60 sec TCP timeout that if met will prompt the teardown of the TCP stream.
First, the Polycom phone on rebooting is not properly tearing down its TCP connection. On a restart we attempt to unSUBSCRIBE from the BLF dialog (packet 93) but the TCP stream is never concluded with a FIN tagged packet.
Second, on restart after the phone re-registers and resubscribes, the sipX server (RLS) is sending the CSEQ 0 NOTIFY (packet 718) in answer to the new SUBSCRIBE (#716) from the source port of the old subscription. No new TCP stream is initiated and thus the Sequence and Ack numbers are incorrect. This NOTIFY should be remapped to the port in the new stream initiated by the REGISTER/SUBSCRIBE after the phone rebooted.
The out of order NOTIFY is prompting our stack to RST the TCP stream and toss the NOTIFY. After 30 minutes have elapsed, the phone will initiate its resubscribe on an new TCP stream, this time the sipX server is using the correct stream in its response thus the NOTIFY is accepted and the BLF icons appear on the UI.