I am calling this a sipx 4.2.0 bug. it worked in sipx 4.0.4.
On 8/13/10 4:57 PM, Michael Scheidell wrote:
I swear, it used to work.
I have not upgraded since. running 4.2.0, cisco FW 8-13, poly 650,
3.13c, poly 335, 3.2.1.
I found an old thread:
<http://forum.sipfoundry.org/index.php?t=msg&goto=46110&S=3ab5cf1d46d4473a64aaffe6a31ebadb>
I reported this before.
it worked in 4.0.4.
" regression testing:
4.0.4 worked! 4.2.0 doesn't anymore,
someone reported this before, maybe,"
I did find out how to (supposedly) change, disable, enable rfc_2543_hold.
add this in SIPDefault.cfg: (didn't seem to matter, cisco's still send
c=0.0.0.0. which the polycom's are SUPPOSED to allow)
#image_version: P0S3-08-12-00
# rfc_2543 is OBSOLETE, c=0.0.0.0 hold is OBSOLETE, poly's use
a=sendonly, rfc_3264
# supposidly, all cisco phones from fw 7-5 use 3264.
#rfc_2543_hold: 0
so, I wonder: is the cisco phone really sending the c=.00000 or dis
sipxproxy just decide its a cisco and screw with it?
why/how did it work with 4.0.4?
--
Michael Scheidell, CTO
o: 561-999-5000
d: 561-948-2259
ISN: 1259*1300
> *| *SECNAP Network Security Corporation
* Certified SNORT Integrator
* 2008-9 Hot Company Award Winner, World Executive Alliance
* Five-Star Partner Program 2009, VARBusiness
* Best in Email Security,2010: Network Products Guide
* King of Spam Filters, SC Magazine 2008
______________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r).
For Information please see http://www.secnap.com/products/spammertrap/
______________________________________________________________________
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/
