gmane.comp.voip.sipx.devel

New jars for jasper reports

Kevin Thorley — 2008-12-02T03:49:34

I have committed the changes for Jasper Reports. As a result, all developers will need to install the sipx-jasperreports-deps RPM. This is available in the sipxecs repo. I have updated the "Building from Source" page on the wiki with this info. After installing the RPM, please make sure to do an autoreconf and configure, at least in sipXconfig project. Kevin

Re: sipxrelay logging problems?

M. Ranganathan — 2008-12-02T03:58:34

I would not recommend removing it. I just have to be careful not to use PropertyConfigurator. It is a good place to centralize logging overrides. Ranga

Re: Is XECS-415 really fixed?

Martin Steinmann — 2008-12-02T00:44:49

I thought we had an agreement around this feature based on this thread: http://list.sipfoundry.org/archive/sipx-dev/msg14689.html The resulting implementation came a bit as a surprise and we looked at it and commented on it --martin -----Original Message----- From: sipx-dev-bounces< at >list.sipfoundry.org [mailto:sipx-dev-bounces< at >list.sipfoundry.org] On Behalf Of Krzeminski, Damian (BL60:9D30) Sent: Monday, December 01, 2008 6:24 PM To: sipx-dev< at >sipfoundry.org Subject: Re: [sipX-dev] Is XECS-415 really fixed? Martin Steinmann wrote: Nothing was said about requiring many other things. think the Because everyone is very eager to throw "the requirement was this" and "the requirement was that" around (which probably does not make much sense to many people reading this list) I'd like to take this opportunity to remind everyone how things usually work in sipXconfig: Martin and users tell us to implement user stories / usage scenarios (in many cases I - or in this case Robert - write up stories bases on some in

Re: Is XECS-415 really fixed?

Damian Krzeminski — 2008-12-01T23:24:30

Nothing was said about requiring many other things. Because everyone is very eager to throw "the requirement was this" and "the requirement was that" around (which probably does not make much sense to many people reading this list) I'd like to take this opportunity to remind everyone how things usually work in sipXconfig: Martin and users tell us to implement user stories / usage scenarios (in many cases I - or in this case Robert - write up stories bases on some initial request from the list or from Martin). We talk about stories on this list. We try to come up with a task list (list o JIRA issues). We proceed to implement the stories. I always push - and usually fail :-) - to implement the simplest thing that works first. Then we come back, look at the UI or a feature again. And we try to implement other stories. The goal is to have a quick turn around: try many things, get them better, stop early if we are heading in the wrong direction. During that time sipXconfig remains usable and people can look

Re: XECS-1694 Subscriptions initiated by RLS servermayfailto reachremote NATed phones in HA configurations

Dale Worley — 2008-12-01T22:05:42

Sorry to be so late getting back to you on this, but I've been out of town for two weeks. On Mon, 2008-11-17 at 09:10 -0500, Joly, Robert (CAR:9D30) wrote: I've looked at section 4.4 now, and clearly it covers phone calls and subscriptions from the phone to sipX. But subscriptions *from* sipX *to* the phone don't seem to be listed (on page 50, at the beginning of section 4.4). Am I overlooking something? Oddly, GRUU can provide some benefit even if the phone in question does not support GRUU: The registrar assigns a GRUU to any registration that presents an instance ID, even if the phone doesn't support GRUU. (There are some uses for instance IDs outside of GRUU production.) Since the proxy/registrar route requests addressed to the GRUU to the contact URI of the phone, the phone will receive the requests. The GRUU itself can be seen in the registration event package for the phone's registration. Though that case is not likely to happen in practice. Dale

Re: XECS-1694 Subscriptions initiated by RLSservermayfailto reachremote NATed phones in HA configurations

Scott Lawrence — 2008-12-01T21:59:10

On Mon, 2008-12-01 at 16:42 -0500, Dale Worley wrote: should be: sip:my.path.com (attribute values must be quoted)

Re: Is XECS-415 really fixed?

Martin Steinmann — 2008-12-01T21:55:17

than This was actually a requirement for this feature: To implement source routing so that gateways can be selected based on where the call originates. Nothing was said about requiering that a gateway is restricted to one location. I am all in favor of simplification that makes it possible to get this feature in. What we cannot do is introduce concepts that are hard to understand and therefore negatively affect usability. I therefore think that we have to go back and think about the original requirement and the concept of introducing a location for gateways as well as assigning users to such locations. --martin

Re: XECS-1694 Subscriptions initiated by RLSservermayfailto reachremote NATed phones in HA configurations

Dale Worley — 2008-12-01T21:42:47

If the registration has a GRUU, it is carried in a element within the element. See draft-ietf-sipping-gruu-reg-event-09, soon to be an RFC. A typical example is: sip:user< at >192.0.2.1

"<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"

(Because the UA provided an instance ID, there is an element as well.) (Oddly, a registrar can construct a GRUU for a registr

Re: Is XECS-415 really fixed?

Robert Joly — 2008-12-01T21:05:38

For sipX gurus, the idea of overlapping groups where the settings of the last group in the User Group list takes precedence but where the first group in the User Group list defines the location may not be so confusing but chances are that it will to many. Also, finding 'superadmin', 'sales' and 'engineering' intermixed with 'Ottawa' and 'Boston' in Gateway _Location_ pull-down menus is not as clean as it could be. I pleaded my case and I will stop there for fear of running another lap down the circular argument track. We'll see how much of this Damian will be able/willing to implement and we'll improve it based on the feedback we get.

Re: Interconnecting sipXecs systems

Martin Steinmann — 2008-12-01T21:05:16

what to parameters) Not that I know assuming that NAT traversal is fully automatic and transparent. --martin

