6 Dec
2012
6 Dec
'12
3:43 a.m.
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
6 Dec
6 Dec
5:44 a.m.
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)
* 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.
* 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).
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
5:57 a.m.
6 dec 2012 kl. 11:44 skrev Peter Dunkley <peter.dunkley(a)crocodile-rcs.com>om>:
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
6:06 a.m.
On Thu, 2012-12-06 at 11:57 +0100, Olle E. Johansson wrote:
My point exactly. I have no experience with the registrar and usrloc
modules, and the outbound development breaks neatly into two parts:
* Edge server (rr, path, outbound)
* Proxy/registrar (registrar, usrloc)
I will eventually do all of it, but if it is needed sooner then getting
someone else to do the proxy/registrar part would help.
All of the checking/handling of the new response codes will be in
failure_routes. So I don't think there is really any work required
here.
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.
Not sure how this would help with outbound as the proxy/registrar and
edge server (with the client connections) will be separate anyway?
I think that between checking the return code from t_relay() and a
failure_route on the edge proxy you will catch all of these problems and
be able to generate the 430 response.
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... :-)
If I had time to visit Berlin I'd have more time to spend on outbound in
the first place :-)
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
6:35 a.m.
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
6:38 a.m.
Hi Juha,
This is already covered in my earlier email from today:
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.
Similar to with the edge server, catching the return code from t_relay()
and the failure_route should do all that is needed.
Regards,
Peter
On Thu, 2012-12-06 at 13:35 +0200, Juha Heinanen wrote:
Peter Dunkley writes:
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
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
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev 
7:20 a.m.
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:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
7:35 a.m.
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.
-- juha
7:53 a.m.
On 12/6/12 1:35 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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.
8:01 a.m.
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?
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?
-- juha
9:07 a.m.
6 dec 2012 kl. 14:01 skrev Juha Heinanen <jh(a)tutpro.com>om>:
Yes, that's clearly a bug. Outbound relies on the
instance ID that identifies the device.
/O
Daniel-Constantin Mierla writes:
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.
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? 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?
-- juha
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
9:24 a.m.
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.
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.
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?
-- juha
9:55 a.m.
6 dec 2012 kl. 15:24 skrev Juha Heinanen <jh(a)tutpro.com>om>:
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
6:08 p.m.
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().
-- juha
8 Dec
8 Dec
3:35 a.m.
7 dec 2012 kl. 00:08 skrev Juha Heinanen <jh(a)tutpro.com>om>:
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
3:58 a.m.
Olle E. Johansson writes:
there may be more than one flow left to try because more than one ua may
have registered the same aor, so better name would be
next_contact_flows.
-- juha
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();
6 Dec
6 Dec
8:29 a.m.
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
8:50 a.m.
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 googled a bit and looks like relationship between q value
sip.instance/reg ids is a mess. more mess comes from so called
permanent registrations (for example a voicemail server registration at
lower q value) that may or may not have sip.instance/reg-ids.
-- juha
9:06 a.m.
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
9:12 a.m.
6 dec 2012 kl. 14:50 skrev Juha Heinanen <jh(a)tutpro.com>om>:
Daniel-Constantin Mierla writes:
Before outbound a contact was a contact. Now we have to start discussing
devices as we have a device identifier. A device can be identified by one
contact - with or without sip.instance and reg-id - or multiple contacts
that share the same sip.instance but have different reg-id's.
One could say "contact group" or "device" or something else. The
entity
has a q value and should be treated as the old "Contact".
/O
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 googled a bit and looks like relationship between q value
sip.instance/reg ids is a mess. more mess comes from so called
permanent registrations (for example a voicemail server registration at
lower q value) that may or may not have sip.instance/reg-ids.
9:56 a.m.
6 dec 2012 kl. 15:27 skrev Juha Heinanen <jh(a)tutpro.com>om>:
Olle E. Johansson writes:
It doesn't say that the URI, nor the URI parameters has to be the same.
Seems to be a mistake, as I said in the earlier mail.
Good catch.
/O
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.
7 Dec
7 Dec
10:18 p.m.
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
8 Dec
8 Dec
3:30 a.m.
On 12/8/12 4:18 AM, Juha Heinanen wrote:
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.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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?
4:04 a.m.
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
6 Dec
9:59 a.m.
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.
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.
Regards,
Peter
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
10:06 a.m.
6 dec 2012 kl. 15:59 skrev Peter Dunkley <peter.dunkley(a)crocodile-rcs.com>om>:
On Thu, 2012-12-06 at 13:20 +0100, Daniel-Constantin
Mierla 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.
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.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
10:23 a.m.
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 :-)
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
10:48 a.m.
6 dec 2012 kl. 16:23 skrev Peter Dunkley <peter.dunkley(a)crocodile-rcs.com>om>:
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
7:44 a.m.
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"?
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
9:02 a.m.
6 dec 2012 kl. 13:44 skrev Alex Balashov <abalashov(a)evaristesys.com>om>:
On 12/06/2012 03:43 AM, Olle E. Johansson wrote:
I included you and everyone else on the sr-dev mailing list. And we already have a few
developers
stepping forward.
/O
Can we do anything to help to get this into the
coming release?
Who, precisely, is "we"?
4218
days inactive
4220
days old
30 comments
5 participants
participants (5)
-
Alex Balashov -
Daniel-Constantin Mierla -
Juha Heinanen -
Olle E. Johansson -
Peter Dunkley