On 3/4/13 5:35 PM, Olle E. Johansson wrote:
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.
I think this is quite a debatable aspect, which is more a handling
preference than a issue, so eventually can end up in some config option.
First, a 302 should be normally sent back to caller -- that only after
all branches were processes, otherwise the caller has no idea there are
pending active branches on initial try and destroy dialog in its side. A
3xx received by caller usually creates completely new dialogs. Handling
302 on proxy is admin decision, not a SIP specs proxy requirements.
Personally I would not like to follow blindly a 3xx unless all branches
are completed with no answer, which differs from your preference, thus
again the need of an eventual configuration option (mod param, function,
event_route, etc...). But I don't find this a bug at all, it's been like
this from ser 0.8, I guess.
Regarding the flows priorities, I think the logic should be in tm (in
t_*_contacts*() or whatsoever), as said in previous email.
usrloc/registrar just populates destination set, it is tm that can do
serial/parallel forking. Even if not using t_*_contacts*(), that means
parallel forking to all records (no matter of flows), which eventually
cannot end up in something very bad, call being answered on first picked
up phone. Again, like with Q in normal contacts, a matter of admin
willing to take it in consideration or not.
From my point of view, this logic of selecting flows by priority should
be in those tm functions added by Juha (to follow the same architecture
as with Q), if not already there can be added at any time. But I don't
find it really a blocker.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, April 16-17, 2013, Berlin
- http://conference.kamailio.com -
_______________________________________________
sr-dev mailing list
[email protected]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
