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]
<mailto:[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]
<mailto:[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]
<mailto:[email protected]>
>> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
> _______________________________________________
> sipx-users mailing list
> [email protected]
<mailto:[email protected]>
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
_______________________________________________
sipx-users mailing list
[email protected] <mailto:[email protected]>
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
======================
Tony Graziano, Manager
Telephone: 434.984.8430
sip: [email protected]
<mailto:[email protected]>
Fax: 434.465.6833
Email: [email protected] <mailto:[email protected]>
LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: [email protected]
<mailto:[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/
