>>> "Dave Deutschman" [EMAIL PROTECTED]> 08/05/08 04:02PM >>
<snip>
We have investigated issues with the Buddy Watch and BLF functions
with
various versions of SIPxchange and Polycom firmware. We have found
(and
reaffirmed by Polycom) that issues arise with these functions if you do
not
use the sip.cfg and phone1.cfg templates provided in the firmware .zip
file
with the version of sip.ld in the phone.
<snip>
Precisely, all kinds of thing's happen if you use mismatched files.
Typically in a lab environment we will remove all polycom soundpoint
files except the default cfg files that ship with the release, then
upload the version we want to test. We also format the file system on
the phone prior to letting it register so we can make sure it gets the
proper config file and not it's last known working one.
I've learned recently that looking at the sipxrls.log file will help
understand where the problem is (I had a remote test unit connecting via
the net through an Ingate, and found it stopped receiving calls or
BLF/RLS when upgrading to 3.10.2. I think 3.10.2 switches some things to
TCP, and I found that by setting my MTU (as suggested on the list) to
smaller than 1500 (1460), had very adverse affects once I put 3.10.2 in
place. After setting the log into debug mode and looking at it with tail
-f, I saw VERY LONG branches for that phone, at which point I set the
Ingate to remove via headers for it, but it took a while for RLS to
communicate properly, actually hours.
In 3.10.2 there were some changes to RLS and Polycom to make it more
"robust", but there were also some other changes to force large requests
to use TCP first which changes a lot of things of removes some problems
for ITSP trunking (I think).
I also try to "not" mix models too much or firmware, whenever possible.
In my case I have local and remote users and sometimes it still does not
"work" right (all on bootrom 4.1 and firmware 3.03c, all using 650's)
all the time. Locally it works much better, but in the cases of remote
users, it can be a little problematic. I also know there are more
changes (hopefully bug killers) coming in the 3.1 firmware release.
I'm not sure this answers things for you, but I do suggest making sure
the environment for testing is "clean" of any legacy files from multiple
firmware versions before uploading and activating one whenever
possible.
**Dale's advice to me to do rls debugging:
The way to start debugging this is to set logging to DEBUG (or at
least
INFO), then do a number of restarts, checking each time whether the
BLF
lights show and whether they function properly. Take notes as to when
you do each action, preferably in GMT ("date -u"). Run the sipXrls
log
through syslog2siptrace and use sipviewer to look at the XML file.
Then
you can check whether sipXrls is delivering the right information to
the
phone, and thus whether it's a phone problem or a sipXrls problem --
Do
the contents of the NOTIFY messages match what should be reported?
**
It would be excellent to fully understand the changes for large packets
and what should be affected or changed when upgrading to 3.10.2.
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
