VoIP Mailing List Archives

[viljoens at verishare....]

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


--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users