Contact and number association on outbout calls

[trustmaster]

Am I doing something wrong or on outbound calls the phone number in question is the number of the company employee who makes the call?

My customers are not quite happy with it, what they normally want is the call contact to be their customer being called in such case because they already see who makes the call in assigned user column. I've made a patch to asteriskLogger.php which changes it for outbound calls but I had to add "recipientID" field to asterisk_log table, so it might need quite some polishing before sharing.

Does it make sense to anybody?

[blak3r]

Something is wrong. One of your regex's needs tweaking.

Take a look at your logs. It's probably not detecting the local extension properly and therefore may be thinking its an inbound call.

I have some logs on the wiki pages (separate page from user manual) you can compare them to.

~blake

On Sep 22, 2012, at 12:48 AM, Vladimir Sibirov notifications@github.com wrote:

Am I doing something wrong or on outbound calls the phone number in question is the number of the company employee who makes the call?

My customers are not quite happy with it, what they normally want is the call contact to be their customer being called in such case because they already see who makes the call in assigned user column. I've made a patch to asteriskLogger.php which changes it for outbound calls but I had to add "recipientID" field to asterisk_log table, so it might need quite some polishing before sharing.

Does it make sense to anybody?

— Reply to this email directly or view it on GitHub.

[trustmaster]

Nope, it clearly logs it as Outbound and the calls title is "Outbound Call".

[blak3r]

Well... I forget which case is the default. Inbound or outbound so that doesn't necessarily mean its not something related to that.

Take a peak at the logs I sent and see what it says for the source and channel

~blake

On Sep 22, 2012, at 1:24 AM, Vladimir Sibirov notifications@github.com wrote:

Nope, it clearly logs it as Outbound and the calls title is "Outbound Call".

— Reply to this email directly or view it on GitHub.

[blak3r]

Only other suggestion would be to revert back to the version of asterisk logger that's on sugar forge and see whether it works then. If I recall I made some commits to help someone who was trying to get ami 1.0 working. Perhaps that screwed something up.

Doubtful but certainly possible.

~blake

On Sep 22, 2012, at 1:24 AM, Vladimir Sibirov notifications@github.com wrote:

Nope, it clearly logs it as Outbound and the calls title is "Outbound Call".

— Reply to this email directly or view it on GitHub.

[trustmaster]

In the asterisk configuration I'm dealing with on outbound calls the only event field containing recipient's phone number is Dialstring in format: trunk_name/123456789. But if you look at asteriskLogger.php in your master branch, it uses $rawData['callerID'] (CallerIDNum) to detect contact/account.

[blak3r]

Doesn't sound right...

~blake

On Sep 22, 2012, at 1:39 AM, Vladimir Sibirov notifications@github.com wrote:

In the asterisk configuration I'm dealing with on outbound calls the only event field containing recipient's phone number is Dialstring in format: trunk_name/123456789. But if you look at asteriskLogger.php in your master branch, it uses $rawData'callerID' to detect contact/account.

— Reply to this email directly or view it on GitHub.

[Laureano]

Maybe we could find the source of the issue if we compare the expected behaviour. I'm running Asterisk 1.4.25.1 in a production system, connected with SugarCRM by yaai 2.4 (the latest release from SugarForge). Whenever we make an outgoing call, there are two Newcallerid events generated from Asterisk. The first one is related to the extension making the outgoing call. The second one is generated by the Dial application and its related to the outgoing channel used to connect the call. On my system, the first CallerID identified by the process is the one that is used as outbound CallerID by our trunk (the number that our customers see when they receive a call from us). After the call being identified as outbound, there is this second Newcallerid event, which is related to the outbound number and updates the CallerID that will be used by asteriskLogger.php to lookup the customer number. Actually, the right CallerID for an outbound call could be also fetched from the Link (or Bridge) event; which could be a workaround if no Newcallerid events are being generated.

My deduction is that the dialplan of @trustmaster could be updating the CallerID for the outbound channel in order to work (or maybe due to misconfiguration) and thus are confusing asteriskLogger.php about the CallerID that should be used to identify the customer. My suggestion would be to check if Asterisk is generating the Newcallerid events for the outbound channel and if the information included in this events isn't updated after by some other event.

Below is a snippet of the log generated from my production system. All sensitive information has been changed, but here are some hints:

• 2222 is the extension calling the customer
• Laureano is the name of the extension calling the customer
• The CallerID of out trunk is 0017681112222
• The number of the customer is 0016502530000

