[Home]

Summary:ASTERISK-02451: [patch] Caller ID wrong on call transfer
Reporter:dsandras (dsandras)Labels:
Date Opened:2004-09-23 09:14:03Date Closed:2008-01-15 15:22:14.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Transfers
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) app_dial_patch2.txt
( 1) app_dial.patch
( 2) app_dial.patch2
Description:I have several Grandstream phones (among others).

If user A calls user B, and user B transfers (blind transfer) user A to user C, user C sees a call coming from user A, which is correct.

If user B calls user A, and user B transfers (blind transfer) user A to user C, user C sees a call coming from user B, which is incorrect.

The same happens when transfering a call to a Zap channel.
Comments:By: Brian West (bkw918) 2004-09-24 06:53:48

This isn't a major bug at all.  Please review the bug posting guidlines.  Something major would be if the PBX stoped functioning after the behavior was observed.  This is accually something that is very easy to fix in your dialplan.

Try this:

http://www.bkw.org/~brian/doc/save_callerid_always.doc
By: Mark Spencer (markster) 2004-09-27 20:35:07

This is option "f" to the Dial command.
By: Mark Spencer (markster) 2004-09-27 20:36:53

Oops misunderstood the problem.  This is not the incorrect behavior -- you cannot know the callerid of the party you are *calling* so when you transfer them it must be your callerid that shows up.  There is no other callerid that makes sense.
By: dsandras (dsandras) 2004-09-28 03:01:36

I don't understand your answer.

If user Mark calls user Andre, and if user Mark transfers Andre to Christian, then Christian should be able to see Andre's caller id when receiving the call, but he sees Mark as caller. When doing the transfer, Andre's caller ID is available for Christian, as for SIP at least there is an INVITE from him. Am I wrong?

If user Andre calls user Mark, then Mark transfers Andre to Christian, then Christian will see Andre as caller id.
By: dsandras (dsandras) 2004-09-28 03:09:32

Actually, I'm not against the fact that you see the callerid of the person who issued the transfer, but then it should be like that in both cases described above. Currently in one case the Callerid of transferer is displayed, and in the other, the callerid of the transferee is displayed. Both should be available in the Invite.
By: dsandras (dsandras) 2004-09-28 05:12:22

I've reread the RFC and examined the SIP messages exchanged with Asterisk.
->
REFER sip:6002@172.17.100.111 SIP/2.0
Via: SIP/2.0/UDP 172.17.100.62;branch=z9hG4bK42f9f298815ceaea
From: "Damien GrandStream" <sip:6003@172.17.100.111;user=phone>;tag=904719c6a838fab7
To: <sip:6002@172.17.100.111;user=phone>;tag=as1ae5bfbf
Contact: <sip:6003@172.17.100.62;user=phone>
Refer-To: sip:6001@172.17.100.111;user=phone

[...]

INVITE sip:6001@172.17.100.48 SIP/2.0
Via: SIP/2.0/UDP 172.17.100.111:5060;branch=z9hG4bK1329ec39
From: "Damien GS Gauche" <sip:6003@172.17.100.111>;tag=as352d6644
To: <sip:6001@172.17.100.48>
Contact: <sip:6003@172.17.100.111>

The From field is wrong, it should be set to 6002 as the REFER is asked to 6002.

I can be totally wrong of course, and I apologize if it is the case.

Thanks,
By: dsandras (dsandras) 2004-09-28 07:01:05

That's not related, but why are you forcing the transferee to send a "BYE" to the transferer?

Following the SIP RFC, the transferer should send a BYE to the transferee once this one has sent a "202 ACCEPTED".

With my GrandStream it results in 2 crossed "BYE" being sent, one resulting in :
"SIP/2.0 481 no such call
Via: SIP/2.0/UDP 172.17.100.111:5060;branch=z9hG4bK18b8a55f
From: "Damien GS Droite" <sip:6002@172.17.100.111>;tag=as37ec598c
To: <sip:6003@172.17.100.62>;tag=9f59f2dada161387
Call-ID: 0b287b6219be000d2abfe3a36a426db7@172.17.100.111
CSeq: 104 BYE
User-Agent: Grandstream BT100 1.0.5.10
Content-Length: 0"

