I've come across a problem when using Cisco phones as sip-clients on a Freeswitch system. The problem that arises has to do whit which RFC the Cisco phones are following. Best thing to do at this moment is to point to the Tech-invite website http://www.tech-invite.com/. The examples on that site are more explanatory to the problem than I am ever are able to provide. Ok if you take a look at the link SIP Service Examples there are 19 examples of how RFC 5359 describes how call signalling should flow. If you take a careful look at example 5 (attendant transfer) you will discover that before there is the transfer the station the transfer will go to is put on hold. Bob is transfering to Carol so she is being put on hold by Bob, signals 12 to 14. Now if you take a look at the RFC involved in transfering calls, to be found on the main site link SIP-Topics (to the left) and then following the link Call Transfer (middle window second line in yellow section) you'll find three RFC regarding to transfering calls. In none of these am I able to find this putting on hold as is scribed in RFC 5359 so it seems reasonably to assume that this 'putting on hold' in not mandatory. Here now arises the source of my problem, the Cisco phones are using RFC 5359 when attempting a attendant transfer. When now this signalling is to flow through Freeswitch it puts the station where the transfer is going to on hold as in the prior example is happening to Carol. Freeswitch the connects the MOH stream to this station. Seems a logical thing to do if your assume the putting on hold is not mandatory for the transfer. When now the original station (prior example Bob) is sending the refer thins go bad. Freeswitch is not sending new invites or other signaling to the stations. It is only processing the byes from the station that preforms the transfer (prior example Bob). If I now break the MOH stream on the freeswitch cli all goes well meaning that all invites and other signalling is flowing correctly through Freeswitch. Did anyone out there have the same problem or better yet have a fix for it?. Kind regards, Durk
_______________________________________________ Freeswitch-users mailing list [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
