The issue as Martin points out is that the user doesn't know any better. I could see a large system where a user may not know the direct user "extension" but knows the DID.
If it can be addressed it would be smart. Al -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of M. Ranganathan Sent: Friday, August 22, 2008 7:21 PM To: Martin Steinmann Cc: [EMAIL PROTECTED] Subject: Re: [sipX-dev] Hairpinned calls ( originating from the pbx backto the pbx ) On Fri, Aug 22, 2008 at 7:10 PM, Martin Steinmann <[EMAIL PROTECTED]> wrote: >> >> >>Scott Lawrence wrote: >>> >>> So there are two phones on the system 201 and 202, but 202 also has >>> a PSTN DID 555-1202, and 201 calls that DID number so that the call >>> goes out via the ITSP and comes back in? >>... >>> The real answer to such a thing is to have a rule that prevents the >>call from looping out in the first place. >> >>On our sipXecs trial system we minimize the chance of such scenarios >>by using user aliases that are equal to the person's DIDs with dialing >>prefix. This ensures that the calls made using your colleague's DID >>are never sent to PSTN and are terminated locally. >>In the example above if the PSTN prefix is 9 then: 202 has alias >>5551202 for the purposes of receiving incoming calls and it also has >>alias >>95551202 for the purposes of resolving outgoing calls locally. >> >>It does not solve the problem entirely since one can still end up with >>a call between 201 and 202 via ITSP due to call forwarding or far end >>transfer. >> >>Cheers, >>Mark. > > > How can this be made intuitive to an ordinary user / admin? It seems > to me that even if there is a fix using smart aliases it does not > solve a users problem unless is is made easy to use and intuitive to > configure. How can this be accomplished? > --martin > AT&T conformance testing requires this case to work anyway and hence I have no choice but to address it. Adds a few states to the B2BUA state machine but its within reach. 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 _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