That's the result of the request from the transferee to the transferer.
By: Mark Spencer (markster) 2004-09-29 10:23:36

If you use the "f" option to the dial command it will use the callerid of the outgoing party if the call was incoming, thus making it the same way for both.
By: dsandras (dsandras) 2004-09-30 04:40:49

Actually I would like the reverse behavior than the 'f' one even though the 'f' one is acceptable.

However, it has no effect here :
   -- Executing Dial("SIP/6002-542f", "SIP/6001|70|rf") in new stack

The parameter is there, but the callerid is still different following the person who is transfering has been called or has called the transferee.

I'm watching at the code, the reason is that 'f' only has an effect in call forwarding, I'm talking about call transfer here.

edited on: 09-30-04 09:08
By: dsandras (dsandras) 2004-09-30 10:15:14

OK, with the following patch, if users use 'f' in the Dial command :
- any forwarded call appears as coming from the user doing the forward
- any transferred call appears as coming from the person being transferred

I don't know if it sounds logical to you, but here is the patch anyway.
By: dsandras (dsandras) 2004-10-01 02:41:45

OK, I found it illogical to display the caller id of the person forwarding the call for call forwarding and the caller id of the person being transfered for call transfer.

So I added a new option 'F' to the Dial command, that option doesn't modify the current Forwarding behavior, but it ensures that the callerid seen by somebody receiving a call transfer, is the one from the person being transferred.
By: zamsler (zamsler) 2004-10-04 23:29:55

I understand what is trying to be done here. You are talking about the difference of a straight transfer and an attended transfer. If a call is fowarded to me, I want to know who is calling not who should have answered the call to start with. Also If you want the third party to see the caller id of the second party doing the transfer, then they should be doing a warm transfer?
By: dsandras (dsandras) 2004-10-05 02:10:50

I don't know what you mean by a warm transfer, but that is more or less correct.

Let's take an example again :
A calls B, B is doing a blind transfert of A to C, I want C to see A as caller ID.
B calls A, B is doing a blind transfert of A to C, I want C to see A as caller ID.

That's what my patch permits to do, it adds an option to the dial command for that.

Currently, C is seeing the caller id of the person of B or A, following B who is doing the transfert has been called by A or has called A, it seems wrong to me :)
By: zamsler (zamsler) 2004-10-05 07:33:17

OK. Example. I use sipura devices as my ATA.

EX 1
A Calls B
If I do a # Transfer(Blind Transfer), C Would see the callerid of A.

EX 2
A Calls B
If I do FLASH-Dial C-FLASH(Warm Transfer) C Would see the callerid of B.

IMO:
Asterisk should represent a PBX System. What I have described above is how a PBX is designed to work. If I remember correctly provisions have been / are being added to * to do a warm transfer.

I thank you for contrubiting to the developement of asterisk. Having patched available to suit everyones needs is what makes this project awesome!!
By: dsandras (dsandras) 2004-10-05 07:40:46

Let's take your example :
EX 1
A Calls B
If A does a # Transfer(Blind Transfer), C Would see the callerid of A.

EX 2
B Calls A
If A does a # Transfer(Blind Transfer), C Would see the callerid of A.

Without the patch, C sees the callerid of A in EX1, and the callerid of B in EX2 (or the reverse, I don't remember).

No Warm transfer involved, only blind. But without the patch, the callerid is not always the one of the person being transfered, sometimes, it is the callerid of the person doing the blind transfer. The patch fixes that. I hope it will be applied :)
By: rlorentz (rlorentz) 2004-10-11 16:22:07

I agree with the logic of sending the number of the transfered caller/callee, but this could also have implications on external transfer(to PSTN). It is important to send the correct callerid for billing purposes.
External caller (Cell 1) calls Sip A (internal)-
sip A transfers External caller(cell 1) with # or transfer button on Eyebeam to external number Cell 2 on PSTN. The number sent to PRI is cell 1's number, the Telco does not like this number and replaces it with main number on PRI. We would like the number of the transferer(sip A) to be sent to PRI. This way the billing is done correct.
Is this related, or are there any differences between sip only transfer and sip-pstn?

