4 Mar
2013
4 Mar
'13
9:07 p.m.
As far as I can tell the reg-id is not checked anywhere in the
t_(load|next)_contacts functions (or the new one related to flows). I
think this means that the contacts are not ordered by reg-id here -
which is incorrect for outbound.
Regards,
Peter
On 04/03/13 16:06, Daniel-Constantin Mierla wrote:
Hello,
On 3/4/13 11:55 AM, Peter Dunkley wrote:
Hi,
I've been looking at caching the ruid and while reading the code I
have not been able to understand how the contacts get correctly
ordered for outbound.
The contacts should be ordered so that those with the lowest reg-id
are the first tried for each ;+sip.instance. However, I can't see
any comparisons of reg-id anywhere (I've looked in usrloc, registrar,
and the tm:t_..._contacts() functions).
Have I missed something or is this (like the parallel forking issue
Olle reported from SIPit) another outbound registrar issue that we
need to fix?
location module keeps the records ordered by registration time, iirc.
By default, parallel forking does not care of Q value, will do
branching at once to all contacts.
If you need to take in consideration Q, then you have to use
t_load/next_contacts(). I assume it is the same for outbound and
reg-id, Juha implemented both of them.
In case the issues is something else, please refresh me with a link in
archive (or add to tracker) about the details after SIPit, I guess I
missed some discussions due to heavy traveling and may take me a while
to spot it in the history.
Cheers,
Daniel