---------- Forwarded message ----------
From: Henry Coleman <[email protected]>
Date: Thu, Feb 17, 2011 at 5:48 PM
Subject: Re: [on-asterisk] End to End callerid
To: Bruce N <[email protected]>


I have just completed checking this out on my own system and I can confer
that the handling of CID is correct in all cases except
an attended transfer (which is pre-announced anyway).
Thank you for helping out, it really helped.
TTFN Henry

On Thu, Feb 17, 2011 at 5:28 PM, Bruce N <[email protected]> wrote:

>
> I can confirm this finding as well with multiple installs of PiaF. With
> FreePBX 2.8 you can change CID at many levels including Trunk, Outbound
> Routes, Extensions, and Emergency Routes. I think the configuration built
> into the custom files are now smart enough to pass Caller ID as expected
> (like Dave noted) in different situations since the product is more mature
> now.
>
> Between, seems that lots of us are relying on FreePBX now-a-days for ease
> of use?! Version 2.8 seems solid and pretty much is business grade now. Just
> wish they get rid of all the custom files and come up with a more clean
> solution to the *_custom.conf files or go SQL based for everything.
>
> -Bruce
>
> > Date: Wed, 16 Feb 2011 15:04:55 -0500
> > From: [email protected]
> > To: [email protected]
> > CC: [email protected]
> > Subject: Re: [on-asterisk] End to End callerid
> >
> > > > From: Henry Coleman <[email protected]>
> >
> > > > > Date: Tue, Feb 15, 2011 at 8:06 AM
> > > > > Subject: Re: [on-asterisk] End to End callerid
> > >
> >
> >
> > > > > If I have an incoming call to an extension (DID) to Ext 200 and
> then
> > > call
> > > > forward this to an external number the call at that number displays
> the
> > > > Calling ID set by the extension or trunk not the original incoming
> call.
> > > > > The same problem exists when transferring a call from an extension.
> ie.
> > > a
> > > > call comes from outside and displays the Caller ID but if the call is
> > > then
> > > > "blind" transfered the Caller ID is lost and the Caller ID is that of
> the
> > > > extension (if internal) not the original number. I think I need some
> code
> > > > that will preserve the original Caller ID after being transferred or
> > > > forwarded.
> > >
> >
> > Hi Henry,
> >
> > I don't know that anything as complicated as a macro is required.
> >
> > I'm running PBXiaf 2.5.2.2. I don't think I've done anything special on
> my
> > end, in fact, our situation might be a bit more complicated. I ran a few
> > scenarios and it worked as desired or in one case as expected.
> >
> > 1) Outside call to my DID. I answered the call, did a _blind_ transfer
> > (just hit the transfer button and released the call) to my cell phone.
> The
> > callerID shown on my cell phone was that of the original outside caller.
> >
> > 2) Outside call to my DID. I setup CFNA on my Aastra phone to forward to
> my
> > cell. Call rang once on my phone then hit my cell. The callerID shown on
> > my cell phone was that of the original outside caller.
> >
> > 3) Outside call to my DID. I setup the VMX locator so that the caller
> could
> > press '1' and be transferred to my cell phone. Outside call hit my VM,
> > pressed '1' and call hit my cell as expected. The callerID shown on my
> cell
> > phone was that of the original outside caller.
> >
> > 4) ** Not as desired but as expected ** Outside call to my DID. I did an
> > attended transfer to my cell phone, the callerID was my DID, not that of
> the
> > outside caller. This is expected because the actual events for attended
> > transfers are Hold -> Dial cell phone -> Introduce call -> Conference ->
> > Release.
> >
> > Some background on our config: We're running PBX in a Flash. Asterisk
> > 1.4.something.
> >
> > Our trunk config is a bit weird: We have a PRI coming into a physical box
> > running Asterisk. That box just takes the PRI calls and sends them via
> SIP
> > to the PBXiaf box which runs on vmware. That's why I say our system is a
> > bit more complicated. There are 4 legs to each of those calls and the
> > CallerID was preserved along all of them.
> >
> > I know this isn't really prescriptive for you in terms of telling you how
> to
> > make it happen. I don't know what the differences are between your setup
> > and mine but at least you know you don't have to start coding your way
> out
> > of the problem.
> >
> > I hope that helps. Let me know if you need further info.
> >
> > Dave
>
>



-- 
*Henry L. Coleman *
***Per: VoIP-PBX.ca
*
*
*








-- 
*Henry L. Coleman *
***Per: VoIP-PBX.ca
*
*
*

Reply via email to