Well actually the remote caller called through our FreeSWITCH in a
B2BUA role, so I might say that the «remote» UA was FreeSWITCH.
.
2011/8/26 Fulvio Scapin <[email protected]>:
> All the UAs where Polycom SoundPoint IP 550. I don't remember what the
> firmware version was at the time.
> Honestly, at the time we didn't want to confuse the client calling us,
> so we didn't exactly explore the situation.
> However I think the call was full-duplex (and B didn't pick up the call).
>
> Btw, I know it's difficult to implement, especially if one uses an
> external B2BUA instead of, or in parallel to sipXbridge, but are there
> news or future projects about call recording?
> As you might imagine, in a business/marketing environment, it could be
> a very useful feature.
>
> Bye and thanks,
> Fulvio Scapin
>
> 2011/8/13 Joegen Baclor <[email protected]>:
>> This is definitely a race condition and will be very hard to reproduce. If
>> the calling UA got confused (or actually supports adhoc conferencing
>> multiple early media channels) due to a fork then you will get exactly what
>> you have experienced. The trick is both 200 Ok must be close enough to each
>> other so as not to generate a CANCEL to one of the transactions.
>>
>> A couple of questions to determine if it's a case of a UA confused by fork
>> or a cool UA feature supporting multi channel forks:
>>
>> 1. is the audio heard by C and A full duplex? Meaning (C and A can talk to
>> each other)
>> 2. Can both C and A be heard by B?
>>
>> if the answer to both Q's is yes, then you got a very cool UA. Send in the
>> brand.
>>
>> On 08/12/2011 09:01 PM, Fulvio Scapin wrote:
>>>
>>> Hello to everyone.
>>> Just wishing to report a strange accident occured to me some time ago
>>> (so forgive me were the details a bit vague), mostly out of curiosity
>>> about possible similar experiences.
>>> A small orientation about my setup:
>>> FreeSWITCH as a B2B UA connected to serveral ITSPs, upstream from a
>>> SipXecs proxy, redirecting incoming calls to an auto-attendant
>>> embedded in SipXecs.
>>>
>>> The strange event happened as follows:
>>>
>>> * incoming calls directed to a hunt group of SipXecs after exiting the
>>> default auto-attendant
>>> * phone A not in the hunt group, phones B and C in the hunt group
>>> * phones B and C ring
>>> * phone A tries to pick up the call with *78 and extension B
>>> * simultaneously phone C picks up the call
>>>
>>> Result:
>>> the two sides of the call are heard by both C and A, as if, for
>>> instance, one was monitoring C's call using phone A .
>>>
>>> Since call monitoring isn't a built-in feature of SipXecs (and my boss
>>> said 'I want that' as soon as we understood what had taken place), I
>>> was wondering whether mine was a freak accident or something more
>>> promising.
>>>
>>> Regards,
>>> 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/
