[Home]

Summary:ASTERISK-13231: bad callerid on incoming SIP transferred calls
Reporter:zerros (zerros)Labels:
Date Opened:2008-12-16 09:27:25.000-0600Date Closed:2008-12-16 11:33:03.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_dial
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Hello,  forgive me in advance for my bad english. I'm a french people.

I have a problem with the atxfer features on incoming calls. If a incoming calls is answerd by the receptionnist and she has to transfer the call using atxfer, the callerid displayed on the final ST2030 is the number that the external caller have dialed.

The final person can not know that it is a direct or a transferred call.

If I use blindxfer, the callerid is OK : the number of the original caller is displayed on the phone.

I think there is a bug with atxfer. the callerid have to be the local callerid of the receptionnist.

I have tried it on the 1.4.22 asterisk version.

****** ADDITIONAL INFORMATION ******

features.conf :
[featuremap]
blindxfer => ##
atxfer => **

extensions.conf :

[globals]

[default]

[incoming_calls]
exten => zerros,1,Answer()
exten => zerros,n,Dial(SIP/777,25,tTwW)
exten => zerros,n,HangUp()

[internal]
exten => _XXX,1,Dial(SIP/${EXTEN},25,tTwW)
exten => _XXX,n,HangUp()

[test]
include => internal

exten => _XXXX.,1,Dial(SIP/${EXTEN}@ippi_out,25,tTwW)
exten => _XXXX.,n,HangUp()

sip.conf :

;04XXXXXXXX
register => xxxxx:xxxxx@ippi.fr/xxxxx

[ippi_out]
type=peer
host=ippi.fr
user=xxxxxx
secret=xxxxxx
fromuser=xxxxx
fromdomain=ippi.fr
nat=yes
canreinvite=no

[ippi_inc]
type=peer
host=ippi.fr
context=incoming_calls
nat=yes
canreinvite=no

[777]
type=friend
context=test
username=777
secret=777
callerid=test <777>
host = dynamic
nat=no
disallow=all
allow=alaw
allow=ulaw

[778]
type=friend
context=test
username=778
secret=778
callerid=test2 <778>
host = dynamic
nat=no
disallow=all
allow=alaw
allow=ulaw
Comments:By: Joshua C. Colp (jcolp) 2008-12-16 10:00:11.000-0600

Can you please provide console output as an attachment with this? I just did a test to confirm callerid was what I expected and it was, I did not see the behavior you are seeing.
By: David Woolley (davidw) 2008-12-16 11:25:38.000-0600

I think what is being said is that the final callee (party C) sees the caller-id of the secretary (party B), which, in simple cases, is what the external caller (party A) dialled, but may not be.

I'm not sure of the details for res_features transfers, but:

- for attended transfers in general, the caller-id is fixed at the time of the enquiry, and it is not possible to know that this is actually an attended transfer, rather than an enquiry;

- for SIP transfers, the enquiry is indistinguishable from a new call on a second line on the transferror's phone, as far as the PABX is concerned (although the phone may instruct party C to take over the call between A and B, that switching is handled within Asterisk, not passed to party C's phone - Asterisk is a back to back user agent, and the conversation between the PABX and party C is a separate SIP connection) - this means that if a res_features transfer gave party A's caller-id, it would be inconsistent with a SIP transfer;

Also, the same sequences, but more likely to be treated as an enquiry, are used in broker situations, and, in that case, it may well be undesirable for the target of the enquiry to know who the broker's client is.


By: Joshua C. Colp (jcolp) 2008-12-16 11:33:03.000-0600

Ah yes, now that I read it a few times I can see that he means that. Thank you davidw for a second pair of eyes. The capability to update callerid information post-attended transfer is going to be added to a future 1.6 release but not 1.4. It will require the device to have the capability to support such a thing. Sorry, but this is just the way it is for now.