gmane.comp.voip.sipx.devel

Forum - http://sipfoundry.rudaserver.com

Rudá Cunha da Silva — 2008-10-12T02:17:39

Re: Header Addresses Review proposal

M. Ranganathan — 2008-10-11T04:14:20

On Fri, Oct 10, 2008 at 6:19 PM, Scott Lawrence nortel.com> wrote: I do not know of an ITSP that would object. That transformation would be the correct thing to do. (Actually Registration with the ITSP does not have a bearing in this matter. ) No. For inbound calling, bt.com for example, does not use a P-A-I header. Cbeyond.net and AT&T send me a PAI header in the inbound call which has the same information as the From header.

Re: Header Addresses Review proposal

Scott Lawrence — 2008-10-10T22:19:07

On Fri, 2008-10-03 at 14:28 -0400, M. Ranganathan wrote: I've reviewed the spreadsheet and have a couple of hypothetical questions: 1. In some cases, you remove any PAI header coming from the sipXproxy. If sipXbridge were _always_ to send a PAI header to the ITSP containing the exact same identity sipXbridge had used to register with the ITSP, do you know of any ITSPs that would object? 2. Do all ITSPs that you've tested strip PAI and present the From header information as PSTN caller-id?

Re: Question on new service state names

Scott Lawrence — 2008-10-10T21:54:54

On Fri, 2008-10-10 at 16:59 -0400, Joe Attardi wrote: It means the state has not been initialized... you _should_not_ ever see that one... It means that it is not running and it's not supposed to be running. Stopping means that sipXsupervisor has been told to Stop a running process, so the permanent state has been changed to Disabled and the process is being stopped. ShuttingDown means the process is enabled, but sipXsupervisor has been told to exit, so the permanent state is Enabled but it is being stopped now. You probably will not often see ShutDown - it would only happen in the short interval during sipXsupervisor shutdown when some managed processes have stopped and others have not (so supervisor itself is still running).

Question on new service state names

Joe Attardi — 2008-10-10T20:59:14

Hi everyone, I'm working on XCF-2915 (sipXconfig must recognize new service state names) and am adding a few status icons along with the status text. However, I'm a bit unclear on what some of the states represent. Could anyone help fill in the blanks for me? According to Carolyn's comments in the description of XCF-2915, the states are: Undefined, Disabled, ConfigurationMismatch, ResourceRequired, Testing, ConfigurationTestFailed, Starting, Stopping, Failed, Running, ShuttingDown, and ShutDown Some of them make sense, but some of them I'm not sure about: * What is "Undefined"? Is that the equivalent of "Unknown" ? * The services seem to show "Disabled" whenever I stop one of them. Does "Disabled" really mean "Stopped", or "Not Running" ? * What's the difference between "Stopping" and "ShuttingDown" ? * When is the state "ShutDown" ? When I stop the service, it seems to go straight back to "Disabled".

New Polycom SoundPoint IP config file scripts insipXtools/src

Paul Mossman — 2008-10-10T20:41:57

Hi all, I had a look at the existing polycom-config script at http://sipxecs.sipfoundry.org/rep/sipXecs/main/sipXtools/src/ It didn't do quite what I was looking for, so I added some new scripts: polycom_config_dump.rb ---------------------- This script parses the specified Polycom SoundPoint/SoundStation IP master configuration file and extracts the individual sip and phone1 configuration parameters, which it dumps (sorted) into a flat INI file. (DUMP_.ini) The key thing here is that it starts with the .cfg then parses multiple CONFIG_FILES, applying overrides in the same manner as the actual phone. As an added convenience, the script can retrieve files given a URI: ./polycom_config_dump.rb ftp://PlcmSpIp:PlcmSpIp< at >example.com/0004f2064015.cfg polycom_ini_diff.rb ------------------- This script compares to the two specified INI files (that were generated by polycom_config_dump.rb) and reports the following differences (in sorted order): D=> Parameters that appear in both files, but with different values. 1=> Parameters that appear only in the first file. 2=> Parameters that appear only in the second file. Yes, I re-invented the "diff" wheel. But, I needed an easy way to see which parameters were missing from one file or the other, versus those that just had different values. The impetus for creating these tools was to find all the parameters from Polycom default files that are missing from our generated profiles. (Which is the root cause for issues such as XCF-2877, which was originally raised against Polycom.) -Paul paul.mossman< at >nortel.com

Re: Build failure with load 13670

Scott Lawrence — 2008-10-10T20:08:53

On Fri, 2008-10-10 at 15:21 -0400, Huijun Yang wrote: or, if you have the current unstable sipxecs repo configured, you can just: sudo yum install nsis

Re: SIP Trace installer: Windows file associations?

