On Mon, 2009-02-02 at 11:13 -0500, M. Ranganathan wrote: > Scott Lawrence wrote: > > On Mon, 2009-02-02 at 10:23 -0500, M. Ranganathan wrote: > > > >> On Mon, Feb 2, 2009 at 10:07 AM, Scott Lawrence > >> <[email protected]> wrote: > >> > >>> On Sun, 2009-02-01 at 19:08 -0500, M. Ranganathan wrote: > >>> > >>>> Hello > >>>> > >>>> I am working on XCF-3252 > >>>> > >>>> http://track.sipfoundry.org/browse/XCF-3252 > >>>> > >>>> This issue is talking about the admin user INVITING a third party but > >>>> I have problems with the conference owner INVITing a third party. I > >>>> fixed some things but other problems remain. > >>>> > >>>> Here is the scenario that is causing problems : > >>>> > >>>> I have an alias for an extension that I wish to INVITE to a conference > >>>> ( say 204 ). I can dial this extension fine with a phone. Then (after > >>>> fixing some other problems) I am trying to INVITE 402 using third > >>>> party call control. For this, I need to send INVITE to 402 but I get > >>>> NOT FOUND from the Proxy Server. > >>>> > >>>> > >>>> Hypothesis: I think this might have something to do with the > >>>> sipx-userforward=false parameter but I am not sure. Attached is a > >>>> trace for the successful call as well as a failed call to that > >>>> extension. > >>>> > >>> Your hypothesis is correct. > >>> > >>> This is a significant problem with the semantics of our 'user-forward' > >>> attribute... > >>> > >>> The meaning of that attribute is really "do not apply any contacts to > >>> this message derived from the "alias" database. The attribute was > >>> created to allow services that really want to address the users > >>> registered phones to exclude other forwarding targets. By including > >>> this attribute, you are instructing the call not to use those targets, > >>> but in your configuration the "phone number" is an alias for the user > >>> (whose real AOR is 'us...@...'). > >>> > >>> Since we don't have any way to distinguish the purpose for which an > >>> alias was added, we can't tell the difference between what you were > >>> doing and a forwarding entry added by the user that sends calls to > >>> his/her cell phone or administrative assistant or whatever. > >>> > >>> In fact, we use aliases for a number of different purposes, and the > >>> 'user-forward' is big non-discriminatory hammer - it just disables all > >>> of them. This just came up recently in some other context, but I can't > >>> seem to find where I wrote about it last. > >>> > >>> So... if you remove that attribute from the invite you generate, then > >>> users configured with extensions as aliases will work again, but your > >>> INVITE may also find its way to other places you don't want it to. At > >>> the moment, that's the choice you face. > >>> > >>> I think that the real solution to this is to implement a different and > >>> more discriminating filtering capability in the redirect server - one > >>> that labels the source of each contact with some semantic tag and then > >>> allows each request to specify either a set of tags to be used or a set > >>> to be ignored. This is going to take some significant work to figure > >>> out all the scenarios we need to support, but the result would replace > >>> both the 'user-forward' and 'sipX-noroute' attributes we're using now. > >>> > >>> > >> As you state above, the reason why that parameter was put there was on > >> the INVITE request URI so that one could avoid being forwarded > >> inadvertently. I am also reading that we may not have the time to fix > >> this right at the moment (we can try but it can take some time and > >> hence may not be do-able for this release?). So what is the conclusion > >> ? > >> > >> There are three choices: > >> > >> Sipxconfig Change the help text so the extension cannot be entered > >> there so people must use the entire address u...@sipx-domain to dial > >> and we clearly state that aliases will not work. Is this an acceptable > >> solution for the moment. > >> > >> The second choice would be to just disable the "INVITE third party to > >> conference" feature (presumably, not acceptable as we want this > >> feature). > >> > >> Or we simply allow forwarding and live with the expected consequences > >> of doing so as you state above. > >> > >> Any ideas on which direction is best? I would vote for #1 as I would > >> not want for my secretary to attend conferences ( especially because I > >> do not have one :-) ). > >> > > > > My general rule is "the call must go through", so I'd choose to allow > > alias-based forwarding. This may result in some interesting failure > > modes, but they are failure modes that a human can figure out ("oh... > > you wanted Bob but he has his phone forwarded to me today") as opposed > > to the current "it broke" situation. > > > > > > > Another option would be a checkbox in the sipxconfig screen that > indicates whether or not call forwarding is allowable on the INVITE. > This way, if a user selects it he is aware that the call may be > forwarded on the INVITE
Non-starter, I'm afraid - you're a developer on the project, and _you_ didn't understand the implications. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
