Try Polycom? =p With snom we always have better luck with older FW. Like 7.x On Wed, Sep 22, 2010 at 10:42 AM, Helmut Kuper <helmut.kuper@ewetel.de> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hi,

any hint to this?

regards helmut

Am 21.09.2010 11:18, schrieb Helmut Kuper:

...

Hello,

today I found a problem with Snom transfer function.

What I do is this:

1. Snom A calls Snom B 2. Snom B icks up and putting Snom A on hold 3. Snom A hears hold music 4. Snom B calls Snom C 5. Snom C picks up 6. Pressing Transfer on Snom B 7. Pressing Transfer on Snom B again :) 8. Connection to Snom B is terminated by FS 9. Snom A hears nothing 10. Snom C hears hold music

I found that Snom B sends an HOLD INVITE to Snom C when transfer is pressed for the 2nd time on Snom B.

I opened a Bug at Snom, but I'm not sure whether this is also a FS issue ...

If you need some pcap traces, I can send you all I have about this.

I use Snom FW 8.4.18 and .20 and FS GIT head of 2010-08-26 (Unfortunately that revision has a .version file in which only contains "git-")

regards Helmut

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32)

iD8DBQFMmiPl4tZeNddg3dwRAhSrAJ4p1vr+WYMSviuGNjg6zUGJNnxcpwCgjpvU VnNfSsNzuhb4MlqOxd0wpFo= =H8u6 -----END PGP SIGNATURE-----

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900

On Sep 24, 2010, at 8:24 AM, Helmut Kuper wrote:

Often a good idea, but this doesn't helps solving the problem.

It is quite clear, that snom has a bug here, but it seems strange to me that FS is allowing transferring phones to put a "call in transfer" to hold AFTER call transfer has started inside of FS.

No its not our job to make sure the phone does the transfer correctly. It can totally screw up the transfer and cause FreeSWITCH to do strange things if it does the refer incorrectly. Just like any other phone that would happen to do it wrong you'll have unexpected results.

regards Helmut