On Thu, 2008-09-25 at 10:10 -0400, Paul Mossman wrote: > Latest analysis from Polycom: The NOTIFY sent to the phone in response > to its new SUBSCRIBE after reboot is using the old pre-reboot TCP > stream information and so it is not recognized and is subsequently > shutdown by TCP RST. The SCS500 should probably either respond to the > TCP stream initiated by the new SUBSCIBE from the phone or on receipt > of the RST, SYN a new stream and send the data that way.
OK, even after I revised the problem description, the sipX problem is not clearly described. The general sipX problem is: If a sipX server wants to send a message to a destination (e.g., a phone), via TCP, it will attempt to use an already-established TCP stream to that destination. But if the destination has been rebooted or reset since the TCP stream was established, the destination will not know of the TCP stream. sipX (or rather the kernel) sends the TCP data packets to the destination, which rejects them with a packet with "RST" set. At that point, sipX should attempt to open a new TCP stream to the target on which to send the message, or should attempt alternative transports. Instead, sipXtack returns a transport error to the higher-level code, which causes the higher-level code to think the destination is unreachable, often leading to functional failures. The observed failure is: A Polycom phone has subscribed to BLF information and receives the NOTIFYs via TCP from the RLS. The phone reboots from loss of power. The phone subscribes again the BLF information, using as its contact address the same address and port as before, with TCP transport. The RLS sends its initial NOTIFY to the phone using the TCP stream that was established with the phone before rebooting. This attempted transmission fails (as the phone does not know of this stream), leaving the phone with no BLF information, and the RLS terminates the subscription (as the application code received an error from attempting to send the NOTIFY). The phone receives no BLF information until it attempts to re-subscribe, at which a series of error-recovery actions on the part of the phone and RLS reestablish effective communication. Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
