I have 2 IVR scenarios, one is outbound and the other is
inbound. Those scenarios are the opposite from each other. The purpose of
having this setup is to test the IVR scenario. So, outbound IVR originate a
call to a DNIS. This DNIS is linked to the same T1 that my outbound call. When
received, the inbound call should link with my inbound IVR. But the events are
not the same from an outbound to inbound and a normal inbound.
Example of event from the outbound to inbound:
Content-Length:
1491
Content-Type:
text/event-plain
Channel-State:
CS_EXECUTE
Channel-State-Number:
4
Channel-Name:
OpenZAP/1%3A21/5143150566
Unique-ID:
7d846604-0139-4b23-b538-7a71349a2416
Call-Direction:
inbound
Answer-State:
ringing
Channel-Read-Codec-Name:
PCMU
Channel-Read-Codec-Rate:
8000
Channel-Write-Codec-Name:
PCMU
Channel-Write-Codec-Rate:
8000
Caller-Username:
OpenZAP
Caller-Dialplan:
XML
Caller-Caller-ID-Name:
openzap
Caller-Caller-ID-Number:
1
Caller-Destination-Number:
5143150566
Caller-Unique-ID:
7d846604-0139-4b23-b538-7a71349a2416
Caller-Source:
mod_openzap
Caller-Context:
default
Caller-Channel-Name:
OpenZAP/1%3A21/5143150566
Caller-Profile-Index:
1
Caller-Channel-Created-Time:
1213871785724672
Caller-Channel-Answered-Time:
0
Caller-Channel-Hangup-Time:
0
Caller-Channel-Transfer-Time:
0
Caller-Screen-Bit:
yes
Caller-Privacy-Hide-Name:
no
Caller-Privacy-Hide-Number:
no
variable_read_codec:
PCMU
variable_read_rate:
8000
variable_write_codec:
PCMU
variable_write_rate:
8000
variable_channel_name:
OpenZAP/1%3A21/5143150566
Application:
answer
Application-Data:
_undef_
Event-Name:
CHANNEL_EXECUTE
Core-UUID:
f240a0e0-1720-42c1-b775-c2596eabadb9
FreeSWITCH-Hostname:
tyan-test.ip5.local
FreeSWITCH-IPv4:
192.168.100.124
FreeSWITCH-IPv6:
127.0.0.1
Event-Date-Local:
2008-06-19%2006%3A36%3A25
Event-Date-GMT:
Thu,%2019%20Jun%202008%2010%3A36%3A25%20GMT
Event-Date-timestamp:
1213871785724672
Event-Calling-File:
switch_core_session.c
Event-Calling-Function:
switch_core_session_exec
Event-Calling-Line-Number:
1042
Example of event from a normal inbound:
Content-Length:
1532
Content-Type:
text/event-plain
Channel-State:
CS_EXECUTE
Channel-State-Number:
4
Channel-Name:
OpenZAP/1%3A7/5143150566
Unique-ID: 3b4ce8bc-324a-4f5d-9460-877f79b541de
Call-Direction:
inbound
Answer-State:
ringing
Channel-Read-Codec-Name:
PCMU
Channel-Read-Codec-Rate:
8000
Channel-Write-Codec-Name:
PCMU
Channel-Write-Codec-Rate:
8000
Caller-Username:
OpenZAP
Caller-Dialplan:
XML
Caller-Caller-ID-Name:
%205147884293
Caller-Caller-ID-Number:
%205147884293
Caller-ANI: %205147884293
Caller-Destination-Number: 5143150566
Caller-Unique-ID: 3b4ce8bc-324a-4f5d-9460-877f79b541de
Caller-Source:
mod_openzap
Caller-Context:
default
Caller-Channel-Name:
OpenZAP/1%3A7/5143150566
Caller-Profile-Index:
1
Caller-Channel-Created-Time:
1213871984059731
Caller-Channel-Answered-Time:
0
Caller-Channel-Hangup-Time:
0
Caller-Channel-Transfer-Time:
0
Caller-Screen-Bit:
yes
Caller-Privacy-Hide-Name:
no
Caller-Privacy-Hide-Number:
no
variable_read_codec:
PCMU
variable_read_rate:
8000
variable_write_codec:
PCMU
variable_write_rate:
8000
variable_channel_name:
OpenZAP/1%3A7/5143150566
Application:
answer
Application-Data:
_undef_
Event-Name:
CHANNEL_EXECUTE
Core-UUID:
f240a0e0-1720-42c1-b775-c2596eabadb9
FreeSWITCH-Hostname:
tyan-test.ip5.local
FreeSWITCH-IPv4:
192.168.100.124
FreeSWITCH-IPv6:
127.0.0.1
Event-Date-Local:
2008-06-19%2006%3A39%3A44
Event-Date-GMT:
Thu,%2019%20Jun%202008%2010%3A39%3A44%20GMT
Event-Date-timestamp:
1213871984059731
Event-Calling-File:
switch_core_session.c
Event-Calling-Function:
switch_core_session_exec
Event-Calling-Line-Number:
1042
This event is just an example, because it’s the same
for problem for the entire event related to connect of the inbound.
In the outbound to inbound call, we have this information:
Caller-Caller-ID-Name:
openzap
Caller-Caller-ID-Number:
1
Caller-Destination-Number: 5143150566
In the normal inbound call, we have this information:
Caller-Caller-ID-Name:
%205147884293
Caller-Caller-ID-Number:
%205147884293
Caller-ANI:
%205147884293
Caller-Destination-Number:
5143150566
Why don’t we get the same result in the outbound to
inbound call than the normal inbound call? In an outbound to inbound call,
freeswitch don’t use the information contain in the variables of the
originate command to set Caller_ID_Name, Caller_ID_Number and Caller_ANI.
Instead, freeswitch fill those variables with what is look like default value
and Caller_ANI is not even included in the event.
Thanks.
SL