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