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/
