Hello all,
I have a problem with callerID when call is transferred (attended) from queue to some other channel. CallerID is set as “asterisk” , that I saw on my phone when someone had transferred call from queue to me. When I don’t use queue callerID is setup as extension number from call is transferred.
Is it possible to set callerID to something else in that circumstance, or at least change that “asterisk” callerid?
Regards,
Borko
Probably, but you haven’t fully specified the situation. There are two ways of doing attended transfers with SIP. I don’t think either should default in that way. Native SIP attended transfers will look like an ordinary outgoing call from the transferror.
@david55 Thanks for your answer. I don’t know that is two ways for attended transfer. As far as I know , you have blind and attended transfer. Atxfer is defined in feature.conf , usualy as *2.
Let me describe you my situation, caller party (let’s say personA) calls some extension XYC , personB who is defined in that extension has answered and after few seconds he wants to transfer to personC with announce (attended transfer). PersonC see as callerID extensionXYC , not sip number of the personB or personA. I have found so far, on page voip-info.org/wiki/view/Aste … tures.conf following part:
Attended transfer:
Note The caller ID presented to the person you are trying to transfer the call to is not what you would expect - Asterisk sets your caller ID to be the extension the call originally arrived at which may not be the same as the extension the call was answered at. There doesn’t appear to be any way of getting the correct caller ID.
I have just the same situation like on that page. Is it completely true or there is some other way to play around with callerID.
With blind transfer I don’t have any problem.
Cheers,
Borko
Your quote seems to be irrelevant as you say you are getting the caller ID for the transferror.
I don’t use features.conf transfers; I only use native SIP transfers (which is the other type of transfer). With native SIP transfers, the phone makes a call to party C without telling the PABX that a transfer might result. As such party C always sees the transferror’s caller ID, and there is nothing that you can do about it for native SIP transfers.
@ david55
Ok, thanks, I’ve read a little bit about native attended transfer. Let’s imagine this scenario :
A calls B, B puts A on hold, B calls C and puts C on hold . How can B connect those two calls together?
Option 1: B sends INVITE C to the contact address for A (which will be on the PABX), specifying the call leg over which it was talking to A (actually the one originating on the PABX).
Option 2: B sends INVITE A to the contact address for C (which will be on the PABX, and may be the same as the original request URI), specifying the call leg over which it was talking to C (actually the one terminating on the PABX).