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
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
