6 dec 2012 kl. 11:44 skrev Peter Dunkley peter.dunkley@crocodile-rcs.com:

Hi Olle,

I haven't had any time for the last few months to work on outbound. So there is some module boiler plate and a set of notes (attached) at the moment and not much more.

I have a requirement for outbound myself for early next year, so will be picking it up again soon, but there is little to no chance of it making it into Kamailio 3.4.

One thing that would speed up the development of outbound is if someone else (who knows about the internals of the registrar and usrloc modules) took on the tasks relating to those. These are basically: Handle multiple registrations with same instance ID but difference reg-id (may already be supported)

It needs to be handled properly in parallell and serial forking, which I have not seen. May have missed it though.

Have registrar populate an AVP array (specified as a modparam), ordered by reg-id, when a lookup() is performed - similar to dispatcher (but don't break parallel and serial forking) - set $du to first contact in the AVP array.

Right.

New API (lookup_next_dest()) in registrar that allow you to work through the set in order if a 430 is returned (API needs to remove failed contacts from the location table) - again, similar to dispatcher And for being able to use outbound for NAT traversal on a single server (so no Edge proxies): Make registrar able to detect that the top Path-URI for the contact is actually an interface on the local server, and if it has an ;ob parameter and a flow token, set $du based on that.

This would allow me to focus on the Edge server behaviour, which involves changes to path, rr, a new outbound module, and some configuration examples (for edge and proxy/registrar).

And new response codes.

I do long for an eventroute for broken TCP connections from clients.

Thanks for the feedback. I guess we have to visit Berlin and feed an unspecified group of developers with Bratwurst and Beer to get some help here... :-)

/O

Regards,

Peter

On Thu, 2012-12-06 at 09:43 +0100, Olle E. Johansson wrote:

...

Peter,

What's the current status of the outbound support? Which branch is it?

Can we do anything to help to get this into the coming release?

/O

---

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 <outbound_design.txt>_______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

Peter Dunkley writes:

Not sure how this would help with outbound as the proxy/registrar and edge server (with the client connections) will be separate anyway?

i would like to see support also for the case where there is only a single server that combines edge proxy and registrar. if i remember correctly, this was also in your original requirements list.

-- juha

Hello,

On 12/6/12 11:44 AM, Peter Dunkley wrote:

Hi Olle,

I haven't had any time for the last few months to work on outbound. So there is some module boiler plate and a set of notes (attached) at the moment and not much more.

I have a requirement for outbound myself for early next year, so will be picking it up again soon, but there is little to no chance of it making it into Kamailio 3.4.

One thing that would speed up the development of outbound is if someone else (who knows about the internals of the registrar and usrloc modules) took on the tasks relating to those. These are basically:

• Handle multiple registrations with same instance ID but difference reg-id (may already be supported)

this should be supported, there is no unique key on instance only and reg-id is saved -- in the worst case, the required changes are very small.