[2012-09-22 13:19:39] ! --- Event ----------------------------------------------------------- ! Event --> Newcallerid ! Privilege --> call,all ! Timestamp --> 1348330829.983534 ! Channel --> SIP/2222-b7300480 ! CallerID --> 0017681112222 ! CallerIDName --> Laureano ! Uniqueid --> 1348330829.25 ! CID-CallingPres --> 0 (Presentation Allowed, Not Screened) ! --------------------------------------------------------------------- * {e['UniqueId']} CallerID Changed to: 0017681112222 [2012-09-22 13:19:39] ! --- Event ----------------------------------------------------------- ! Event --> Dial ! Privilege --> call,all ! Timestamp --> 1348330830.396432 ! Source --> SIP/2222-b7300480 ! Destination --> SIP/sipTrunk-08f17690 ! CallerID --> 0017681112222 ! CallerIDName --> Laureano ! SrcUniqueID --> 1348330829.25 ! DestUniqueID --> 1348330830.26 ! --------------------------------------------------------------------- ! Dial Event src=SIP/2222-b7300480 dest=SIP/sipTrunk-08f17690 ! Successfully created CALL record with id=c1cd3680-6f63-06f7-cf48-505de5d8f0ad

• CallerID is: 0017681112222 OUTBOUND state detected... /^(sip\/(remote)(222[0-9])-)/i is astMatchInternal eChannel= eDestination=SIP/sipTrunk-08f17690 [2012-09-22 13:19:41] ! --- Event ----------------------------------------------------------- ! Event --> Newcallerid ! Privilege --> call,all ! Timestamp --> 1348330830.399774 ! Channel --> SIP/sipTrunk-08f17690 ! CallerID --> 0016502530000 ! CallerIDName --> ! Uniqueid --> 1348330830.26 ! CID-CallingPres --> 0 (Presentation Allowed, Not Screened) ! --------------------------------------------------------------------- \ {e['UniqueId']} CallerID Changed to: 0016502530000

[2012-09-22 13:19:41] ! --- Event ----------------------------------------------------------- ! Event --> Link ! Privilege --> call,all ! Timestamp --> 1348330831.832379 ! Channel1 --> SIP/2222-b7300480 ! Channel2 --> SIP/sipTrunk-08f17690 ! Uniqueid1 --> 1348330829.25 ! Uniqueid2 --> 1348330830.26 ! CallerID1 --> 0017861112222 ! CallerID2 --> 0016502530000 ! ---------------------------------------------------------------------

TL;DR Using the CallerID makes sense to me as long as a Newcallerid event gets generated for the outbound channel by the Dial application, which should be the expected behaviour.

[trustmaster]

Thanks for explaining, @Laureano. Now I see how it works and why CallerID in theory should contain the right number. I'll check the logs to see what's going wrong on my end.

[blak3r]

Yaai was developed against asterisk 1.6 and more importantly AMI v1.1

Im pretty sure v1.4 uses ami 1.0 which Will require some modifications to asterisk logger.

Getting my threads crossed up. Is everything working fine for you on 1.4, @laureano?

[trustmaster]

Forgot to mention I'm using asterisk 1.8.

[Laureano]

@blak3r, I made some changes to asteriskLogger in order to work with Asterisk 1.4 due to the AMI version. These changes were pretty straight forward, at least in my case: changing some event names and some parameters. I'm planning to submit these changes soon as a branch, at least to provide some level of support to AMI 1.0, but I've some others changes in the same code related to other features / fixes that I should take apart before commiting.

[blak3r]

Fantastic. Yeah didn't seem too difficult to get working. Glad you got it. That'll be a nice edition to the codebase. There's another guy on the form that's been working on it too if ya search issues if you guys wanna collaborate at all.

~blake

On Sep 22, 2012, at 4:11 PM, Tomás Laureano Peralta Tormeynotifications@github.com wrote:

@blak3r, I made some changes to asteriskLogger in order to work with Asterisk 1.4 due to the AMI version. These changes were pretty straight forward, at least in my case: changing some event names and some parameters. I'm planning to submit these changes soon as a branch, at least to provide some level of support to AMI 1.0, but I've some others changes in the same code related to other features / fixes that I should take apart before commiting.

— Reply to this email directly or view it on GitHub.

[Laureano]

Yes, I'm trying to catch up with the current efforts listed on the issues to collaborate. I guess that on the next few days I'll be up to date.

[Laureano]

@trustmaster I just double checked the code for 1.8, it should be generating the Newcallerid event on Dial too.

[trustmaster]

Found the cause. Here is what happens: it generates all (3) Newcallerid events before the Dial Begin event. So by the moment the call record is created all Newcallerid events have already passed and it won't change CallerID to the recipient's number. This is weird because on previous Asterisk 1.8 instances I dealt with it didn't act this way and Newcallerid events followed Dial Begin. But on this one it is reverse!

