[Home]

Summary:ASTERISK-07378: Problem with CALLERID handling in version > 1.2.0
Reporter:boesl (boesl)Labels:
Date Opened:2006-07-21 07:48:25Date Closed:2011-06-07 14:02:42
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Transfers
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) res_features-blindtransferer-feature.diff
Description:Hi I'm running an asterisk-1.2.10 on a 2.6.16-gentoo-r9 system.

I think the CALLERID handling in the new version 1.2.0 needs some work. There are good points for the new way but also for the old way.

Let me give you an example.

The senario:
Two SIP peers are connected. Now the caller phone wants to make a blind transfer to another, a 3rd SIP peer. If you do so with the old way, the orginal CALLERID, from peer one is beeing set and send to the 3rd peer as CALLERID, but thats not what you whant. The CALLERID from the 2rd peer, that one that is acually transfered to the 3rd peer, should be set and send as CALLERID.
If your working with the new version the CALLERID from peer one is not set for the channel to peer two. So if you make a blind transfer the 3rd peer sees the CALLERID from peer two.

At this point with version 1.2.10 everthing looks nice, but not in this scenario:

Now you're trying to work with the the extension states. For ex. any hint subscription for BLF with SIP phones.
And here it is, the problem with the new way.
If there is an extension state change, for ex. a new call is made to that extension, asterisk sends a notify to the peer with the subscription and the information in this message contains the extensions that have changed and the CALLERID information for the new channel.
So what you see is, that with the new version 1.2.0 the extension that changed and the CALLERID information are the same! Because the CALLERID is not set to the calling peers CALLERID, but to the CALLERID from the peer that has changed and is observed.
This is not what you want; I think what you want is to see who is calling the observed peer.

With the old version this problem didn't exist, because the callerid is set to the calling peer's CALLERID.

This problem needs to be fixed, because either way, one function (transfer or extension state changes) don't work correctly.
I tried to make a workaround in the dialplan, but there isn't enough information in the channels about the caller or the callee and there is no way to intercept in the notify mechanism. Something like CALLERID and CALLEEID maybe the way to fix this.  

regards
Boesl
Comments:By: Joshua C. Colp (jcolp) 2006-07-26 10:08:13

Scenario #1:

Phone 1 calls Phone 2
Phone 2 blind transfers Phone 1 to extension 145
Extension 145 sees callerid of Phone 1.

We know this is the way it works, it's been tested a lot in the past day or two (by myself and others). Is this the way that it isn't working for you or do you want to see it work differently?

Scenario #2:

I wasn't aware that the device state stuff ever sent the callerid of the calling party to the peer. As far as I know, it's only supposed to communicate the status (ie: in use, ringing, etc).

What previous version of Asterisk were you using that things worked like you say they did?
By: Serge Vecher (serge-v) 2006-08-08 13:35:39

boesl: need your response to joshnet.
By: boesl (boesl) 2006-08-15 02:52:12

Hi,

I'm sorry for the late response but I was on vacation.

In Scenario 1 with the blind transfer and the current version of asterisk, it works like you discribed.
But if you put an 'o' parameter in the Dial command you will see the difference. And that 'o' is also the way I was testing the old and new behavior, I was not using any other version of asterik.

In Secnario 2 you'r right there is no callerid send, but with an snom specific patch there is.
And the callerid send to the phone is taken from the channel thats state has just changed. At this ponit the old and the new way make the diffrence.
By: k-egg (k-egg) 2006-08-15 04:41:55

i personally didnt get the point here at all... but i did a little patch to res_features which provides some information, when your're blind transfered.

maybe it helps you, Boesel.

you can exchange the second BLINDTRANSFERER to BLINDTRANFEREE, and may get what you want ;)
By: Joshua C. Colp (jcolp) 2006-08-15 09:57:30

I'm sort of confused as well, can you explain any better what the problem is? If it's just that the Snom patch doesn't work because of this, then I would take it up with who produced that. Keeping our source tree working with out of tree patches is not something we can do.
By: boesl (boesl) 2006-08-17 09:19:54

Hi

first of all you may be right and this isn't really a bug or at least non of your concern. But I think the callerid processing is not quite right in the way it is done.

I'm trying to make my point clear for you.
To avoid confusion, I'm only considering the "new" or the "actuall" callerid processing in asterisk 1.2.x.

There are Alice with callerid 'Alice <100>', Bob with 'Bob <200>' and there is John with 'John <300>'.

Now Alice is calling Bob:

Alice ----------------------> Asterisk ------------------------->Bob
       chan_1: Alice <100>
                                                       chan_2: <200>

So the chan_1 has Alice callerid and the chan_2 has Bob's (the callerid(num) at least). So if Alice makes an blind transfer to John, we get the following:

John <---------------------- Asterisk -------------------------> Bob
       chan_1: <300>
                                                       chan_2: Bob <200>

and on Johns phone you can see that Bob <200> is calling and if you which you can change the callerid for that call in the dial plan, to show something like 'transfered call'.

But now I see the problem. If someone is watching the state from Bob and e.g. Alice is calling Bob -> Asterisk informs the whatcher, but the information  
for that change contains only the callerid from Bob, so the watcher sees something like 'Bob is calling Bob'.

Alice ----------------------> Asterisk ------------------------->Bob
       Chan_1: Alice <100>      
                                                       Chan_2: <200>
                                           |
                                only chan_2 info: <200>
                                           |
                                           V
                                        watcher thinks <200> is calling <200>

I know that there is no such information in the org. device state stuff about caller or callee, but the patchs adds such information. And if you use phones with support for that, it is a really nice thing.
But the patch isn't the place to change that, because the information about the caller (chan_1 information above) is gone allready in the device state section.
 
So I thing it would be nice if there is a change in the callerid processing, so that the caller- and the callee-id is saved in each channel.

Alice ----------------------> Asterisk ------------------------->Bob
       chan_1 information:    
       callerID: Alice <100>
       calleeID: Bob <200>
                                                       chan_2 information:
                                                       callerID: Alice <100>
                                                       calleeID: Bob <200>

I hope you can understand my point.

Regards
Boesl


By: Joshua C. Colp (jcolp) 2006-09-06 13:59:37

I understand now... think isn't an actual bug, you just think it should work differently. That's fine - take it up on the asterisk-dev mailing list and maybe it can be incorporated next development cycle.