• Have registrar populate an AVP array (specified as a modparam), ordered by reg-id, when a lookup() is performed - similar to dispatcher (but don't break parallel and serial forking) - set $du to first contact in the AVP array.

This one can be also easily added, we have t_load_contacts() which serializes the contact records based on Q value. It has to be extended to work on reg-id:

http://kamailio.org/docs/modules/stable/modules/tm.html#id2550968

• New API (lookup_next_dest()) in registrar that allow you to work through the set in order if a 430 is returned (API needs to remove failed contacts from the location table) - again, similar to dispatcher

There is t_next_contacts(), working on the set of avps built by t_load_contacts() -- again, it need some enhancements, but probably not hard work.

Perhaps I can help on the above points, even do them myself, but I can't give any timelines for the moment.

And for being able to use outbound for NAT traversal on a single server (so no Edge proxies):

• Make registrar able to detect that the top Path-URI for the contact is actually an interface on the local server, and if it has an ;ob parameter and a flow token, set $du based on that.

Address in firth path will be used to set $du anyhow, not sure what the flow token implies, but might be just done from config.

Cheers, Daniel

This would allow me to focus on the Edge server behaviour, which involves changes to path, rr, a new outbound module, and some configuration examples (for edge and proxy/registrar).

Regards,

Peter

On Thu, 2012-12-06 at 09:43 +0100, Olle E. Johansson wrote:

...

Peter,

What's the current status of the outbound support? Which branch is it?

Can we do anything to help to get this into the coming release?

/O

---

sr-dev mailing list sr-dev@lists.sip-router.org mailto: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

On 12/6/12 1:35 PM, Juha Heinanen wrote:

Daniel-Constantin Mierla writes:

...

This one can be also easily added, we have t_load_contacts() which serializes the contact records based on Q value. It has to be extended to work on reg-id:

since i have implemented t_load_contacts()/t_next_contacts(), perhaps i can help here. tell me what kind of extension is needed and i'll try to implement it.

that would be great!

I haven't studied exactly the algorithm, but from what I understood, the contacts have to be sorted also by reg-id. What is not clear yet for me is if Q values still plays a role.

First, it will require to propagate sip-instance and reg-id fields to destination set (via branch_t structure) from usrloc/registrar -- just adding some fields and copy the values as we do for example for path and q.

If Q has to be taken in consideration, I would guess that the list of contacts will be grouped by sip-instance value, those groups will be ordered by Q (like taking the highest q in the group and comparing with the other groups). Inside the group, the order will be set by reg-id.

Selection of next destinations to try will be done by taking the first within a group with same instance (perhaps doing parallel forking if there are groups with same Q). If it is a failure, then will go and take the next contacts in the groups (based on reg-id value).

Again, the part related to Q has to be clarified. Otherwise should be about grouping on sip-instance and ordering by reg-id (lower reg-id is first to use).

Thinking of these attributes, might be easier to work with xavps instead of classic avps.

Cheers, Daniel

6 dec 2012 kl. 14:01 skrev Juha Heinanen jh@tutpro.com:

Daniel-Constantin Mierla writes:

...

I haven't studied exactly the algorithm, but from what I understood, the contacts have to be sorted also by reg-id. What is not clear yet for me is if Q values still plays a role.

i was wondering that too. what is the relationship between q and reg-id?

This is how I parse it - which may or may not be wrong :-)

One registered device has TWO registrations that I belive should have the same Q.

So first sort contacts so that you have them grouped by contact and for the pairs with one or multiple reg-ids and the same instance, treat them as one contact when handling serial forking with Q values. One contact may have an inactive state, since the flow is down. In that case, select the next contact with the same instance id but a different reg-id.

We should always only use one contact in the set of contacts for one instance with different regid's.

...

First, it will require to propagate sip-instance and reg-id fields to destination set (via branch_t structure) from usrloc/registrar -- just adding some fields and copy the values as we do for example for path and q.

what if sip-instance is missing, but reg-id is present like in this register request from barasip?

REGISTER sip:test.fi SIP/2.0. Via: SIP/2.0/TCP 192.98.102.10:5050;branch=z9hG4bKe8fc3b4174d10554;rport. Contact: sip:0x8bac4f0@192.98.102.10:5050;transport=tcp;expires=600;q=0.8;reg-id=1. Max-Forwards: 70. Route: sip:192.98.102.10;transport=tcp;lr. To: sip:test@test.fi. From: sip:test@test.fi;tag=a41662ae8ebfb044. Call-ID: 72e7f927a4be41a2. CSeq: 33968 REGISTER. User-Agent: baresip v0.4.2 (i586/linux). Supported: outbound, path. Content-Length: 0.

or is it a bug in baresip?

Yes, that's clearly a bug. Outbound relies on the instance ID that identifies the device.

/O

-- juha

---

sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

6 dec 2012 kl. 15:24 skrev Juha Heinanen jh@tutpro.com:

Olle E. Johansson writes:

One registered device has TWO registrations that I belive should have the same Q.

where is that specified? outbound rfc does not have a single word about q.

We've discussed this for a long time during the last SIPit. You guys should come too :-)

You are right though. It must be an oversight. Treat my statements as my personal implementation guidelines, nothing more. We should propably take this to the sip-implementors list.

also, there is no mention that reg-id value has anything to do with the order in which the contacts are tried. rfc says,

When a proxy uses the location service to look up a registration binding and then proxies a request to a particular contact, it selects a contact to use normally, with a few additional rules:

"normally" to me means ordered by q value. first additional rule places a clear restriction:

o The proxy MUST NOT populate the target set with more than one contact with the same AOR and instance-id at a time.

Exactly.

the next one is not clear to me:

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.

what if this another target has lower q than some other target?

Again, it seems like the authors assumed that a UA sends the SAME register contact across two different paths. It doesn't say so. It doesn't tell the registrar what to do if the contact uri and uri parameters are different for the two registrations from the same device.

