History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: XCF-2576
Type: Improvement Improvement
Status: Open Open
Priority: Critical Critical
Assignee: Unassigned
Reporter: Scott Lawrence
Votes: 0
Watchers: 0
Available Workflow Actions

Resolve
Request Information
Operations

If you were logged in you would be able to see more operations.
sipXconfig

*force* the refer_brackets parameter to 'on' for Snom phones

Created: 2008-05-21 10:18   Updated: 2008-10-22 17:55
Component/s: snom, settings
Affects Version/s: 3.10.2
Fix Version/s: None

Original Estimate: Unknown Remaining Estimate: Unknown Time Spent: Unknown
Issue Links:
Dependancy
 
This issue required for:
XECS-1410 disambiguate transfer target addresses Major Open
Related
This issue related to:
XCF-1797 snom "Refer Brackets" should be enabl... Major Closed
 


 Description  « Hide
Snom phones have a setting 'refer_brackets' that controls whether or not the phone puts <> around the uri value in a Refer-To header.

I don't know what the point of this parameter is, since leaving them off produces a semantically incorrect result if the URI has any url or header parameters, but doubtless there is some environment where this hack is needed.

With changes in the sipXproxy in version 3.10.2 (XECS-1410), leaving off the brackets will cause all consultative transfers (and some blind transfers) to fail, so we need to fix (not merely default) the value for this parameter to 'on'.


 All   Comments   Work Log   Change History      Sort Order:
Michael Haag - 2008-05-21 10:38
The default value of this snom config param was fixed in response to my filing a prior bug about the same issue (XCF-1797). So, it's interesting that the system Scott was testing earlier this week had snoms configured with the Refer option disabled. Perhaps the sipx sysadmin had tinkered with that config option, or the sipx server had been upgraded from a release prior to our changing the default (such that the previous default was retained, or the snoms weren't configured using sipxconfig. Regardless, Scott's assertion that we should *force* that snom config option to be enabled is a good one. I will add emphasis to the subject line, so it's clear the issue is about forcing the value, not just defaulting it.