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