Summary:ASTERISK-03280: [Patch] Loss of callerid when calling from chan_vpb.c
Reporter:tcord (tcord)Labels:
Date Opened:2005-01-15 04:02:44.000-0600Date Closed:2005-01-17 21:43:16.000-0600
Versions:Frequency of
Environment:Attachments:( 0) patch
( 1) patch
( 2) patch
( 3) patch
( 4) patch
Description:Callerid is not maintained when calling from vpb channels


patch to fix problem included
Comments:By: nick (nick) 2005-01-15 10:06:28.000-0600

Do you have a disclaimer?

By: Mark Spencer (markster) 2005-01-15 12:24:57.000-0600

We'll need the disclaimer as well as a patch for CVS head, thanks!

By: tcord (tcord) 2005-01-16 01:48:50.000-0600

Disclaimer has been emailed as PDF to malcolmd@digium.com, don't have a fax near me right now (snail mail will take a month from here)

By: Mark Spencer (markster) 2005-01-16 01:56:07.000-0600

Perfect, do you have a patch for CVS head, too?

By: tcord (tcord) 2005-01-16 05:23:26.000-0600

patch for CVS head attached

By: tcord (tcord) 2005-01-16 06:25:07.000-0600

woops - better hold that patch it is for v1.0.12, will need some changes for current CVS

By: tcord (tcord) 2005-01-16 08:14:00.000-0600

Final patch gives the ability to represent callerid as "String"<number> consistent with other drivers

By: VoiceTronix (benkramer) 2005-01-16 19:06:08.000-0600

Have you tested that this was an issue with the CVS head version of Asterisk before producing the patch ? The reason I ask this is that the variable me->callerid is not guaranteed to have anything in it, as it is no longer used to store the CID, but may have temporary information in it.

By: tcord (tcord) 2005-01-16 20:43:30.000-0600

me->callerid is obtained from struct vpb_pvt and in this instance comed from the config file vpb.conf lines callerid="...", if it contains nothing the code as presented still works, it just inserts "unknowm"

Do you mean I should perform a preliminary check as I have presented in the last patch (which does nothing?) so ignore it please.

This patch is purely to fix problems in outbound calls from chan_vpb devices.

The "callerid" lines from vpb.conf go nowhere unless they are copied into the ast_channel structure somewhere during a call, do you have any better suggestions where this should be done or have I missed the point of your comment?

The patch as represented 01-16-05 08:09 has been tested and fixes the issue outlined above

By: VoiceTronix (benkramer) 2005-01-16 21:10:40.000-0600

There is actually a confusion as to the current purpose and original purpose of the "callerid" config option in vpb.conf. I will look into clarifying this soon.
So you patch provides which one:
A) the "Station identification" when calling from a vpb station port to another resource ?
B) forwards the "caller id" that was collected on when the call was presented to the system ?
This will help me to integrate your patch and clarify the usage of the "callerid" config option.

By: tcord (tcord) 2005-01-16 21:57:35.000-0600

You are correct with (A), there was no facility in chan_vpb to present a callerid when calling from a vpb channel to another resource, I haven't tested the (B) option yet but will get onto this one soon.

I will only be able to test the Australian stuff, but a quick look through the code indicates this is all in place anyway
is what you put on FXO lines
on FXS lines

The callerid config option as far as I can see is not documented, but if this info is defined prior to channel=N in the config file it works with this patch.

By: VoiceTronix (benkramer) 2005-01-16 22:23:33.000-0600

can you contact me directly at ben at voicetronix.com.au

By: VoiceTronix (benkramer) 2005-01-17 21:27:39.000-0600

I have patched this and cleaned up the caller ID stuff a bit. It should also forward caller ID information from a trunk if the trunk is not answered till after the CID collection has completed (ie ~ do a wait(3) before Dial()ing).
Tested with OpenLine4 and Grandstream BudgeTone100.

By: VoiceTronix (benkramer) 2005-01-17 21:29:20.000-0600

See last comment.