edited on: 10-11-04 16:25
By: dsandras (dsandras) 2004-10-13 03:11:55

You are absolutely right about this, it will have the behavior you describe.

However :
- you already had that behavior without the patch following you are calling or called by the transferee
- You can use the parameter or not in the Dial application following the case.
By: twisted (twisted) 2004-10-27 17:08:09

Wow.  Holy confusion batman.  

Regardless, what's the status here?
By: twisted (twisted) 2004-11-14 21:03:42.000-0600

Apparently, there is still no interest here.  You may re-open if this is still an issue and actually wish to respond.
By: dsandras (dsandras) 2004-11-15 02:35:27.000-0600

Why is the bug closed?

Has the patch been applied to CVS?

Thanks,

PS: sorry for reopening, but that was the only way to add this bugnote.
By: Russell Bryant (russell) 2004-11-15 09:00:04.000-0600

There was a request for updates over two weeks before this bug was closed.  You must respond in a timely manner to keep bugs from being closed due to lack of interest.

That's just our job.
By: dsandras (dsandras) 2004-11-15 09:06:54.000-0600

I found a problem reported by our users, I provided a patch.

Then a few weeks later, you are asking for an update. What update do you want me to provide?

Another bug report where I was using strcmp instead of ast_strlen was also closed because I didn't provide an updated patch. I can understand this, but I can not understand why this one was closed.
By: Brian West (bkw918) 2004-11-29 23:59:48.000-0600

update update... get your fresh update.

bkw
By: Olle Johansson (oej) 2004-12-13 01:51:04.000-0600

Anyone interested in this patch or is it time to close this?

--housekeeping
By: dsandras (dsandras) 2004-12-13 02:20:20.000-0600

The question is not to know if it has to be closed or not. The question is to know if you will apply it to CVS. So my question is : "will you apply that patch to CVS?".

If you won't, then close it, and I'll keep that patch for myself.
By: Olle Johansson (oej) 2004-12-27 15:59:54.000-0600

markster: I guess this patch hangs on your shoulders... 8-)
By: Mark Spencer (markster) 2005-01-06 21:01:28.000-0600

This patch places the callerid of the outbound channel in the callerid of the inbound channel.  I can't see that as logical, and unfortunately I still don't understand what the problem is within the context of the existing options.
By: dsandras (dsandras) 2005-01-07 02:20:43.000-0600

I'll explain again :
If Mark calls Damien, and Damien transfers (blind transfer) Mark to Klaus-Peter, Klaus-Peter sees a call coming from Mark, which is correct in my opinion.

If Damien calls Mark, and Damien transfers (blind transfer) Mark to Klaus-Peter, Klaus-Peter sees a call coming from Damien, which is incorrect.

There is an incoherence in the behavior. The patch fixes this, you always see the original caller as source of the call when there is a blind transfer. If you don't like it, then close the bug. I'll keep it around here for our users.
By: Mark Spencer (markster) 2005-01-16 01:55:32.000-0600

ding ding ding

okay, I finally understand what you're trying to get at.

Should be fixed in CVS, no 'F' option needed.  Feel free to reopen if this isn't what you were looking for.
By: Russell Bryant (russell) 2005-01-17 16:49:45.000-0600

fixed in 1.0
By: Digium Subversion (svnbot) 2008-01-15 15:22:01.000-0600

Repository: asterisk
Revision: 4810

U   trunk/apps/app_dial.c

------------------------------------------------------------------------
r4810 | markster | 2008-01-15 15:21:58 -0600 (Tue, 15 Jan 2008) | 2 lines

Give outbound channels callerid of their extension *after* calling (bug ASTERISK-2451)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=4810
By: Digium Subversion (svnbot) 2008-01-15 15:22:14.000-0600

Repository: asterisk
Revision: 4826

U   branches/v1-0/apps/app_dial.c

------------------------------------------------------------------------
r4826 | russell | 2008-01-15 15:22:14 -0600 (Tue, 15 Jan 2008) | 2 lines

give outbound channels callerid of their extension after calling (bug ASTERISK-2451)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=4826