4 Mar
2013
4 Mar
'13
5:55 a.m.
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?
Thanks.
Peter
4 Mar
4 Mar
11:06 a.m.
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.
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 -
11:35 a.m.
New subject: Outbound registrar.lookup() not ordering results by reg-id?
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.
11:57 a.m.
On 3/4/13 5:35 PM, Olle E. Johansson wrote:
4 mar 2013 kl. 17:06 skrev Daniel-Constantin Mierla
<miconda(a)gmail.com>om>:
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 -
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. 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.
5 Mar
5 Mar
3:47 a.m.
New subject: Outbound registrar.lookup() not ordering results by reg-id?
4 mar 2013 kl. 17:57 skrev Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
On 3/4/13 5:35 PM, Olle E. Johansson wrote:
I agree it's not a blocker, but there's another point I want to make here too.
I've always been trying to be strict in marketing - don't promise too much and try
to be honest. If we claim to support a feature, we should support it. I don't like
people saying that Asterisk 11 supports WebRTC, since it doesn't even support the
current proposals, and the technology is still under development. Asterisk 11 will likely
never support WebRTC because that would violate the current release policy.
Now, if a core feature in outbound is missing we can not claim that Kamailio 4.0.0.
supports outbound. Failover between flows in outbound is a core feature of the outbound
standard. We can say that we have an early development release of an outbound module and
fix it for a later release. Sometimes things just doesn't finish on time in Open
Source, where we depend on contributions of individual time or commercial funding. I think
we have to communicate clearly here and tell our user base that this module is not
finished.
Regarding the handling of 302 - yes, I agree with you in theory - the RFC claims what you
say. Unfortunately not all implementations agree with the standard. There are many DND
buttons on SIP phones that send a 302 that you want to handle in the core network. The DND
could lead to a secretary and her phone should start to ring while other phones are still
ringing. Every case is different and has to be handled in the configuration script on a
case by case basis.
For a softphone 302 where companies seldom has control over the configuration, I
wouldn't trust the 302 in the core, so I would send it back all the way if needed.
Cheers,
/O
4 mar 2013 kl. 17:06 skrev Daniel-Constantin
Mierla <miconda(a)gmail.com>om>:
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. 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. 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.
12:24 p.m.
Hi guys,
Hugh Waite will be looking into the forking related issues with outbound
shortly.
I believe Olle's current proposal of a failure_branch_route[] is the
current favoured one, but once Hugh has had a chance to think about this
properly he will put out an email to the list with a proposed solution.
Regards,
Peter
8:21 p.m.
New subject: Outbound registrar.lookup() not ordering results by reg-id?
Olle E. Johansson writes:
Now, if a core feature in outbound is missing we can
not claim that
Kamailio 4.0.0. supports outbound. Failover between flows in outbound
is a core feature of the outbound standard.
olle,
i don't dispute the support claim, but we do support failover in the
common case where only one UA registers the same aor.
We can say that we have an
early development release of an outbound module and fix it for a later
release.
i think it is the tm module that is incomplete here, i.e., the
capability to replace a failing branch of a transaction is missing.
-- juha
4 Mar
4 Mar
12:07 p.m.
As far as I can tell the reg-id is not checked anywhere in the
t_(load|next)_contacts functions (or the new one related to flows). I
think this means that the contacts are not ordered by reg-id here -
which is incorrect for outbound.
Regards,
Peter
On 04/03/13 16:06, Daniel-Constantin Mierla wrote:
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.
Cheers,
Daniel
1:23 p.m.
Peter Dunkley writes:
As far as I can tell the reg-id is not checked
anywhere in the
t_(load|next)_contacts functions (or the new one related to flows). I
think this means that the contacts are not ordered by reg-id here -
which is incorrect for outbound.
peter,
you are correct. t_serial.c functions do not order contacts based on
reg-id, only based on q. i must have missed that requirement in the
rfc. can you quote the requirement?
-- juha
8:59 p.m.
Peter Dunkley writes:
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).
peter,
i implemented what is stated in chapter 7 of outbound rfc, specifically:
o The proxy MUST NOT populate the target set with more than one
contact with the same AOR and instance-id at a time.
o If a request for a particular AOR and instance-id fails with a 430
(Flow Failed) response, the proxy SHOULD replace the failed branch
with another target (if one is available) with the same AOR and
instance-id, but a different reg-id.
in above, the requirement is "different" reg-id". it does not require
ordering based on reg-id. may be ordering is specified in some other
rfc?
the major problem is that currently kamailio has no way to replace just
the failed branch. it is thus possible to try other reg-id contacts
only after all contacts in the current destination set have failed and
failure route is executed.
-- juha
5 Mar
5 Mar
8 a.m.
Hi Juha,
I re-read the RFC this morning. I was mistaken about the reg-id
requirement. I have gone through my notes and emails and this seems to
have been the result of a misunderstanding during a conversation about
the development several months ago.
Thanks,
Peter
On 05/03/13 01:59, Juha Heinanen wrote:
Peter Dunkley writes:
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).
peter,
i implemented what is stated in chapter 7 of outbound rfc, specifically:
o The proxy MUST NOT populate the target set with more than one
contact with the same AOR and instance-id at a time.
o If a request for a particular AOR and instance-id fails with a 430
(Flow Failed) response, the proxy SHOULD replace the failed branch
with another target (if one is available) with the same AOR and
instance-id, but a different reg-id.
in above, the requirement is "different" reg-id". it does not require
ordering based on reg-id. may be ordering is specified in some other
rfc?
the major problem is that currently kamailio has no way to replace just
the failed branch. it is thus possible to try other reg-id contacts
only after all contacts in the current destination set have failed and
failure route is executed.
-- juha
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
4181
days inactive
4183
days old
10 comments
4 participants
participants (4)
-
Daniel-Constantin Mierla -
Juha Heinanen -
Olle E. Johansson -
Peter Dunkley