We observed that the new Poly phones (formerly known as Polycom) were not getting sent a SIP UPDATE in certain circumstances (example: retrieving a parked call, and therefore, Caller ID would not show the parked caller). I renamed Polycom to Poly which will catch all Poly AND Polycom UA's. I also added Acrobits, and Ringotel to extend such functionality to those UA's. There were also other minor compatibility issues with the new Poly phones which have been resolved with tweaking the UA recognition on the code.
Co-authored-by: Joseph <junction1153@gmail.com>
In FS-6400, the attempt was made to randomize OPTIONS
packets to be sent at a random interval. The same random
interval is applied to all endpoints so this doesn't work.
Furthermore, rounding within the code, as well as
reseeding with srand() on each run will ultimately
make the ping times converge over time. Once the
times converge, they will not separate since the reseeding
will cause the same random number to apply to each
registration.
This commmit will apply the random interval only during
initial registration and update of registration.
All subsequent pings will be incremented with the
actual value of ping-mean-interval. (This parameter
name is no longer accurate, and would be better named
ping-max-interval).
srand() has been moved to the start of the worker
thread, and all repeat calls have been removed,
so that each call of rand(), even during the
same second, generates a different random number.
Fixes#1132, Fixes#1133
After rejecting the subscription for authentication the function calls goto end. In the end block freeswitch fires PRESENCE_PROBE events and releases the allocated memory
* when rejecting a call for auth PRESENCE_PROBE should not get fired
* This caused all other subscribers to the same entity to get flooded with NOTIFY's because `call_id` only gets set later in the function, so when firing the PRESENCE_PROBE without `call_id` being set all subscriptions will get a notify
* this can be considered a security flaw as any unauthorized user can send
SUBSCRIBES and trigger thousands of NOTIFY's to the SUBSCRIBED endpoints
This was fixed simply my moving down the end label after the code that
sends the PRESENCE_PROBE event
We use the transport of the Contact header of the remote UAC to decide
which of our own Contact addresses we should use when replying to a
SUBSCRIBE or sending a presence NOTIFY.
If TLS is not enabled on a Sofia profile, then the TLS Contacts for
that profile are NULL. Unfortunately we were using these NULL values
uncritically when the remote UAC sent us a Contact header with a TLS
transport and our own Sofia profile did not have TLS enabled.
With this commit we fall back to our TCP Contact address when the
remote Contact is TLS and our Sofia profile does not have TLS enabled.
Andrey Volk