Try karoo bridge instead. See http://wiki.sipfoundry.org/display/sipXecs/Karoo+Bridge+SBC
On 10/18/2011 11:40 PM, Fulvio Scapin wrote: > Thanks again for your opinions. > I shall dump the SIP traffic to get a better idea of what's actually > happening to the call flow and where the fork is initiated. > To Kumaran, I am planning to upgrade to the latest stable release in a > few weeks, andwhen I do I will certainly test the same situation > again. > > Since I am using the FS version bundled with SipXECS, upgrading FS > might too alter this behaviour. > > Strange how using FS more heavily is such a rare choice, since it's > effectively bundled with SipXECS and it already functions as a core > component. > I chose to employ it as a SBC since sipXbridge is, inevitably, far > less malleable and customisable. In a smallish environment that can be > quite an issue. > > I'll be back with more details and refer to the FS mailing lists if necessary. > > Regards, > Fulvio Scapin > > 2011/10/18 Joegen Baclor<[email protected]>: >> Not a feature but a bug. FS is not suppose to be "mixing" multiple INVITEs >> with replaces to the same dialog. Instead, it should be "replacing" it with >> the latest INVITE that knew about its dialog state via the replaces param. >> Unfortuantely FS acting as SBC is something that is not common. The OP >> mentioning FS in the middle made all the difference. I agree that the OP >> should also bring this up in the FS mailing list. >> >> >> On 10/18/2011 09:34 PM, Tony Graziano wrote: >> >> it sounds as if the FS SBC is bridging the call and creating separate forks, >> and allowing them to be picked up individually instead of making this a >> single stream. >> it has a lot of security implications in doing so, IMO. You might want to >> revisit how your FS b2bua is configured and how the bridge is established. I >> feel reasonably sure there would be a way to keep this from happening, but I >> don't know this would be a good example of how to establish a b2bua >> connection, given the multiple connections to a single stream. Have you >> asked about this on the fs-users list? >> Since this is not a direct configuration by sipx, it's certainly not a bug. >> The question remains is whether it is a feature request! >> >> >> On Tue, Oct 18, 2011 at 9:09 AM, Fulvio Scapin<[email protected]> >> wrote: >>> Hello Kumaran. >>> >>> I had forgotten to mention my SipXECS version in my previous mail. I >>> fear it's still a 4.2. Haven't found the time to upgrade yet. >>> Your scenario appears mostly correct, although I didn't quite get the >>> first three points you enumerated. >>> >>> Just to add a few more details, I use FreeSWITCH as SBC in a B2BUA >>> configuration, connected to a few ITSP SIP providers. >>> So what actually happens is that I receive a SIP invite through my >>> ITSP account, which FreeSWITCH «bridges» with my SipXECS default AA. >>> When the AA answers the caller digits an internal extension number and >>> the call is transferred to that extension, which would be the 200 of >>> your example. >>> If nobody answers at 200 and user 201 dials *78200 as you imagined, >>> the call is instantiated solely between the external caller and >>> extension 201, as one might expect. >>> >>> However, if the user at 200 picks up the call after the user at 201 >>> has dialed *78200, they BOTH answer the call, in somethin akin to a >>> three-way conference. >>> >>> I do realize it's not intended to behave that way, but it might become >>> a useful feature rather than a bug for quite a few people, hopefully. >>> >>> Regards, >>> Fulvio >>> >>> 2011/10/18 Kumaran T<[email protected]>: >>>> Hi Fulvio, >>>> Which Build you seeing this issue? >>>> I tried in latest 4.5.2 build by following scenario and its working >>>> fine.Please let me know my scenario was right? >>>> 1.DID no assigned to AA >>>> 2.Call DID number from PSTN number >>>> 3.AA will answer and dial 200 from pstn number >>>> 4.The call will transferred to 200 and 200 will start ringing >>>> 5.From 201 user dialed *78200 >>>> 6. Call is retrieved and call will disconnected from 200 >>>> 7.Call will established between pstn user and 201.. >>>> >>>> Regards, >>>> Kumaran T >>>> >>>> On 10/18/2011 1:22 PM, Fulvio Scapin wrote: >>>>> Hello again. >>>>> I've been finally able to reproduce in a repeatable way the phenomenon >>>>> I described a few weeks ago. >>>>> >>>>> Situation: >>>>> >>>>> Call from outside to the SipXECS-based IVR, dialing the internal >>>>> extension directly through the IVR, let's say extension 31. >>>>> >>>>> Extension 31 (polycom soundpoint 550) rings. >>>>> >>>>> The operator at extension 30 (also polycom soundpoint 550) dials *7831 >>>>> to pick up the call. >>>>> After he has dialed *7831 the user at extension 31 picks up the call >>>>> and begins talking. >>>>> A second or two later the user at extension 30 picks up the call as >>>>> well. >>>>> >>>>> End result: >>>>> >>>>> A three-way call in which each of three parties involved can speak >>>>> with and hear the other two. >>>>> >>>>> >>>>> Am I the only one finding this peculiar? >>>>> >>>>> Bye, >>>>> Fulvio Scapin >>>>> _______________________________________________ >>>>> sipx-users mailing list >>>>> [email protected] >>>>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>>> _______________________________________________ >>>> sipx-users mailing list >>>> [email protected] >>>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>>> >>> _______________________________________________ >>> sipx-users mailing list >>> [email protected] >>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> >> -- >> ====================== >> Tony Graziano, Manager >> Telephone: 434.984.8430 >> sip: [email protected] >> Fax: 434.465.6833 >> >> Email: [email protected] >> >> LAN/Telephony/Security and Control Systems Helpdesk: >> Telephone: 434.984.8426 >> sip: [email protected] >> >> Helpdesk Contract Customers: >> http://support.myitdepartment.net >> Blog: >> http://blog.myitdepartment.net >> >> Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 >> Ask about our Internet Fax services! >> >> _______________________________________________ >> sipx-users mailing list >> [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> >> _______________________________________________ >> sipx-users mailing list >> [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