Re: Is XECS-415 really fixed?

Martin Steinmann — 2008-12-01T21:01:44

they screen. organizational Except that this is not obvious to the unintended admin. I found group priorities a "hard to grasp" concept before we mingled it with location. Now with this added complexity I start to get really concerned about how to make this intuitive or document it in help texts so that people will get this right without "expensive" help. --martin

Re: XECS-1694 Subscriptions initiated by RLSservermayfailto reachremote NATed phones in HA configurations

Scott Lawrence — 2008-12-01T20:54:48

On Mon, 2008-12-01 at 14:56 -0500, Arjun Nair wrote: Hmmm... not too surprising. The reason I suggested the angle brackets (<...>) is that in SIP we have the problem that semi-colon delimited parameters are ambiguous without the angle brackets, unless you know what part of a SIP message the uri value came from. They can be either field parameters or uri parameters. Looking back at RFC 3680, it becomes clear that the encoding you suggest below is correct: The "uri" element contains the URI associated with that contact. The "display-name" element contains the display name for the contact. The "display-name" element MAY contain the xml:lang attribute to indicate the language of the display name. The "unknown-param" element is used to convey contact header field parameters that are not specified in RFC 3261. One example are the user agent capability parameters specified in [11]. Each "unknown- param" element describes a single contact header field parameter. The name of

Re: Is XECS-415 really fixed?

Scott Lawrence — 2008-12-01T20:30:52

On Mon, 2008-12-01 at 14:39 -0500, Joly, Robert (CAR:9D30) wrote: Sorry, but that argument is circular - you argue that multiple groups are rare in order to argue against using multiple groups. I use multiple groups a lot when setting things up, and overlapping groups are very useful because they express different axes - sales vs engineering and Ottawa vs Boston for example.

Re: Is XECS-415 really fixed?

Damian Krzeminski — 2008-12-01T20:15:50

You can change the group priority by re-ordering them on the group screen. The order in which you enter the group names on a user screen does not matter. It's easy to keep you geographical based groups above you organizational groups. That's correct. Introducing a designated location concept in UI (which again - I am not really arguing against) will not change the fact that group order will influence the location. And think about it like that: people who are in Ottawa probably will have other common things than just which gateway should be used: so admin would probably have a group for them anyway. Asking admin to also create a location and assign it to that group is asking admin to do more things. [...]

Re: Interconnecting sipXecs systems

Scott Lawrence — 2008-12-01T20:03:36

On Mon, 2008-12-01 at 14:26 -0500, Damian Krzeminski wrote: None that I can think of for now. _______________________________________________ sipx-dev mailing list sipx-dev< at >list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev

Re: XECS-1694 Subscriptions initiated by RLS servermay failto reachremote NATed phones in HA configurations

Arjun Nair — 2008-12-01T19:56:49

This doesn't validate as anyURI (using sipx-validate-xml). Here's my latest proposal: Reg-info xml: sip:joe< at >pc34.example.com

my.path.com

This validates, and it should maintain interop/backward compatibility for reg-info. Arjun

Re: Is XECS-415 really fixed?

Robert Joly — 2008-12-01T19:39:46

That is correct however some subtleties need to be mentioned. #1- Scenarios that have users belonging to multiple groups are not frequent and #2 for those cases, conflicts could be avoided altogether by using the user-based location setting instead of the group-based ones. I have my opinion on what is necessary but it does not really count because I'm not out there talking to customers and trying to sell the product. I think we'll have to defer to Martin on that one.

Re: Interconnecting sipXecs systems

Damian Krzeminski — 2008-12-01T19:26:10

Makes sense to me. Are there any special parameters (other than generic gateway parameters) for such connection? D. _______________________________________________ sipx-dev mailing list sipx-dev< at >list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev

Re: sipxrelay logging problems?

Damian Krzeminski — 2008-12-01T19:19:31

log4j.properties should probably not be monopolized by sipXconfig (it comes from times when sipXconfig was the only java application in sipx). I'll gladly move out of the way with it. I do not even remember from top of my head how sipXconfig is finding it at the moment... D.

Re: Problem removing services from a server

Scott Lawrence — 2008-12-01T18:46:55

On Mon, 2008-12-01 at 11:47 -0500, Joe Attardi wrote: It would be more productive to enumerate the sequence of xml-rpc actions between sipXconfig and sipXsupervisor (as opposed to GUI clicks).

Re: Is XECS-415 really fixed?

Scott Lawrence — 2008-12-01T18:44:17

On Mon, 2008-12-01 at 11:04 -0500, Robert Joly wrote: Actually, my understanding is that the group hierarchy is fixed - it depends on the order of the groups in the groups list, not on how they are entered. (is this right Damian?) But since users can be in multiple groups, you're right back where you started with possible conflicts. "Conceivable" is a metric that leads to the Dark Side. Is it "necessary" that we be able to this? I don't think so.