[sr-dev] Status of outbound support

[Olle E. Johansson]

6 dec 2012 kl. 16:23 skrev Peter Dunkley <peter.dunkley at crocodile-rcs.com>:

> On Thu, 2012-12-06 at 16:06 +0100, Olle E. Johansson wrote:
> 
>>> 
>> The flow token points to a flow saying that Kamailio should NOT parse the Contact URI and find a destination. It should find the proper connection.
>> 
> In the specific case of a single server (no edge proxies) the flow token will indicate exactly what the source of the REGISTER was (assuming the example algorithm from section 5.2 of RFC 5626 is used) - which may have no connection because it could have arrived over UDP.  Assuming that any binding within the NAT in-front of the client is still live this allows us to route back to client without any of the contact aliasing/received stuff.  In actual fact, the information in the flow token should allow both $du to be correctly set and force_send_socket() to be called correctly.
> 
>       Example Algorithm: When the proxy boots, it selects a 20-octet
>       crypto random key called K that only the edge proxy knows.  A byte
>       array, called S, is formed that contains the following information
>       about the flow the request was received on: an enumeration
>       indicating the protocol, the local IP address and port, the remote
>       IP address and port.  The HMAC of S is computed using the key K
>       and the HMAC-SHA1-80 algorithm, as defined in [RFC2104].  The
>       concatenation of the HMAC and S are base64 encoded, as defined in
>       [RFC4648], and used as the flow identifier.  When using IPv4
>       addresses, this will result in a 32-octet identifier. 
> However, this strikes me as something that does need to be handled within C code when setting the destination because as sophisticated as Kamailio configuration can be, performing base64 decoding followed by HMAC-SHA1-80 followed by complex string parsing may be a bit too much <face-smile.png>

Right. I should have used "flow" instead of connection, as outbound support connectionless flows :-)

I agree that that algorithm may not be simple to implement in the routing language...

/O