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