Hi all

I’ve got a setup where I use a Sangoma PRI card driven via Sangoma WanPipe to connect to a legacy Samsung PABX (I’m not sure which model) form Asterisk
1.8.11.0.

The reason is the customer has a large installed base of Samsung phones physically connected to it and on each users desk. They did not want to spring for a complete replace of all their Samsung phones with generic, and dump their existing Samsung PABX (worth several hundred thousand in local currency) for a 100% SIP phone + Asterisk setup.

They do want the calls recorded and accessed in a custom system, ergo Asterisk – raison d’etre for the setup – it records and the 3rd party system interfaces to it via the AMI to playback and record.

The Asterisk stands between the Samsung and the telco’s SIP trunk, and presents PRI NET to the Samsung, so it “thinks” it is directly connected to the telco PRI trunk.

The Asterisk in turn connects to the telco –SIP– trunk. (E. g. we protocol translate on Asterisk level – it speaks PRI to the Samsung and SIP to the telco)

Everything works fine, EXCEPT when users do transfers. If they “Asterisk transfer” (#number) on the Samsung phones, it works fine, but ONLY if the target Samsung phone is not busy with a conversation.

If the target Samsung phone IS busy with a conversation, that conversation on the Samsung is cut off, and the person “outside” wanting to talk to the consultant is also cut off – MOH ends and Asterisk emits standard CLI info and runs the H extension on the call, as it should for a normal hangup.

If they “Samsung transfer” (e. g. use the physical transfer button on the Samsung handset) it works fine – if the user is busy, it rings back, if not, the call goes through.

The reason they have to “Asterisk transfer” is that Asterisk can keep track of which extension is actually linked to a call – this is vital for the 3rd party system we have interrogating asterisk for extensions status for business logic purposes over AMI.

If they “Samsung transfer” asterisk is oblivious of the “new” extension on which the call is running, and therefore business logic breaks – it only has that 1000 (reception) is busy, and has no inlking of the fact that, in the Samsung, 1000 has transferred to 1023 (for example) and business logic should run on 1023, NOT 1000…

Can anybody offer any comments?

Thanks

Stefan