Paul Mossman — 2008-10-10T20:07:03

Dale wrote: Thanks! I've raised XECS-1781 to track adding associations to the tool upon install. -Paul

sipxportlib-3.10.2 make check fails under

2008-10-10T20:02:13

Re: Build failure with load 13670

Huijun Yang — 2008-10-10T19:21:41

Re: sipXconfig now collects IP addresses of alltheservers in the cluster

Dale Worley — 2008-10-10T18:41:26

In that particular use-case, what you want is "What sipX starts, use DNS to look up the host names, verify that they match the interface addresses of the servers, and generate the appropriate configuration files accordingly." When the admin configures it, you do want to warn him if DNS can't deliver addresses for those host names. Dale

Build failure with load 13670

Huijun Yang — 2008-10-10T18:39:47

Re: value of registar-config/SIP_REGISTRAR_DOMAIN_ALIASES

Damian Krzeminski — 2008-10-10T18:21:55

[...] Not just looked: I actually fixed it :-) Paul's patch is undoing the part of the fix. The mechanism of injecting additional initial alias is still there and can be used if needed. Martin told me that it creates more problem than it solves that's why I am removing it now. This is the relevant change: http://sipxecs.sipfoundry.org/ViewVC/sipXecs?view=rev&rev=13672 D.

Re: sipXconfig now collects IP addresses of all the servers in the cluster

Damian Krzeminski — 2008-10-10T18:11:22

Yes. That's what I prefer as well. The lookup should happen while you are looking at the screen and the address is displayed and stored. You have to enter IP address there, so if the lookup fails you won't be able to proceed without entering the address. Agreed. That would have all the issues that were raised when I asked my stupid question... D.

Re: sipXconfig now collects IP addresses of all the servers in the cluster

Andy Spitzer — 2008-10-10T18:05:12

Woof! On Fri, 10 Oct 2008 13:41:22 -0400, Damian Krzeminski nortel.com> wrote: Is that a dynamic button on the screen like: Lookup IP address [woof.us.nortel.com] Or is it just a "when I get around to creating the config file, use DNS to lookup woof.us.nortel.com? I'd prefer the former, so the user can: A) See if DNS is working right now. B) See that the IP address returned makes sense C) Know exactly that the IP address shown will be in the one in the config files. So, instead of making them type an IP address, they can enter a host name or fqdn, and sipXconfig will look it up right then and there, and use the looked up value as if it was typed in. The latter sounds problematic in case DNS isn't available at the time the config is generated, or if it happens to have changed since they last looked. --Woof!

Re: sipXconfig now collects IP addresses ofalltheserversin the cluster

Scott Lawrence — 2008-10-10T17:58:54

On Fri, 2008-10-10 at 13:05 -0400, Dale Worley wrote: Can we depend on the user not finding a way to set things up so badly that nothing works including the alarm? No. No matter what we do, someone will find a way to mess it up completely. But in those cases, they'll know the system isn't working.

Re: value ofregistar-config/SIP_REGISTRAR_DOMAIN_ALIASES

Scott Lawrence — 2008-10-10T17:55:19

On Fri, 2008-10-10 at 12:10 -0400, Damian Krzeminski wrote: In a perfect world it would not be needed, but it is harmless and will allow some really lame phones to work that otherwise would not, so leave it. The configuration you describe looks correct to me.

Re: value of registar-config/SIP_REGISTRAR_DOMAIN_ALIASES

Robert Joly — 2008-10-10T17:53:16

Have you looked at XCF-1969?

Re: Port allocation test service

Dale Worley — 2008-10-10T17:46:54

I don't know much about the alarm system, but it seems to me that we do need a Java interface for it. Dale

Re: sipXconfig now collects IP addresses of all the servers in the cluster

Damian Krzeminski — 2008-10-10T17:41:22

So based on your, Dale's and woof's feedback this is what I'd like to do. - WON'T fix http://track.sipfoundry.org/browse/XCF-2909 - since we clearly have to collect IP addresses - new issue: add configuration test to verify if configured names resolve to configred IP addresses (I wanted to do that anyway, verifying if DNS is configured correctly was on Martin's issues list) - failing configuration test is hard to ignore in sipXconfig UI - new improvement: let user to select 'use DNS' option on Edit Server screen - it will force sipXconfig to resolve the hostnames when generating configuration (it's for admins who want to rely on independently configured DNS server) Comments? D.

Re: Port allocation test service

M. Ranganathan — 2008-10-10T17:08:18

Sorry to ask about something I might have missed on the list but as a good citizen of the ecosystem, how can sipxbridge send an alram? I can udertake to javatize that and make it available in sipxcommons. Thanks. Regards Ranga