[sr-dev] Outbound registrar.lookup() not ordering results by reg-id?

Olle E. Johansson oej at edvina.net
Mon Mar 4 17:35:54 CET 2013


4 mar 2013 kl. 17:06 skrev Daniel-Constantin Mierla <miconda at gmail.com>:

> 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.

Here's the issue:

Like with the example of a 302 for one call leg in a parallell fork, we need to handle one call leg here too.

Let's assume I have a SIP account miconda at edvina.net and you register two phones with outbound, which means at least four contacts, in groups of two sharing the same +sip.instance but have different reg-id's.

If I call these and one phone has an issue, then the edge proxy reports 430 flow failed and I need to move to the other reg-id contact for that phone only. 

As far as I understand today, I can't retarget unless I hit failure_route. I won't hit that as long as our other phone is ringing.

That's why I suggested we consider a failure_branch_route() for these kind of retargets that won't affect the fork. This is like the earlier example on the mailing list where I forked to multiple phones, one sent 302. I would like to follow that 302 before the fork completes and ends up in failure_route or gets a 200 OK.

/O


More information about the sr-dev mailing list