[trustmaster]

Regarding another part of my original question: why it doesn't associate a contact. I found that this case is already known and commented in the code: when there are multiple duplicate accounts (which are actually the same but there is OR and no DISTINCT in the query) the contact has no account associated, then it doesn't associate it. OK, we solve it by enforcing our customers to associate all contacts with accounts.

Another thing I've noticed: in findSugarObjectByPhoneNumber() if it finds an Account associated to a Contact it returns just the Account alone which is then linked to the Call via setRelationshipBetweenCallAndBean() in the main loop, but the Contact itself is discarded. This is not very correct and the Contact should be linked via setRelationshipBetweenCallAndBean() too.

[blak3r]

Please see this blurb in the User manual:

How are multiple matching contacts handled?

When the user doesn't intervene (by selecting from a list of matching contacts or manually relating), the first matching contact found in the database is picked. This happens when the hangup action occurs.

Desired behavior:

• If phone number matches an account phone number, log it to account only.
• If it matches multiple contacts and each of them is from the same account, then log it to account only.
• If it matches multiple contacts and the account name differs... We don't really have a good person to log this to... this behavior is undefined.

If the user is currently logged into sugar and they have call notification enabled, when there are multiple matching contacts the user can select the contact by clicking on a radio button. Once selected, setContactId ajax call is triggered which updates the contact_id column. As long as this is done before the call is hung up, asteriskLogger will check to see if the user selected the contact before picking one as outlined above.

You may be asking yourself... why is there logic in two places? There is contact matching logic in both callListener and asteriskLogger. Well, asteriskLogger is necessary because that logs calls even when the user isn't logged into sugarcrm at all. CallListener needs logic as that is what displays the screen pops to the user and provides additional features to help user resolve multiple contact matching. As a result, we have similar logic in two places.

To your second point, I suspect you may have multiple matching contacts for the account and thus why it's rindSugarObjectByPhoneNumber is returning an account..

To your first point, If OR or Distinct will improve the query I'm all ears. I'm by no means a SQL expert but I spent a couple hours trying to make it the best I could.

~blake

[trustmaster]

You have slightly misunderstood what I mean. Each Call entry normally has 2 relations: both Account and Contact. Making the choice between them exclusive is a bit strange. I got a call from Mr. John Doe / Foobar Inc., but it only associated it with Foobar Inc. and my boss won't know that it was Mr. John Doe who called me.

OR/DISTINCT thing is well commented in the code: the only known way to fix it so far is to replace SOAP call with a direct database query.

[blak3r]

What I was trying to say is it should relate to both mr John doe and the account if that's the case.

But there are two exceptions. If the account has a phone number set on it, then we only relate to that phone number.

-or-

If there are two contacts under the same account and both have the same phone number, we don't have any way Of knowing which contact it was so we just relate to the account.

If yaai is not doing that, then there must be a bug.

~blake

On Sep 24, 2012, at 1:39 AM, Vladimir Sibirov notifications@github.com wrote:

You have slightly misunderstood what I mean. Each Call entry normally has 2 relations: both Account and Contact. Making the choice between them exclusive is a bit strange. I got a call from Mr. John Doe / Foobar Inc., but it only associated it with Foobar Inc. and my boss won't know that it was Mr. John Doe who called me.

OR/DISTINCT thing is well commented in the code: the only known way to fix it so far is to replace SOAP call with a direct database query.

— Reply to this email directly or view it on GitHub.

[trustmaster]

I know about this exception and it is correct. But currently it doesn't relate to the Contact regardless of whether the Account has a phone number or not.

[blak3r]

Maybe having a bug then where you have multiple contacts related to the account. Perhaps one was deleted. I thought it handled that properly but maybe not.

Try creating a new account / contact and seeing if you still have that issue. It definitely relates calls to contacts for me.

On Tue, Sep 25, 2012 at 3:47 AM, Vladimir Sibirov notifications@github.comwrote:

I know about this exception and it is correct. But currently it doesn't relate to the Contact regardless of whether the Account has a phone number or not.

— Reply to this email directly or view it on GitHubhttps://github.com/blak3r/yaai/issues/68#issuecomment-8846108.

[Laureano]

Same here. Calls are related to contact and account when available.

[trustmaster]

Probably misconfiguration on my side or something. I'll close it as nobody else has this issue.

[blak3r]

Make sure it got merged in I think I made the change like 1.5 months ago.

~blake

On Sep 25, 2012, at 1:53 PM, Vladimir Sibirov notifications@github.com wrote:

Probably misconfiguration on my side or something. I'll close it as nobody else has this issue.

— Reply to this email directly or view it on GitHub.