Hello,
I thought I would try and produce a short summary (basically just bullet points) of what is required for Outbound just to make sure I haven't missed anything.
There are three use cases for Kamailio with Outbound/Path: * EDGE server between client and registrar * Registrar with EDGE server between it and client * Single server (EDGE server and registrar combined) using Outbound instead of aliasing for NAT traversal
EDGE server ----------- * Path - Existing Path module does (most of) what is required when called for REGISTER requests - Received parameters are not needed on Path: headers because we will use Outbound flow tokens now * Outbound - Need to generate/add flow token and ;ob parameter to the Path/Record-Route headers when: # It's an initial request (out-of-dialog INVITE, REGISTER, SUBSCRIBE, or REFER), with # A single Via:, and # Top Route: points to us and has ;ob parameter or Contact: has ;ob parameter or it's a REGISTER with ;+sip.instance, or # force_outbound() API has been called - Need to maintain mapping of flow tokens to connections (flow token to/from source address and port) - Need an Outbound routing API (related to loose_route()) that sets $du correctly based on flow token in Route: header (R-URI no longer used) - If the flow token doesn't match a connection send 430 response (response sending in kamailio.cfg, but Outbound routing API needs to return an appropriate error to support this)
Registrar --------- * Path - Path already supported in usrloc * Outbound - instance and reg IDs already stored in usrloc - multiple registrations with the same instance ID but different reg IDs must be supported (may be already) - Parallel and serial forking behaviour must be preserved, when forking branch to each unique instance ID not reg ID. - Need a new/improved lookup() API that returns the location for the best reg ID and populates an AVP with the other instance IDs in order they should be tried - On receipt of 430 response to a request the failed location should be removed from the usrloc table and the next location (from the AVP) tried. Similar to the way dispatcher works.
Single server ------------- * Path - Use this to add single (local) Path header - just needed to get the Outbound flow token into the usrloc table - Received parameters are not needed on Path: headers because we will use Outbound flow tokens now * Outbound - Similar to the combined behaviour of EDGE server and Registrar, but because the mapping of flow token to connection is local there is no need for the 430 response stuff - can just loop through the list of matching connections locally until a good one is found.
Note: Double-Path and advertised address... * Talking to one of my colleagues he thought that double-Path headers wouldn't be required. Double-RR is used to make sure the route-set is good in both directions when there are transport/network changes. Because Path is just used in the one direction this shouldn't be required. Does this make sense? * Because the Path header needs to show the address of the outbound interface it should use the advertised address for that interface, not the listening address of the interface. Is this correct?
Proposed API ------------ Right thing to do might be a new outbound module which provides both the EDGE server and registrar functions. The module would bind (through C-API - which might need extended/tweaked for each of the modules) to path, rr, registrar, and location modules to make use of the functions already implemented there. Probably (when Outbound is used) path, rr, and registrar will not be called from kamailio.cfg directly - the outbound wrapper functions will be used instead: * outbound_route(): use instead of rr.loose_route() (may well call rr.loose_route() internally but will also use flow token to work out value for $du) * outbound_record_route(): use instead of rr.record_route() (may well call rr.record_route() internally - but will also add the flow token (if the requirements for Outbound are met in the request)) * outbound_add_path(): use instead of path.add_path() (may well call path.add_path() internally - but will also add the flow token and generate it (and add to token/connection mapping table) for new connections (if the requirements for Outbound are met in the request)) * outbound_lookup(): use instead of registrar.lookup() (may well call registrar.lookup() internally - but will select the contact(s) with the best reg IDs and fill in AVP) * outbound_next_contact(): new API which will remove the first contact from the AVP _and_ location table and select the best remaining reg ID * force_outbound(): new API which will make sure flow tokens are added by outbound_record_route() and outbound_add_path() even if the request doesn't indicate client support
Token/connection map maintenance ---------------------------------- * Is there a need to add an event_route[] to catch connection closes (and a corresponding outbound module API to remove a token/connection mapping) as previously suggested by OEJ? * Is it OK for the outbound.outbound_route() function just to check that a connection found in the mapping table is valid when attempting to route a request (and removing the mapping and returning that there was no mapping when it isn't) - or would this lead to stuck entries in the mapping table? * Perhaps entries in the map should expire automatically anyway (so no catching of closes required) - they will be created when a client registers so there is an expiry time available?
Thanks,
Peter
9 aug 2012 kl. 00:32 skrev Peter Dunkley:
Hello,
I thought I would try and produce a short summary (basically just bullet points) of what is required for Outbound just to make sure I haven't missed anything.
There are three use cases for Kamailio with Outbound/Path:
- EDGE server between client and registrar
- Registrar with EDGE server between it and client
- Single server (EDGE server and registrar combined) using Outbound
instead of aliasing for NAT traversal
EDGE server
- Path
- Existing Path module does (most of) what is required when called for
REGISTER requests
- Received parameters are not needed on Path: headers because we will
use Outbound flow tokens now
- Outbound
- Need to generate/add flow token and ;ob parameter to the
Path/Record-Route headers when: # It's an initial request (out-of-dialog INVITE, REGISTER, SUBSCRIBE, or REFER), with # A single Via:, and # Top Route: points to us and has ;ob parameter or Contact: has ;ob parameter or it's a REGISTER with ;+sip.instance, or # force_outbound() API has been called
- Need to maintain mapping of flow tokens to connections (flow token
to/from source address and port)
- Need an Outbound routing API (related to loose_route()) that sets $du
correctly based on flow token in Route: header (R-URI no longer used)
- If the flow token doesn't match a connection send 430 response
(response sending in kamailio.cfg, but Outbound routing API needs to return an appropriate error to support this)
I would say "active connection". In the case of UDP, a failed UDP transmit could be an indication. There's a NAT keepalive protocol - very simple cr and cr+lf - to check the status of the connection.
Registrar
- Path
- Path already supported in usrloc
- Outbound
- instance and reg IDs already stored in usrloc
- multiple registrations with the same instance ID but different reg IDs
must be supported (may be already)
- Parallel and serial forking behaviour must be preserved, when forking
branch to each unique instance ID not reg ID.
- Need a new/improved lookup() API that returns the location for the
best reg ID and populates an AVP with the other instance IDs in order they should be tried
- On receipt of 430 response to a request the failed location should be
removed from the usrloc table and the next location (from the AVP) tried. Similar to the way dispatcher works.
Single server
- Path
- Use this to add single (local) Path header - just needed to get the
Outbound flow token into the usrloc table
- Received parameters are not needed on Path: headers because we will
use Outbound flow tokens now
- Outbound
- Similar to the combined behaviour of EDGE server and Registrar, but
because the mapping of flow token to connection is local there is no need for the 430 response stuff - can just loop through the list of matching connections locally until a good one is found.
A locally generated 408 should be treated as a 430 - right?
Note: Double-Path and advertised address...
- Talking to one of my colleagues he thought that double-Path headers
wouldn't be required. Double-RR is used to make sure the route-set is good in both directions when there are transport/network changes. Because Path is just used in the one direction this shouldn't be required. Does this make sense?
- Because the Path header needs to show the address of the outbound
interface it should use the advertised address for that interface, not the listening address of the interface. Is this correct?
Proposed API
Right thing to do might be a new outbound module which provides both the EDGE server and registrar functions. The module would bind (through C-API
- which might need extended/tweaked for each of the modules) to path, rr,
registrar, and location modules to make use of the functions already implemented there. Probably (when Outbound is used) path, rr, and registrar will not be called from kamailio.cfg directly - the outbound wrapper functions will be used instead:
- outbound_route(): use instead of rr.loose_route() (may well call
rr.loose_route() internally but will also use flow token to work out value for $du)
- outbound_record_route(): use instead of rr.record_route() (may well call
rr.record_route() internally - but will also add the flow token (if the requirements for Outbound are met in the request))
- outbound_add_path(): use instead of path.add_path() (may well call
path.add_path() internally - but will also add the flow token and generate it (and add to token/connection mapping table) for new connections (if the requirements for Outbound are met in the request))
- outbound_lookup(): use instead of registrar.lookup() (may well call
registrar.lookup() internally - but will select the contact(s) with the best reg IDs and fill in AVP)
- outbound_next_contact(): new API which will remove the first contact
from the AVP _and_ location table and select the best remaining reg ID
- force_outbound(): new API which will make sure flow tokens are added by
outbound_record_route() and outbound_add_path() even if the request doesn't indicate client support
Token/connection map maintenance
- Is there a need to add an event_route[] to catch connection closes (and
a corresponding outbound module API to remove a token/connection mapping) as previously suggested by OEJ?
Think UDP too. "Connection close" => "connection failures" :-) In some cases, you might want to do external things when this happens, alert a system, change iptables mappings or something else.
- Is it OK for the outbound.outbound_route() function just to check that a
connection found in the mapping table is valid when attempting to route a request (and removing the mapping and returning that there was no mapping when it isn't) - or would this lead to stuck entries in the mapping table?
- Perhaps entries in the map should expire automatically anyway (so no
catching of closes required) - they will be created when a client registers so there is an expiry time available?
Since we reuse the connection, the connection and the registration should not be assumed to have the same expiry. When registration expires there may still be an active dialog on that connection. Mapping these would be hard, like a phone with one registration, five subscriptions and an active call dialog on the same connection. We can't assume that the phone call should be hung up because the registred contact expires.
/O
Peter Dunkley wrote:
I thought I would try and produce a short summary (basically just bullet points) of what is required for Outbound just to make sure I haven't missed anything.
Thanks for that. The chatlogs sure were nice, but this makes discussions a lot easier.
EDGE server
- Path
- Existing Path module does (most of) what is required when called for REGISTER requests
- Received parameters are not needed on Path: headers because we will use Outbound flow tokens now
- Outbound
- Need to generate/add flow token and ;ob parameter to the Path/Record-Route headers when:
I'd like to see the flow-token mechanism replace the current received mechanism. Conceptionally, they are the same: a string representation of the two endpoint addresses of a flow. Which also means you don't really need to keep a mapping of connections and flow tokens. From any given pair of local and remote address, you can simply calculate it on the fly.
For the edge server, things are easy: Put the flow token into the user part of Route, Record-Route, or Path headers. The all-in-one proxy would store the flow token instead of the pair of received and socket in location (or possibly as a fake Path? This would end up as a Route header in outgoing requests, which should be okay, and would have the advantage of no need to change the location table yet again.)
If I am not mistaken, this mechanism works independently of whether the endpoint supports outbound or not. If it doesn't this is just like what we do today except that we won't meddle with Contact URIs and other mean things (there'd still be meddeling with SDP but that's a different topic).
- If the flow token doesn't match a connection send 430 response (response sending in kamailio.cfg, but Outbound routing API needs to return an appropriate error to support this)
Essentially, this would be changing the current proprietary 477 to a 430. Probably easiest to add a config parameter and let the admin decide what exactly they want.
Things are a bit more complicated with UDP. I think replacing the current local 408 with a local 430 if the UAS side of the transaction times out (fr_timer, I believe?) should do the trick. This is nonewithstanding a 408 in case the whole transaction times out (fr_inv_timer). Maybe we add optional event routes for these which would be called instead of generating these local responses when set?
Note: Double-Path and advertised address...
- Talking to one of my colleagues he thought that double-Path headers
wouldn't be required. Double-RR is used to make sure the route-set is good in both directions when there are transport/network changes. Because Path is just used in the one direction this shouldn't be required. Does this make sense?
Correct. The Path is basically just a route for out-of-dialog messages. The route set for a dialog is generated by way of Record-Route headers inserted during dialog creation.
- Because the Path header needs to show the address of the outbound
interface it should use the advertised address for that interface, not the listening address of the interface. Is this correct?
Yes, but keepp in mind that the flow token is only good for a particular flow between two particular endpoint addresses (this being transport, IP address, and port tuples). So, if the edge receives an outgoing request (meaning towards the endpoint) with a valid hostport in the Route URI but a flow token for a local address it doesn't serve, it would have to fail. For incoming requests, it could rewrite the route set with a new Route URI for this particular flow.
Hence I am not sure if it makes sense at all to advertise anything other than the actual listening address. In one direction, your dialog will be broken if the flow fails, anyways.
Proposed API
Right thing to do might be a new outbound module which provides both the EDGE server and registrar functions.
I'd prefer if we could do this through config and only enhance the C APIs where needed. With the new include logics and whatnot, this can come in the form of a config library.
Best regards, Martin
On Thu, 2012-08-09 at 10:10 +0200, Martin Hoffmann wrote:
I'd prefer if we could do this through config and only enhance the C APIs where needed. With the new include logics and whatnot, this can come in the form of a config library.
You can do includes but you can't put complex functions with parameters into a config library. So you would end up having to do it as routes with pseudo-variables to pass data around. I think this would be very messy for something as complex as Outbound - and there is always the chance you might use a route-name or variable name that someone else has (making it hard for them to add Outbound support to an existing configuration).
A lot of the business logic for Outbound will be done in the configuration anyway (failure-routes to generate/convert status to 430 and so on) mainly because this is right place for that stuff, but surely a new module that has drop-in replacements for existing functions (like record_route(), loose_route(), lookup() and so on) is going to be easier for people to work with?
Or have I misunderstood?
Regards,
Peter
9 aug 2012 kl. 16:00 skrev Peter Dunkley:
On Thu, 2012-08-09 at 10:10 +0200, Martin Hoffmann wrote:
I'd prefer if we could do this through config and only enhance the C APIs where needed. With the new include logics and whatnot, this can come in the form of a config library.
You can do includes but you can't put complex functions with parameters into a config library. So you would end up having to do it as routes with pseudo-variables to pass data around. I think this would be very messy for something as complex as Outbound - and there is always the chance you might use a route-name or variable name that someone else has (making it hard for them to add Outbound support to an existing configuration).
A lot of the business logic for Outbound will be done in the configuration anyway (failure-routes to generate/convert status to 430 and so on) mainly because this is right place for that stuff, but surely a new module that has drop-in replacements for existing functions (like record_route(), loose_route(), lookup() and so on) is going to be easier for people to work with?
Or have I misunderstood?
I am not in favour of a new module. Like GRUU, this is just optional behaviour based on the signalling....
/O
On Thu, 2012-08-09 at 16:03 +0200, Olle E. Johansson wrote:
I am not in favour of a new module. Like GRUU, this is just optional behaviour based on the signalling....
My concern is just the amount of complex Kamailio configuration required for something like Outbound. It's likely to be very messy and hard for people to use. But if you think it is practical, I don't have a problem trying it that way.
There are going to be quite a number of (hopefully small) changes to the existing modules (path, registrar, rr, and usrloc at least) anyway.
* The record_route() APIs need to be updated to make the userinfo settable from kamailio.cfg (at least you can already add parameters) * The add_path() APIs need to be updated to let parameters be added (for example ";ob" - at least you can already set the userinfo) * The logic to decide to use outbound for requests from clients should be manageable as a route * The logic to do the routing back to clients, sending the 430 etc, should be manageable as a route * Flow token generation/decode/validation is going to be tricky as new APIs will be needed for at least base64 encode, base64 decode, HMAC-SHA1-80 - and string manipulation in kamailio.cfg is a pain. Perhaps a set of flow-token specific APIs to wrapper all of these things (in one of the utils modules) would be better? * A new API will be required to determine whether a connection exists (based on input of IP address, port, and protocol) - unless trying to send the request and just catching/translating the error to a 430 is OK * I think the new lookup(), lookup_next_dest(), managing the AVPs for this and removing bindings from the location table all do need to be new functions in the registrar module
Have I missed anything in that list?
On Thu, 2012-08-09 at 15:42 +0100, Peter Dunkley wrote:
On Thu, 2012-08-09 at 16:03 +0200, Olle E. Johansson wrote:
I am not in favour of a new module. Like GRUU, this is just optional behaviour based on the signalling....
My concern is just the amount of complex Kamailio configuration required for something like Outbound. It's likely to be very messy and hard for people to use. But if you think it is practical, I don't have a problem trying it that way.
There are going to be quite a number of (hopefully small) changes to the existing modules (path, registrar, rr, and usrloc at least) anyway. * The record_route() APIs need to be updated to make the userinfo settable from kamailio.cfg (at least you can already add parameters) * The add_path() APIs need to be updated to let parameters be added (for example ";ob" - at least you can already set the userinfo) * The logic to decide to use outbound for requests from clients should be manageable as a route * The logic to do the routing back to clients, sending the 430 etc, should be manageable as a route * Flow token generation/decode/validation is going to be tricky as new APIs will be needed for at least base64 encode, base64 decode, HMAC-SHA1-80 - and string manipulation in kamailio.cfg is a pain. Perhaps a set of flow-token specific APIs to wrapper all of these things (in one of the utils modules) would be better? * A new API will be required to determine whether a connection exists (based on input of IP address, port, and protocol) - unless trying to send the request and just catching/translating the error to a 430 is OK * I think the new lookup(), lookup_next_dest(), managing the AVPs for this and removing bindings from the location table all do need to be new functions in the registrar module
Have I missed anything in that list?
Add to the list:
* Advertised address support in Path module
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On Thu, 2012-08-09 at 15:54 +0100, Peter Dunkley wrote:
On Thu, 2012-08-09 at 15:42 +0100, Peter Dunkley wrote:
On Thu, 2012-08-09 at 16:03 +0200, Olle E. Johansson wrote:
I am not in favour of a new module. Like GRUU, this is just optional behaviour based on the signalling....
My concern is just the amount of complex Kamailio configuration required for something like Outbound. It's likely to be very messy and hard for people to use. But if you think it is practical, I don't have a problem trying it that way.
There are going to be quite a number of (hopefully small) changes to the existing modules (path, registrar, rr, and usrloc at least) anyway. * The record_route() APIs need to be updated to make the userinfo settable from kamailio.cfg (at least you can already add parameters) * The add_path() APIs need to be updated to let parameters be added (for example ";ob" - at least you can already set the userinfo) * The logic to decide to use outbound for requests from clients should be manageable as a route * The logic to do the routing back to clients, sending the 430 etc, should be manageable as a route * Flow token generation/decode/validation is going to be tricky as new APIs will be needed for at least base64 encode, base64 decode, HMAC-SHA1-80 - and string manipulation in kamailio.cfg is a pain. Perhaps a set of flow-token specific APIs to wrapper all of these things (in one of the utils modules) would be better? * A new API will be required to determine whether a connection exists (based on input of IP address, port, and protocol) - unless trying to send the request and just catching/translating the error to a 430 is OK * I think the new lookup(), lookup_next_dest(), managing the AVPs for this and removing bindings from the location table all do need to be new functions in the registrar module
Have I missed anything in that list?
Add to the list: * Advertised address support in Path module
And:
* Handle SIP/STUN/keepalive stuff (RFC5626 section 5.4 and section 8) - does Kamailio support anything like this already?
Hello,
On 8/9/12 4:42 PM, Peter Dunkley wrote:
On Thu, 2012-08-09 at 16:03 +0200, Olle E. Johansson wrote:
I am not in favour of a new module. Like GRUU, this is just optional behaviour based on the signalling....
there is no final design yet, I assume, but if there is a need for [persistent] storage, I would not like to get rr or path dependent of db or other type of external storage. If the flow value carries the information needed for routing in the SIP message, then rr/path can be extended. Otherwise I think a new module to take care of storage overhead is recommended, either using internally rr/path or the other modules using it.
The fact is that these modules are used heavily, even in embedded devices, but at the moment outbound is not implemented at large in clients side (ie, few phones sending sip.instance and reg-id). So the 'classic' usage is still the most important for some time.
Cheers, Daniel
My concern is just the amount of complex Kamailio configuration required for something like Outbound. It's likely to be very messy and hard for people to use. But if you think it is practical, I don't have a problem trying it that way.
There are going to be quite a number of (hopefully small) changes to the existing modules (path, registrar, rr, and usrloc at least) anyway.
- The record_route() APIs need to be updated to make the userinfo settable from kamailio.cfg (at least you can already add parameters)
- The add_path() APIs need to be updated to let parameters be added (for example ";ob" - at least you can already set the userinfo)
- The logic to decide to use outbound for requests from clients should be manageable as a route
- The logic to do the routing back to clients, sending the 430 etc, should be manageable as a route
- Flow token generation/decode/validation is going to be tricky as new APIs will be needed for at least base64 encode, base64 decode, HMAC-SHA1-80 - and string manipulation in kamailio.cfg is a pain. Perhaps a set of flow-token specific APIs to wrapper all of these things (in one of the utils modules) would be better?
- A new API will be required to determine whether a connection exists (based on input of IP address, port, and protocol) - unless trying to send the request and just catching/translating the error to a 430 is OK
- I think the new lookup(), lookup_next_dest(), managing the AVPs for this and removing bindings from the location table all do need to be new functions in the registrar module
Have I missed anything in that list?
-- 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
9 aug 2012 kl. 16:42 skrev Peter Dunkley:
On Thu, 2012-08-09 at 16:03 +0200, Olle E. Johansson wrote:
I am not in favour of a new module. Like GRUU, this is just optional behaviour based on the signalling....
My concern is just the amount of complex Kamailio configuration required for something like Outbound. It's likely to be very messy and hard for people to use. But if you think it is practical, I don't have a problem trying it that way.
There are going to be quite a number of (hopefully small) changes to the existing modules (path, registrar, rr, and usrloc at least) anyway. • The record_route() APIs need to be updated to make the userinfo settable from kamailio.cfg (at least you can already add parameters)
If you have a modparam for "outboundsupport" for rr this could be done automatically with the rules Iñaki showed you.
• The add_path() APIs need to be updated to let parameters be added (for example ";ob" - at least you can already set the userinfo)
The same. I think it could be semi-automatic.
• The logic to decide to use outbound for requests from clients should be manageable as a route
"Use outbound for requests from clients" - we get incoming requests on an existing flow. What's there to manage?
• The logic to do the routing back to clients, sending the 430 etc, should be manageable as a route
Do you mean a "new route" - because then I don't follow you.
• Flow token generation/decode/validation is going to be tricky as new APIs will be needed for at least base64 encode, base64 decode, HMAC-SHA1-80 - and string manipulation in kamailio.cfg is a pain. Perhaps a set of flow-token specific APIs to wrapper all of these things (in one of the utils modules) would be better?
Why should the configuration script have to mess with generating a token. If the client indicates outbound support in a request coming in on a new flow with no associated flow token, we can always generate one. I don't see it will ever hurt communication.
• A new API will be required to determine whether a connection exists (based on input of IP address, port, and protocol) - unless trying to send the request and just catching/translating the error to a 430 is OK
COnnection management is the big thing here.
• I think the new lookup(), lookup_next_dest(), managing the AVPs for this and removing bindings from the location table all do need to be new functions in the registrar module
lookup_next_flow() - it's the same destination. I agree that this has to be exposed to the routing script.
One needs to consider various cases: - flow with UDP - flow with TCP - flow with TLS - IPv4 flows - IPv6 flows
A device could have contacts with the same instance ID registred for all of these. That set is then multiplied with the number of edge proxys used.
If the incoming request is IPv6 I might want to select an IPv6-based flow to the device and select that reg-id as the primary one. If incoming is TLS with a SIPS uri I need to select from that criteria.
This selection could be done in the branch route if I don't like the current destination selected. Then if I get a 430 I want to be able to change and retransmit in the failure route.
/O
Have I missed anything in that list?
-- 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
--- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
Peter Dunkley wrote:
On Thu, 2012-08-09 at 10:10 +0200, Martin Hoffmann wrote:
I'd prefer if we could do this through config and only enhance the C APIs where needed. With the new include logics and whatnot, this can come in the form of a config library.
You can do includes but you can't put complex functions with parameters into a config library. So you would end up having to do it as routes with pseudo-variables to pass data around.
Yes. Maybe we can fix that, too? Adding route arguments shouldn't be too hard, if you do it shell style (just a list of arguments, accessible inside the route through PVs $0, $1, etc.).
I think this would be very messy for something as complex as Outbound - and there is always the chance you might use a route-name or variable name that someone else has (making it hard for them to add Outbound support to an existing configuration).
I don't think outbound is all that complex. Pretty much the only change that is really very fundamental is the serial routing lookup for same-instance clients. The rest is pretty much there.
A lot of the business logic for Outbound will be done in the configuration anyway (failure-routes to generate/convert status to 430 and so on) mainly because this is right place for that stuff, but surely a new module that has drop-in replacements for existing functions (like record_route(), loose_route(), lookup() and so on) is going to be easier for people to work with?
Assuming you can't fit outbound into the existing functions (which, I think would only be the case with lookup()), I'd rather have new functions within the existing modules.
Regards, Martin
On Thu, 2012-08-09 at 16:27 +0200, Martin Hoffmann wrote:
Yes. Maybe we can fix that, too? Adding route arguments shouldn't be too hard, if you do it shell style (just a list of arguments, accessible inside the route through PVs $0, $1, etc.).
If someone volunteers to do this I'll happily make use of it.
What I used so far to communicate with sub-routes was passing via local variables, like $var(p1), ...
Cheers, Daniel
On 8/9/12 4:43 PM, Peter Dunkley wrote:
On Thu, 2012-08-09 at 16:27 +0200, Martin Hoffmann wrote:
Yes. Maybe we can fix that, too? Adding route arguments shouldn't be too hard, if you do it shell style (just a list of arguments, accessible inside the route through PVs $0, $1, etc.).
If someone volunteers to do this I'll happily make use of it.
-- 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
On 8/9/12 4:59 PM, Daniel-Constantin Mierla wrote:
What I used so far to communicate with sub-routes was passing via local variables, like $var(p1), ...
but of course, contributions to get route block parameters will be accepted.
Cheers, Daniel
On 8/9/12 4:43 PM, Peter Dunkley wrote:
On Thu, 2012-08-09 at 16:27 +0200, Martin Hoffmann wrote:
Yes. Maybe we can fix that, too? Adding route arguments shouldn't be too hard, if you do it shell style (just a list of arguments, accessible inside the route through PVs $0, $1, etc.).
If someone volunteers to do this I'll happily make use of it.
-- 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
-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
2012/8/9 Martin Hoffmann martin.hoffmann@telio.ch:
I'd like to see the flow-token mechanism replace the current received mechanism.
Hi, I've captured a real flow of a SIP registration via an Outbound Edge Proxy (by forcing Outbound usage since the client, Twinkle, does not implement it):
https://gist.github.com/3517204
Other flows that could be useful here:
http://tools.ietf.org/html/draft-ietf-sipcore-sip-websocket-02#section-8
Hi, sorry for the very late response, please let me some comments inline:
EDGE server
- Path
- Existing Path module does (most of) what is required when called for
REGISTER requests
It MUST add ;ob param to the Path URI.
- Received parameters are not needed on Path: headers because we will
use Outbound flow tokens now
- Outbound
- Need to generate/add flow token and ;ob parameter to the
Path/Record-Route headers when: # It's an initial request (out-of-dialog INVITE, REGISTER, SUBSCRIBE, or REFER), with # A single Via:, and # Top Route: points to us and has ;ob parameter or Contact: has ;ob parameter or it's a REGISTER with ;+sip.instance, or # force_outbound() API has been called
My fault: it is not the ;+sip.instance parameter but ;reg-id parameter in the Contact header.
BTW: The EDGE proxy must not add ;ob to the top Route since it should determine that a future incoming in-dialog request must be routed through an Outbound connection if such a top Route (or second Route if there is double RR) has a URI username which identifies the Outbound flow token.
- Need to maintain mapping of flow tokens to connections (flow token
to/from source address and port)
- Need an Outbound routing API (related to loose_route()) that sets $du
correctly based on flow token in Route: header (R-URI no longer used)
- If the flow token doesn't match a connection send 430 response
(response sending in kamailio.cfg, but Outbound routing API needs to return an appropriate error to support this)
Registrar
- Path
- Path already supported in usrloc
- Outbound
- instance and reg IDs already stored in usrloc
- multiple registrations with the same instance ID but different reg IDs
must be supported (may be already)
- Parallel and serial forking behaviour must be preserved, when forking
branch to each unique instance ID not reg ID.
- Need a new/improved lookup() API that returns the location for the
best reg ID and populates an AVP with the other instance IDs in order they should be tried
- On receipt of 430 response to a request the failed location should be
removed from the usrloc table and the next location (from the AVP) tried. Similar to the way dispatcher works.
Single server
- Path
- Use this to add single (local) Path header - just needed to get the
Outbound flow token into the usrloc table
- Received parameters are not needed on Path: headers because we will
use Outbound flow tokens now
- Outbound
- Similar to the combined behaviour of EDGE server and Registrar, but
because the mapping of flow token to connection is local there is no need for the 430 response stuff - can just loop through the list of matching connections locally until a good one is found.
... and remove any registration binding if the request could not be sent (503, 408...).
Note: Double-Path and advertised address...
- Talking to one of my colleagues he thought that double-Path headers
wouldn't be required. Double-RR is used to make sure the route-set is good in both directions when there are transport/network changes. Because Path is just used in the one direction this shouldn't be required. Does this make sense?
Right. In this case the EDGE proxy would add a single Path header whose URI points to the interface in which it wants to receive future requests from the registrar, and such a Path URI should, of course, contain the outbound flow token (URI username) and the URI ;ob param.
- Because the Path header needs to show the address of the outbound
interface it should use the advertised address for that interface, not the listening address of the interface. Is this correct?
mmm, the interface in which it wants to receive future requests from the registrar, right?
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Martin Hoffmann -
Olle E. Johansson -
Peter Dunkley