4 mar 2013 kl. 17:06 skrev Daniel-Constantin Mierla <[email protected]>:

> 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 [email protected] 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
_______________________________________________
sr-dev mailing list
[email protected]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

Reply via email to