5 Mar
2013
5 Mar
'13
3:35 a.m.
4 mar 2013 kl. 17:06 skrev Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Hello,
On 3/4/13 11:55 AM, Peter Dunkley wrote:
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(a)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
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.