I don't really see any case where that happens. YOu normally configure a device to register with this service using this q value. Finding the edge servers and registering with them is done using DNS or provisioning and there's no separate configuration per edge proxy. So the Q value will in most cases be the same. But never say never :-)

/O

-- juha

---

sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

7 dec 2012 kl. 00:08 skrev Juha Heinanen jh@tutpro.com:

after sleeping on it, i propose the following simple implementation of instance-id/reg-id aware load_contacts()/next_contacts():

• load_contacts() does the same as it currently does, i.e., load

contacts to an avp and orders them based on q value.

• next_contacts() creates destination set that includes highest q value

contacts, but if there is two contacts with same instance-id, only one of them is included. next_contacts() also stores the current q value in an avp.

• in failure route, if response code is 408 or 430, a new function

next_contacts_skip() is called that works as described above, but skips next contacts with the stored q value (if any). otherwise, next_contacts() is called.

is this acceptable to everyone? feel welcome to propose a better name for next_contacts_skip().

next_contact_flow()

#If we have no spare flow for current contact, go to next q level. if (!next_contact_flow()) next_contacts();

/O

regarding missing +sip.instance contact param in baresip, it was my bad. i had a patched baresip that added q instead of +sip.instance.

-- juha

my bogus register request was without +sip.instance, but with reg-id. in such a case, reg-id should be ignored:

A Contact header field value with an instance-id media feature tag but no "reg-id" header field parameter is valid (this combination will result in the creation of a GRUU, as described in the GRUU specification [RFC5627]), but one with a reg-id but no instance-id is not valid. If the registrar processes a Contact header field value with a reg-id but no instance-id, it simply ignores the reg-id parameter.

that didn't happen. the result was that location record had NULL in instance field and 1 in reg-id field.

it would simplify contact handling if in the above case both fields would be null.

what is the rational that if there is no reg-id field, then location table has reg-id value 0 instead of null?

-- juha

Olle E. Johansson writes:

One could say "contact group" or "device" or something else. The entity has a q value and should be treated as the old "Contact".

show me an rfc that says that all registrations of this "entity" has to share the same q value.

-- juha

Daniel-Constantin Mierla writes:

First, it will require to propagate sip-instance and reg-id fields to destination set (via branch_t structure) from usrloc/registrar -- just adding some fields and copy the values as we do for example for path and q.

looks like this also means two new arguments to dset.h append_branch, next_branch and get_branch functions, right?

-- juha

Daniel-Constantin Mierla writes:

yes. Or, for getting the branch, if they become with too many parameters, then use the function that returns the pointer to the branch structure.

if we do that, then for consistency, get_branch and next_branch should be dropped altogether and replaced by get_sip_branch (which already exists) and get_next_sip_branch (which would be new).

i can do that if people feel that it is ok.

-- juha

6 dec 2012 kl. 15:59 skrev Peter Dunkley peter.dunkley@crocodile-rcs.com:

On Thu, 2012-12-06 at 13:20 +0100, Daniel-Constantin Mierla wrote:

...

Address in firth path will be used to set $du anyhow, not sure what the flow token implies, but might be just done from config.

The flow token is the user part of the Path-URI and is an encrypted string that indicates the source IP address, port, and protocol of the REGISTER request. So for NAT traversal purposes you want to send to the place the flow token indicates, not what is actually in the host part of the Path-URI (but only if the Path-URI has an ;ob parameter). The idea is that even on a single server system with clients that do not support outbound it should be possible to "force outbound" so as to get this into the location table.

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.

Basically, when using outbound like this, the aliasing stuff in nathelper and the received AVP/parameter/column in registrar and usrloc are obsoleted.

The useful parts remaining in nathelper will be nat_uac_test() and nat pinging. Although, for outbound capable clients nat pinging on the server is not needed as the clients will send STUN requests to the SIP server anyway. This means the when outbound support is complete, STUN should be enabled by default on the Kamailio builds.

Yep.

Have sent e-mail to sip-implementors on the Q issue. It seems to me that Juha is right, it must be a mistake.

/O

Regards,

Peter

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

6 dec 2012 kl. 16:23 skrev Peter Dunkley peter.dunkley@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

6 dec 2012 kl. 13:44 skrev Alex Balashov abalashov@evaristesys.com:

On 12/06/2012 03:43 AM, Olle E. Johansson wrote:

...

Can we do anything to help to get this into the coming release?

Who, precisely, is "we"?

I included you and everyone else on the sr-dev mailing list. And we already have a few developers stepping forward.

/O