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@crocodile-rcs.comwrote:
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
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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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
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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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:
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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
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@tutpro.com Sender: sr-dev-bounces@lists.sip-router.org To: sr-dev@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
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:
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@tutpro.com Sender: sr-dev-bounces@lists.sip-router.org To: sr-dev@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
8 jan 2013 kl. 10:43 skrev Peter Dunkley peter.dunkley@crocodile-rcs.com:
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:
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@tutpro.com Sender: sr-dev-bounces@lists.sip-router.org To: sr-dev@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Peter Dunkley Technical Director Crocodile RCS Ltd _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Also can a flow fail temporarily?
For example a broadband router with a NAT timeout of 60 seconds and a UA with a keep-alive interval of 120s. Would the flow succeed for the first 60 seconds after each keep-alive and then fail for 60 seconds until the next keepalive?
And would this generate a 430 or would it generate a different response code?
On the other hand this quote from the RFC makes it sounds like 430 represents a permanent condition:
If the flow no longer exists, the proxy SHOULD send a 430 (Flow Failed) response to the request.
Richard
On 8 January 2013 09:55, Olle E Johanson olle@ozone.webway.se wrote:
8 jan 2013 kl. 10:43 skrev Peter Dunkley <peter.dunkley@crocodile-rcs.com
:
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:
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@tutpro.com Sender: sr-dev-bounces@lists.sip-router.org To: sr-dev@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 listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Peter Dunkley Technical Director Crocodile RCS Ltd
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
10 jan 2013 kl. 11:50 skrev Richard Brady rnbrady@gmail.com:
Also can a flow fail temporarily?
For example a broadband router with a NAT timeout of 60 seconds and a UA with a keep-alive interval of 120s. Would the flow succeed for the first 60 seconds after each keep-alive and then fail for 60 seconds until the next keepalive?
Yes. That's a misconfigured ua, isn't it... The UA will have to make sure to manage connections properly so at least one of the two are always open and working... Outbound is all about pushing responsiblity for the flows to the UA.
And would this generate a 430 or would it generate a different response code?
On the other hand this quote from the RFC makes it sounds like 430 represents a permanent condition:
If the flow no longer exists, the proxy SHOULD send a 430 (Flow Failed) response to the request.
Well, Outbound is very focused on TCP. It's alive or dead. It doesn't behave like UDP.
/O
Richard
On 8 January 2013 09:55, Olle E Johanson olle@ozone.webway.se wrote:
8 jan 2013 kl. 10:43 skrev Peter Dunkley peter.dunkley@crocodile-rcs.com:
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:
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@tutpro.com Sender: sr-dev-bounces@lists.sip-router.org To: sr-dev@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Peter Dunkley Technical Director Crocodile RCS Ltd _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Also can a flow fail temporarily?
For example a broadband router with a NAT timeout of 60 seconds and a UA with a keep-alive interval of 120s. Would the flow succeed for the first 60 seconds after each keep-alive and then fail for 60 seconds until the next keepalive?
Yes. That's a misconfigured ua, isn't it...
Don't think so. It is not easy or common for UAs to discover the NAT timeout. They must make assumptions about what is a reasonable lower bound, unless you are mad enough to expect the user to configure this. On mobile / battery-powered devices it is often not an option to configure a keep-alive interval that low.
But if you want a different example then take an unreliable network connection. My question was more about whether the EP would generate a 430 or a 408/503/504 in this kind of potentially temporary failure case.
The UA will have to make sure to manage connections properly so at least
one of the two are always open and working...
Yes AND the proxy has to manage those flows properly so both of the two are always tired when necessary and preferably not after a 32 second timeout trying a flow which it should already know has failed.
Keep in mind the the flows are tried serially, not in parallel.
Outbound is all about pushing responsiblity for the flows to the UA.
Responsibility for initiating them yes. But there is a whole lot for the server to do and that is what we're trying to get to the bottom of.
Well, Outbound is very focused on TCP. It's alive or dead. It doesn't behave like UDP.
So if the network flaps for 60 seconds is a TCP connection dead or alive?
Richard
i didn't find in rfc5626 a requirement that registrar should remove 430 flow contact,
Closest I can find is:
"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."
Richard Brady writes:
i didn't find in rfc5626 a requirement that registrar should remove 430 flow contact,
Closest I can find is:
"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."
it is thus the job of the proxy, not the registrar, to remove the currently unusable registration. the proxy could do it either by sending un-REGISTER request to registrar or via an mi/rpc command. the former is possible now. the latter requires that instance and reg_id params are added to ul_rm_contact mi command.
-- juha
Richard Brady writes:
i didn't find in rfc5626 a requirement that registrar should remove
430
flow contact,
Closest I can find is:
"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."
it is thus the job of the proxy, not the registrar, to remove the currently unusable registration. the proxy could do it either by sending un-REGISTER request to registrar or via an mi/rpc command. the former is possible now. the latter requires that instance and reg_id params are added to ul_rm_contact mi command.
When we were discussing implementing outbound someone (I think it was Inaki) did mention that some parts of the outbound spec were unclear on precisely how to implement things. This could well be one of those parts - no mention except in an example, and even there the description "feels" a bit wrong.
I just don't like the idea that an edge proxy should need to be a UAC and generate an un-REGISTER. Adding an MI/RPC command would be implementation specific. Making the registrar capable of removing a contact in response to receiving a 430 seems far more logical and is going to be no harder than adding an MI/RPC command to do it.
I will add a new exported function to registrar, probably called unregister_contact(), at some point in the future. I don't think it is a big job but it almost certainly won't happen before the freeze - it may be a couple of weeks before I have time to come back to it.
Regards,
Peter
-
Juha Heinanen -
Olle E Johanson -
Olle E. Johansson -
Peter Dunkley -
Richard Brady