On Mon, Feb 2, 2009 at 2:08 PM, Scott Lawrence <[email protected]> wrote: > > 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. > > >
I don't follow. If the flag is set, then I put "dont forward" on the request URI in which case you have to use the u...@domain in the entry box. If the flag is not set I use "forward" on the request URI. Kindly explain why this does not work? Also please note that your analysis of the issue is not quite right in JIRA. You can indeed invite third party to confences when logged in as administrative user. Thank you Ranga -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
