On Thu, Sep 18, 2008 at 11:57 AM, Alfred Campbell <[EMAIL PROTECTED]> wrote: > Looking at this issue I wanted to get some opinions on expected behavior for > sipXbridge. (this is coming from XECS-1692) > > > > If a customer has ISDN (BRI/PRI) and sipXbridge trunks from an ITSP I can > see this causing quite a few problems. If your primary DID is out the ISDN > and your CLID is set for your user account the sipXbridge will not work for > you? > > Does everyone see this as a configuration error? > > Regards, > > Al
Hello! Let me describe mechanistically what happens and maybe we can discuss things from there: 1. At the signaling level, I select an ITSP account on the basis of request-URI domain AND the caller-ID of the inbound INVITE at sipxbridge. The caller ID comes to me in the From OR PAI header ( for anonymous calling ). I match these two quantities in my account database to determine the ITSP account. I need to do this in case of being challenged on the INVITE. (Not all ITSPs will challenge INVITE). I assume the user name in the account is the caller iD to do this match. 2. If I cannot find a caller ID that matches anything in my account database, I pick the first one that matches the outbound Request URI domain and rewrite the From header to match the user name for that account. I cannot send an INVITE to an account without doing the edit of the >From header to match what they expect when sending out an invite in case 2. Otherwise INVITE will be rejected. 3. If the requirement to be able to support multiple accounts from a single provider can be removed, I can go with #2 and just forward along the From header un-edited. However, I DO need the user name in my account database because I do have to REGISTER with ITSPs. Replicating this information (both in IMDB as a caller id and in sipxbridge.xml as a user name) is unavoidable in cases where Registration is required on initialization. Thanks! Ranga. > > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > -- 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
