6 Dec
2012
6 Dec
'12
7:53 a.m.
On 12/6/12 1:35 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
that would be great!
I haven't studied exactly the algorithm, but from what I understood, the
contacts have to be sorted also by reg-id. What is not clear yet for me
is if Q values still plays a role.
First, it will require to propagate sip-instance and reg-id fields to
destination set (via branch_t structure) from usrloc/registrar -- just
adding some fields and copy the values as we do for example for path and q.
If Q has to be taken in consideration, I would guess that the list of
contacts will be grouped by sip-instance value, those groups will be
ordered by Q (like taking the highest q in the group and comparing with
the other groups). Inside the group, the order will be set by reg-id.
Selection of next destinations to try will be done by taking the first
within a group with same instance (perhaps doing parallel forking if
there are groups with same Q). If it is a failure, then will go and take
the next contacts in the groups (based on reg-id value).
Again, the part related to Q has to be clarified. Otherwise should be
about grouping on sip-instance and ordering by reg-id (lower reg-id is
first to use).
Thinking of these attributes, might be easier to work with xavps instead
of classic avps.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
This one can be also easily added, we have
t_load_contacts() which
serializes the contact records based on Q value. It has to be extended
to work on reg-id:
since i have implemented t_load_contacts()/t_next_contacts(),
perhaps i
can help here. tell me what kind of extension is needed and i'll try to
implement it.