7 Jan
2013
7 Jan
'13
2:54 p.m.
Hi Peter
Great work on this! We'd like to help you test.
The test I have in mind, which we could create using SIPp, would be to
register multiple contacts with the same instance-id (i.e. "sip.instance"
param) but different reg-id params. Then send an INVITE to that AoR and
make sure the forking is only per instance-id and not per reg-id. This
could be repeated in multiple permutations of instance-ids and reg-ids.
This would be a test of save() and lookup() more than anything else. Is
that what you had in mind?
Richard
On 3 January 2013 14:13, Peter Dunkley <peter.dunkley(a)crocodile-rcs.com>wrote;wrote:
I hope to get the outbound edge proxy and flow timer
stuff into master by
Monday, but it could really do with some additional testing especially in
conjunction with the reg-id stuff in registrar/usrloc (which I have no idea
how to use).
Peter
7 Jan
7 Jan
3:34 p.m.
New subject: [SR-Users] Testing SIP Outbound / RFC5626 (Was: Freezing for next major release)
Hi Richard,
I haven't been directly involved with the coding of the registrar stuff.
This does sound like testing worth doing.
Also worth adding tests to check that if you get a 430 back after
routing to one reg-id you can try the next.
Peter
On Mon, 2013-01-07 at 12:54 +0000, Richard Brady wrote:
Hi Peter
Great work on this! We'd like to help you test.
The test I have in mind, which we could create using SIPp, would be to
register multiple contacts with the same instance-id (i.e.
"sip.instance" param) but different reg-id params. Then send an INVITE
to that AoR and make sure the forking is only per instance-id and not
per reg-id. This could be repeated in multiple permutations of
instance-ids and reg-ids.
This would be a test of save() and lookup() more than anything else.
Is that what you had in mind?
Richard
On 3 January 2013 14:13, Peter Dunkley
<peter.dunkley(a)crocodile-rcs.com> wrote:
I hope to get the outbound edge proxy and flow timer stuff
into master by Monday, but it could really do with some
additional testing especially in conjunction with the reg-id
stuff in registrar/usrloc (which I have no idea how to use).
Peter
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
9:46 p.m.
New subject: [SR-Users] Testing SIP Outbound / RFC5626 (Was: Freezing for next major release)
Peter Dunkley writes:
I haven't been directly involved with the coding
of the registrar stuff.
This does sound like testing worth doing.
i did the registrar stuff and tested it with baresip, which supports
outbound. more testing is of course welcome.
-- juha
8 Jan
8 Jan
12:07 a.m.
New subject: [SR-Users] Testing SIP Outbound / RFC5626 (Was: Freezing for next major release)
Hi Juha,
I assumed as much, but what I haven't had the chance to do myself yet is the full
end-to-end scenario where the Kamailio edge proxy indicates a broken flow and the
registrar successfully re-routes through another flow.
Peter
On 7 Jan 2013, at 19:46, Juha Heinanen <jh(a)tutpro.com> wrote:
Peter Dunkley writes:
I haven't been directly involved with the
coding of the registrar stuff.
This does sound like testing worth doing.
i did the registrar stuff and tested it with baresip, which supports
outbound. more testing is of course welcome.
-- juha
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
12:41 a.m.
New subject: [SR-Users] Testing SIP Outbound / RFC5626 (Was: Freezing for next major release)
Hi Juha,
I was wondering if you could provide an example of how to use
lookup()/lookup_branches(), t_load_contacts(), t_next_contacts(), and
t_next_contacts_flows() for registrar supporting outbound with an edge
proxy?
From the documentation of these functions it does look
like parallel and
serial forking and outbound should "just work" if they
are used properly.
Is that correct?
One requirement of an outbound capable registrar is that if a flow fails
(edge proxy returns a 430) the registrar should realise that the flow is
now dead and remove that contact binding from its database so it is not
used again as well as trying the next contact. I can't see anything that
will do this? Is this missing?
Thanks,
Peter
Peter Dunkley writes:
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
I haven't been directly involved with the
coding of the registrar stuff.
This does sound like testing worth doing.
i did the registrar stuff and tested it with baresip, which supports
outbound. more testing is of course welcome.
-- juha
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
4:40 a.m.
New subject: [SR-Users] Testing SIP Outbound / RFC5626 (Was: Freezing for next major release)
Peter Dunkley writes:
I was wondering if you could provide an example of how
to use
lookup()/lookup_branches(), t_load_contacts(), t_next_contacts(), and
t_next_contacts_flows() for registrar supporting outbound with an edge
proxy?
peter,
in my tests i did like this:
1) in route block, called lookup("location") followed by
t_load_contacts(), t_next_contacts(), and t_relay().
2) in failure route block, if status was 408 or 430, called first
t_next_contact_flows() and, if that failed, called t_next_contacts(); if
status was something else, skipped t_next_contact_flows() and only
called t_next_contacts(). after that called t_relay().
i have never used lookup_branches() and don't even know what it does.
-- juha
4:46 a.m.
New subject: [SR-Users] Testing SIP Outbound / RFC5626 (Was: Freezing for next major release)
Peter Dunkley writes:
One requirement of an outbound capable registrar is
that if a flow fails
(edge proxy returns a 430) the registrar should realise that the flow is
now dead and remove that contact binding from its database so it is not
used again as well as trying the next contact. I can't see anything that
will do this? Is this missing?
peter,
i didn't find in rfc5626 a requirement that registrar should remove 430
flow contact, but, if there is such a requirement, in my opinion removal
should be done from failure route in the script by a function that
removes the contact.
a similar thing was discussed a while back (see below).
-- juha
From: Juha Heinanen <jh(a)tutpro.com>
Sender: sr-dev-bounces(a)lists.sip-router.org
To: sr-dev(a)lists.sip-router.org
Subject: [sr-dev] git:master: usrloc(k): keep time of the last keepalive for
natted UDP contacts
Date: Thu, 13 Sep 2012 17:08:51 +0300
Klaus wrote:
Why only UDP? Are TCP contacts removed when the TCP connections is closed?
IMO there should also be a mechanism to remove ALL expired unresponsive
contacts.
how about the following for tcp contacts:
- set_forward_no_connect();
- if t_relay() fails because tcp connection does not exist,
unregister the AoR/contact
what would be needed is a find out that t_relay() failed due to
non-existing connection and a script function to do un-registration of
an AoR/contact.
perhaps both of these two things already exist?
-- juha
11:43 a.m.
New subject: [SR-Users] Testing SIP Outbound / RFC5626 (Was: Freezing for next major release)
Hi Juha,
A few months ago there was a discussion on IRC and the sr-dev list about
what is needed for outbound. This requirement to remove broken contacts
was presented then by someone as something that (although not explicit
in the RFC) is needed.
If a flow is broken, particularly one over TCP where the connection is
established from the UAC to the edge proxy, then it will never work
again. As such it is extremely wasteful to continue to try and use that
flow (in preference to one that will work) for each new dialog forming
request. Further, as re-REGISTER times can be quite long, not removing
broken contacts could lead to a significant/growing number of dead
contacts (all of which will be tried for each new dialog forming
request) in the location table.
There is an unregister() function in the registrar module, there are
also the reg_(fetch|free)_contacts() functions in the registrar module.
None of these appear to do quite what is required.
Peter
On Tue, 2013-01-08 at 04:46 +0200, Juha Heinanen wrote:
Peter Dunkley writes:
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
One requirement of an outbound capable registrar
is that if a flow fails
(edge proxy returns a 430) the registrar should realise that the flow is
now dead and remove that contact binding from its database so it is not
used again as well as trying the next contact. I can't see anything that
will do this? Is this missing?
peter,
i didn't find in rfc5626 a requirement that registrar should remove 430
flow contact, but, if there is such a requirement, in my opinion removal
should be done from failure route in the script by a function that
removes the contact.
a similar thing was discussed a while back (see below).
-- juha
From: Juha Heinanen <jh(a)tutpro.com>
Sender: sr-dev-bounces(a)lists.sip-router.org
To: sr-dev(a)lists.sip-router.org
Subject: [sr-dev] git:master: usrloc(k): keep time of the last keepalive for
natted UDP contacts
Date: Thu, 13 Sep 2012 17:08:51 +0300
Klaus wrote:
Why only UDP? Are TCP contacts removed when the TCP connections is closed?
IMO there should also be a mechanism to remove ALL expired unresponsive
contacts.
how about the following for tcp contacts:
- set_forward_no_connect();
- if t_relay() fails because tcp connection does not exist,
unregister the AoR/contact
what would be needed is a find out that t_relay() failed due to
non-existing connection and a script function to do un-registration of
an AoR/contact.
perhaps both of these two things already exist?
-- juha
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev 
11:55 a.m.
New subject: [SR-Users] Testing SIP Outbound / RFC5626 (Was: Freezing for next major release)
8 jan 2013 kl. 10:43 skrev Peter Dunkley <peter.dunkley(a)crocodile-rcs.com>om>:
Hi Juha,
A few months ago there was a discussion on IRC and the sr-dev list about what is needed
for outbound. This requirement to remove broken contacts was presented then by someone as
something that (although not explicit in the RFC) is needed.
Just a clarification:
Section 9.3 says that
"Bob's authoritative proxy first tries the flow to EP1,
but EP1 no longer has a flow to Bob, so it responds with a 430 (Flow
Failed) response. The proxy removes the stale registration and tries
the next binding for the same instance."
But it is not mentioned in the server handling section of the Outbound RFC.
/O
If a flow is broken, particularly one over TCP where the connection is established from
the UAC to the edge proxy, then it will never work again. As such it is extremely
wasteful to continue to try and use that flow (in preference to one that will work) for
each new dialog forming request. Further, as re-REGISTER times can be quite long, not
removing broken contacts could lead to a significant/growing number of dead contacts (all
of which will be tried for each new dialog forming request) in the location table.
There is an unregister() function in the registrar module, there are also the
reg_(fetch|free)_contacts() functions in the registrar module. None of these appear to do
quite what is required.
Peter
On Tue, 2013-01-08 at 04:46 +0200, Juha Heinanen wrote:
Peter Dunkley writes:
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev One requirement of an outbound capable registrar
is that if a flow fails
(edge proxy returns a 430) the registrar should realise that the flow is
now dead and remove that contact binding from its database so it is not
used again as well as trying the next contact. I can't see anything that
will do this? Is this missing?
peter,
i didn't find in rfc5626 a requirement that registrar should remove 430
flow contact, but, if there is such a requirement, in my opinion removal
should be done from failure route in the script by a function that
removes the contact.
a similar thing was discussed a while back (see below).
-- juha
From: Juha Heinanen <jh(a)tutpro.com>
Sender: sr-dev-bounces(a)lists.sip-router.org
To: sr-dev(a)lists.sip-router.org
Subject: [sr-dev] git:master: usrloc(k): keep time of the last keepalive for
natted UDP contacts
Date: Thu, 13 Sep 2012 17:08:51 +0300
Klaus wrote:
Why only UDP? Are TCP contacts removed when the TCP connections is closed?
IMO there should also be a mechanism to remove ALL expired unresponsive
contacts.
how about the following for tcp contacts:
- set_forward_no_connect();
- if t_relay() fails because tcp connection does not exist,
unregister the AoR/contact
what would be needed is a find out that t_relay() failed due to
non-existing connection and a script function to do un-registration of
an AoR/contact.
perhaps both of these two things already exist?
-- juha
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
4337
days inactive
4338
days old
8 comments
4 participants
participants (4)
-
Juha Heinanen -
Olle E Johanson -
Peter Dunkley -
Richard Brady