8 Oct
2011
8 Oct
'11
4:14 p.m.
Hi, Internet is changing and now devices which are sporadically
connected (TCP) are very common. I mean, of course, movile devices.
RFC 5626 (AKA "Outbound) is the solution for those scenarios under SIP
protocol. Features of RFC 5626:
- NAT solved (at signaling level) without hacks in the proxy side (no
more "Contact" replacements, please).
- Allow re-registration of a client (after loosing the TCP connection)
by indicating the registrar to replace the previous binding with the
new one (for this, a Contact param ";+sip.instance" and ";reg-id" are
used). Avoid mantaining dozens of unreachable registration bindings in
the registrar.
- RFC 5626 is for clients, outbound proxies ("edge proxies") and
registrars (which could be behind the edge(s) proxy). Path support is
required in both the edge proxy and registrar (already implemented in
Kamailio!).
- If the registrar tries to route a request to a client registered
using RFC 5626 and it gets a connection error or timeout, the
registrar MUST remove such binding.
- If the registrar tries to route a request to a client registered
though an outbound/edge proxy and receives a "430 Flow Failed", the
registrar MUST remove such binding.
- The client could mantain two different registrations (by using two
separate edge proxies that route the REGISTER to the same registrar
behind them). Both registration have the same ";+sip.instance" value
but different ";reg-id" value. When the registrar (or inbound proxy)
has to route a request to that AoR, and in case there are various
bindings with same ";+sip.instance", it just tries the one with lowest
";reg-id" value. If it fails (430 "Flow Failed" replied by the edge
proxy) it would try the next one. Yeah, failover for incoming calls, a
cool and *needed* feature now.
- When a UAC sends a REGISTER announcing support for RFC 5626
("Supported: outbound"), the binding matching changes: Now the
registrar must check for other bindings with same ";+sip.instance"
rather than matching the Contact URI (which is useless as the client
is supposed to be natted).
Some other collateral changes needed for the above to work properly:
- 430 status code MUST have less priority than any other 4XX response
since such 430 response can only be replied by edge proxies and means
"the TCP/TLS connection with the user is closed".
- We need two new fields in the registration backend for storing the
";+sip.instance" and ";reg-id" param.
- When a TCP connection is made from a client, Kamailio has to create
a flow token identifier for such connection.
- We need a new "loose_route_outbound()" function that adds a
Record-Route whose URI username matches the flow token associated to
the connection from which the request comes.
- When a request arrives to Kamailio and contains a Route header
pointing to us and containing a Route with username, then Kamailio
must inspect the URI username to know which connection to use for
routing such request (don't trust the RURI as it would be the private
URI of a Contact header). Don't mangle the Contact header please, no
more request/response mangling.
- Summarizing, RFC 5626 requires additions to:
- registrar module
- location module
- rr module
So, RFC 5626 is the solution for lot of common problems today and IMHO
it's a good specification. Many devices are already implementing them.
Let's forget the "Contact mangling" hacks and other not-so-ellegant
solutions already present in Kamailio/SIP-Router for this purpose. RFC
5626 was published in October 2009, it's not a new and exotic
specification.
Is there interest in implementing this? I know the specification and could help.
Cheers.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
9:37 a.m.
On 10/9/11 8:14 AM, Juha Heinanen wrote:
Iñaki Baz Castillo writes:
I know a good one that I can warmly recommend :)
http://www.creytiv.com/baresip.html
I added outbound support to baresip exactly for this reason; the method
is standardized by IETF and we as responsible open source people should
try to stick to standards and avoid too many non-interoperable hacks.
it is also tested against Sip-Router and many features are working, like
TCP/UDP ping keepalive, sip-instance and Flow-Timer ..
/alfred
So, RFC 5626 is the solution for lot of common
problems today and IMHO
it's a good specification. Many devices are already implementing them.
inaki,
can you name one, preferably such that runs on linux?
10:06 a.m.
Alfred E. Heggestad writes:
I know a good one that I can warmly recommend :)
http://www.creytiv.com/baresip.html
i have been trialing with baresip myself too and like it a lot. i
didn't know that it has support for outbound, since it does not include
Supported: gruu in its register message.
on the other hand, baresip doesn't indicate in its invite support for
session timer and it does not support presence.
-- juha
10 Oct
10 Oct
4:29 p.m.
On 10/9/11 4:06 PM, Juha Heinanen wrote:
Alfred E. Heggestad writes:
if the ;outbound=x parameter is given, SIP outbound is enabled and it
should include Supported: outbound.
what is the relationship between gruu and outbound ? GRUU (RFC 5627)
has a normative reference to Outbound (RFC 5626), probably because of
+sip.instance. Outbound has an informative reference to GRUU spec.
http://tools.ietf.org/html/rfc5627#section-13.1
/alfred
I know a good one that I can warmly recommend :)
http://www.creytiv.com/baresip.html
i have been trialing with baresip myself too and like it a lot. i
didn't know that it has support for outbound, since it does not include
Supported: gruu in its register message.
4:36 p.m.
2011/10/10 Alfred E. Heggestad <aeh(a)db.org>rg>:
what is the relationship between gruu and outbound ?
GRUU (RFC 5627)
has a normative reference to Outbound (RFC 5626), probably because of
+sip.instance. Outbound has an informative reference to GRUU spec.
IMHO Outbound is a real need (since NAT and TCP clients do exist),
while GRUU is a cool feature, but not a requirement for the core
protocol.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
5:09 p.m.
Hello all,
there is some implementation towards these extensions done by SER folks
in the past (quite some long time ago, when gruu was a draft), some
notes in the readme:
http://kamailio.org/docs/modules/stable/modules_s/registrar.html#sip.instan…
Now, I don't how much the specs in the draft were changed by the time of
becoming rfc (I haven't read neither these drafts nor rfcs). The
inconvenience is that we have two implementations for usrloc/registrar
at this moment, but for next release (i mean 3.3) could be a nice task
and pleasant work for the volunteers here to merge the two
implementations and update with outbound/gruu. Just announce it when the
works starts so there is no duplicated effort :-)
To answer to the initial question, this rfc (in the subject) is not in
my todo, but that may change before 3.3 (decision to be made when I have
time to read the rfcs and can assert properly usability), although I
hope it will not be the case to code it myself because someone else will
do it...
Cheers,
Daniel
On 10/10/11 10:36 PM, Iñaki Baz Castillo wrote:
2011/10/10 Alfred E. Heggestad<aeh(a)db.org>rg>:
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
what is the relationship between gruu and
outbound ? GRUU (RFC 5627)
has a normative reference to Outbound (RFC 5626), probably because of
+sip.instance. Outbound has an informative reference to GRUU spec.
IMHO Outbound
is a real need (since NAT and TCP clients do exist),
while GRUU is a cool feature, but not a requirement for the core
protocol.
5:20 p.m.
2011/10/10 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Now, I don't how much the specs in the draft were
changed by the time of
becoming rfc (I haven't read neither these drafts nor rfcs). The
inconvenience is that we have two implementations for usrloc/registrar at
this moment, but for next release (i mean 3.3) could be a nice task and
pleasant work for the volunteers here to merge the two implementations and
update with outbound/gruu. Just announce it when the works starts so there
is no duplicated effort :-)
Complete agreed.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
9 Oct
9 Oct
6:23 p.m.
2011/10/9 Juha Heinanen <jh(a)tutpro.com>om>:
Iñaki Baz Castillo writes:
PJSIP implements RFC 5626 since December 2010:
http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2010-December/012225…
I hope Blink (and maybe other softphones running on Linux) would upgrade soon.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
So, RFC 5626 is the solution for lot of common
problems today and IMHO
it's a good specification. Many devices are already implementing them.
inaki,
can you name one, preferably such that runs on linux? 
10 Oct
10 Oct
4:15 a.m.
RFC 5626 support is currently being added to the JAIN SIP stack, which
is the basis for many Java SIP products including Mobicents (and Jitsi I
believe?). So we should see it appearing in derived products in the near
future.
Andy Miller
Crocodile RCS Ltd.
On 09/10/2011 23:23, Iñaki Baz Castillo wrote:
2011/10/9 Juha Heinanen<jh(a)tutpro.com>om>:
Iñaki Baz Castillo writes:
PJSIP implements RFC 5626
since December 2010:
http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2010-December/012225…
I hope Blink (and maybe other softphones running on Linux) would upgrade soon.
So, RFC 5626 is the solution for lot of common
problems today and IMHO
it's a good specification. Many devices are already implementing them.
inaki,
can you name one, preferably such that runs on linux? 
4:24 a.m.
10 okt 2011 kl. 10:15 skrev Andrew Miller:
RFC 5626 support is currently being added to the JAIN
SIP stack, which is the basis for many Java SIP products including Mobicents (and Jitsi I
believe?). So we should see it appearing in derived products in the near future.
Andy Miller
Crocodile RCS Ltd.
On 09/10/2011 23:23, Iñaki Baz Castillo wrote:
> 2011/10/9 Juha Heinanen<jh(a)tutpro.com>om>:
>> Iñaki Baz Castillo writes:
>>
>>> So, RFC 5626 is the solution for lot of common problems today and IMHO
>>> it's a good specification. Many devices are already implementing them.
>> inaki,
>>
>> can you name one, preferably such that runs on linux?
> PJSIP implements RFC 5626 since December 2010:
>
> http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2010-December/012225…
>
> I hope Blink (and maybe other softphones running on Linux) would upgrade soon.
>
This is good news! Now guys, they need a server!
/O
9 Oct
9 Oct
4:21 a.m.
8 okt 2011 kl. 22:14 skrev Iñaki Baz Castillo:
Hi, Internet is changing and now devices which are
sporadically
connected (TCP) are very common. I mean, of course, movile devices.
RFC 5626 (AKA "Outbound) is the solution for those scenarios under SIP
protocol. Features of RFC 5626:
- NAT solved (at signaling level) without hacks in the proxy side (no
more "Contact" replacements, please).
- Allow re-registration of a client (after loosing the TCP connection)
by indicating the registrar to replace the previous binding with the
new one (for this, a Contact param ";+sip.instance" and ";reg-id"
are
used). Avoid mantaining dozens of unreachable registration bindings in
the registrar.
- RFC 5626 is for clients, outbound proxies ("edge proxies") and
registrars (which could be behind the edge(s) proxy). Path support is
required in both the edge proxy and registrar (already implemented in
Kamailio!).
- If the registrar tries to route a request to a client registered
using RFC 5626 and it gets a connection error or timeout, the
registrar MUST remove such binding.
- If the registrar tries to route a request to a client registered
though an outbound/edge proxy and receives a "430 Flow Failed", the
registrar MUST remove such binding.
- The client could mantain two different registrations (by using two
separate edge proxies that route the REGISTER to the same registrar
behind them). Both registration have the same ";+sip.instance" value
but different ";reg-id" value. When the registrar (or inbound proxy)
has to route a request to that AoR, and in case there are various
bindings with same ";+sip.instance", it just tries the one with lowest
";reg-id" value. If it fails (430 "Flow Failed" replied by the edge
proxy) it would try the next one. Yeah, failover for incoming calls, a
cool and *needed* feature now.
- When a UAC sends a REGISTER announcing support for RFC 5626
("Supported: outbound"), the binding matching changes: Now the
registrar must check for other bindings with same ";+sip.instance"
rather than matching the Contact URI (which is useless as the client
is supposed to be natted).
Some other collateral changes needed for the above to work properly:
- 430 status code MUST have less priority than any other 4XX response
since such 430 response can only be replied by edge proxies and means
"the TCP/TLS connection with the user is closed".
- We need two new fields in the registration backend for storing the
";+sip.instance" and ";reg-id" param.
- When a TCP connection is made from a client, Kamailio has to create
a flow token identifier for such connection.
- We need a new "loose_route_outbound()" function that adds a
Record-Route whose URI username matches the flow token associated to
the connection from which the request comes.
- When a request arrives to Kamailio and contains a Route header
pointing to us and containing a Route with username, then Kamailio
must inspect the URI username to know which connection to use for
routing such request (don't trust the RURI as it would be the private
URI of a Contact header). Don't mangle the Contact header please, no
more request/response mangling.
- Summarizing, RFC 5626 requires additions to:
- registrar module
- location module
- rr module
So, RFC 5626 is the solution for lot of common problems today and IMHO
it's a good specification. Many devices are already implementing them.
Let's forget the "Contact mangling" hacks and other not-so-ellegant
solutions already present in Kamailio/SIP-Router for this purpose. RFC
5626 was published in October 2009, it's not a new and exotic
specification.
Is there interest in implementing this? I know the specification and could help.
I agree that SIP outbound solves a lot of issues with NAT and many other things that
we've been fighting
with when building SIP solutions on the Internet, outside of private networks.
Today, I think SIP outbound suffers from a chicken-and-egg issue. Since neither Asterisk
nor
Kamailio has implemented it, developers has no available reference implementation.
Open Source has a role to play as reference implementations, available for everyone.
If we start, the customers will require devices to develop this support.
SIP Outbound is intertwined with GRUU. Both of them are part of the GIN PBX registration
for multiple phone numbers that is a basis for SIP Forum's SIPconnect.
I do hope we can find interest in this and get funding to complete SIP outbound in
SIP-router.
/O
10 Oct
10 Oct
7:38 a.m.
On Saturday 08 October 2011, Iñaki Baz Castillo wrote:
[RFC 5826]
Hi Inaki,
sounds really interesting, thanks for bringing this up here.
Some other collateral changes needed for the above to
work properly:
- 430 status code MUST have less priority than any other 4XX response
since such 430 response can only be replied by edge proxies and means
"the TCP/TLS connection with the user is closed".
What about the 439 code, i guess we need support in the server for this as
well?
- We need two new fields in the registration backend
for storing the
";+sip.instance" and ";reg-id" param.
- When a TCP connection is made from a client, Kamailio has to create
a flow token identifier for such connection.
- We need a new "loose_route_outbound()" function that adds a
Record-Route whose URI username matches the flow token associated to
the connection from which the request comes.
- When a request arrives to Kamailio and contains a Route header
pointing to us and containing a Route with username, then Kamailio
must inspect the URI username to know which connection to use for
routing such request (don't trust the RURI as it would be the private
URI of a Contact header). Don't mangle the Contact header please, no
more request/response mangling.
- Summarizing, RFC 5626 requires additions to:
- registrar module
- location module
- rr module
For the 430 prioriziation issue you mentiod this probably needs to be changed
in the tm module.
Best regards,
Henning
7:44 a.m.
10 okt 2011 kl. 13:38 skrev Henning Westerholt:
On Saturday 08 October 2011, Iñaki Baz Castillo
wrote:
The idea is that a client has two open connections and two registrations from the same
device. The registrations has the same UUID in the contact, but different reg-id's.
When an edge proxy returns 430 when the registrar uses one reg-id contact, the registrar
needs to retry with the other reg-id.
So there are two issues here: Kamailio acting as an edge proxy that receives registrations
and adds a path header, and answers with an error code if the connection to the client is
lost. The other is Kamailio as a location server that understands that it has two
registrations from the same device and only use one of them, with the others as failover.
/O
[RFC 5826]
Hi Inaki,
sounds really interesting, thanks for bringing this up here.
Some other collateral changes needed for the
above to work properly:
- 430 status code MUST have less priority than any other 4XX response
since such 430 response can only be replied by edge proxies and means
"the TCP/TLS connection with the user is closed".
What about the 439 code, i guess we need support in the server for this as
well?
7:39 a.m.
Olle E. Johansson writes:
The idea is that a client has two open connections and
two
registrations from the same device. The registrations has the same
UUID in the contact, but different reg-id's. When an edge proxy
returns 430 when the registrar uses one reg-id contact, the registrar
needs to retry with the other reg-id.
i just checked rfc5626 and in my opinion it has big flaw in that even if
an ua is configured with two ob proxies, rfc5626 does not require that
ua registers via both of them. rfc5626 thus just brings more complexity
without any benefit for implementing proxy redundancy.
-- juha
8:26 a.m.
2011/10/10 Juha Heinanen <jh(a)tutpro.com>om>:
No Juha, really not.
Forget the two ob proxies if you want. The rest of the specification
is the best answer for NAT and TCP/TLS, much better than the
half-solutions we use today (those that makes the registrar to mantain
40 bindings for the same AoR when the device is a movile using SIP
over TCP and reconnects every few minutes).
What are you proposing then Juha? not implementing RFC 5626 and
continuing with custom solutions that don't work well? continuing with
Contact rewritting? No please.
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
The idea is
that a client has two open connections and two
registrations from the same device. The registrations has the same
UUID in the contact, but different reg-id's. When an edge proxy
returns 430 when the registrar uses one reg-id contact, the registrar
needs to retry with the other reg-id.
i just checked rfc5626 and in my opinion it has big flaw in that even if
an ua is configured with two ob proxies, rfc5626 does not require that
ua registers via both of them. rfc5626 thus just brings more complexity
without any benefit for implementing proxy redundancy.
8:15 a.m.
Iñaki Baz Castillo writes:
Forget the two ob proxies if you want. The rest of the
specification
is the best answer for NAT and TCP/TLS, much better than the
half-solutions we use today (those that makes the registrar to mantain
40 bindings for the same AoR when the device is a movile using SIP
over TCP and reconnects every few minutes).
i don't have anything against that when ua registers it tells its unique
id so that registrar can discard the old ones.
what i was trying to say that outbound does not bring any help to
implementing redundant sip infrastructure, where two active proxies
could have worked together each with its own ip address.
What are you proposing then Juha? not implementing RFC
5626 and
continuing with custom solutions that don't work well? continuing with
Contact rewritting? No please.
what comes to nat traversal, what are the problems with contact
rewriting? so far it has worked quite well for me.
-- juha
9:25 a.m.
2011/10/10 Juha Heinanen <jh(a)tutpro.com>om>:
It's a hack! and it breaks SIP protocol as the UA should see a RURI
matching its Contact in incoming requests, rather than a rewritten
URI.
I cannot understand how the current hack should be preferred instead
of implementing RFC 5626. "It seems to work with current hack" should
not be a valid argument IMHO.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
What are you
proposing then Juha? not implementing RFC 5626 and
continuing with custom solutions that don't work well? continuing with
Contact rewritting? No please.
what comes to nat traversal, what are the problems with contact
rewriting? so far it has worked quite well for me.
8:34 a.m.
Iñaki Baz Castillo writes:
It's a hack! and it breaks SIP protocol as the UA
should see a RURI
matching its Contact in incoming requests, rather than a rewritten
URI.
huh, inaki, don't you use this?
http://sip-router.org/wiki/tutorials/alias-example
I cannot understand how the current hack should be
preferred instead
of implementing RFC 5626. "It seems to work with current hack" should
not be a valid argument IMHO.
because MOST OF that rfc brings lots of complexity without any real
benefit. +sip.instance stuff is the only benefit.
-- juha
9:36 a.m.
10 okt 2011 kl. 14:15 skrev Juha Heinanen:
Iñaki Baz Castillo writes:
For platforms where you want some sort of integrity check in the message, like
with S/MIME or SIP Identity,
rewriting the message will break security. If we want to build secure platforms in SIP,
we need to find solutions that doesn't require SDP and SIP rewrites in the proxys.
That's why ICE puts the burden of finding IP addresses and relay servers on the UA and
SIP outbound puts connection management on the UA. If the UA can handle all of this
and have all data correct when sending the message, a message rewrite that breaks
digital signatures should not be needed any more.
One thing I realized the other night during a SIP discussion was that Ice doesn't
allow
a network provider to implement a policy. I don't think a proxy can't say
"442 Always use media relay"
and force the client to drop local addresses, like if there's a requirement for
lawful
intercept in the network. That will be something that needs to be added to ICE.
/O
Forget the two ob proxies if you want. The rest
of the specification
is the best answer for NAT and TCP/TLS, much better than the
half-solutions we use today (those that makes the registrar to mantain
40 bindings for the same AoR when the device is a movile using SIP
over TCP and reconnects every few minutes).
i don't have anything against that when ua registers it tells its unique
id so that registrar can discard the old ones.
what i was trying to say that outbound does not bring any help to
implementing redundant sip infrastructure, where two active proxies
could have worked together each with its own ip address.
What are you proposing then Juha? not
implementing RFC 5626 and
continuing with custom solutions that don't work well? continuing with
Contact rewritting? No please.
what comes to nat traversal, what are the problems with contact
rewriting? so far it has worked quite well for me.
8:39 a.m.
Olle E. Johansson writes:
For platforms where you want some sort of integrity
check in the
message, like with S/MIME or SIP Identity, rewriting the message will
break security. If we want to build secure platforms in SIP, we need
to find solutions that doesn't require SDP and SIP rewrites in the
proxys.
based on my observations from many users and also based what kind of new
modules people have written for sr lately, there is more and more
tendency towards adding b2bua kind of stuff to sip proxy. if you want
a secure solution, better not to use proxy at all, but some kind of p2p
protocol.
One thing I realized the other night during a SIP
discussion was that
Ice doesn't allow
a network provider to implement a policy. I don't think a proxy can't
say "442 Always use media relay"
and force the client to drop local addresses, like if there's a
requirement for lawful
intercept in the network. That will be something that needs to be
added to ICE.
making it yet more complex. forget proxy if you want end-to-end
security.
-- juha
9:58 a.m.
2011/10/10 Juha Heinanen <jh(a)tutpro.com>om>:
Indeed. And honestly I don't like that at all.
That's not security, it's just "local policy". Mandating the audio
through a RTP tunnel is not "security".
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
For platforms
where you want some sort of integrity check in the
message, like with S/MIME or SIP Identity, rewriting the message will
break security. If we want to build secure platforms in SIP, we need
to find solutions that doesn't require SDP and SIP rewrites in the
proxys.
based on my observations from many users and also based what kind of new
modules people have written for sr lately, there is more and more
tendency towards adding b2bua kind of stuff to sip proxy. if you want
a secure solution, better not to use proxy at all, but some kind of p2p
protocol.
But nobody here is proposing RFC 5626 for security ;)
The point here is that, by implementing RFC 5626, a proxy does NOT
mangle the headers so, other proxies or UA's can verify the integrity
of the request (for example using Identity header). If the proxy
rewrites a header then forget Identity mechanism.
One thing I
realized the other night during a SIP discussion was that
Ice doesn't allow
a network provider to implement a policy. I don't think a proxy can't
say "442 Always use media relay"
and force the client to drop local addresses, like if there's a
requirement for lawful
intercept in the network. That will be something that needs to be
added to ICE.
making it yet more complex. forget proxy if you want end-to-end
security.
5:57 p.m.
On 10/10/11 3:58 PM, Iñaki Baz Castillo wrote:
2011/10/10 Juha Heinanen<jh(a)tutpro.com>om>:
Indeed. And honestly I
don't like that at all.
who is working on such extensions for our project? I am
not aware of
anyone trying to push b2bua in kamailio/ser and very happy with that.
My personal opinion is not against a b2bua in the proxy, but against any
b2bua in SIP. This concept brought the PSTN architecture back to life in
SIP, killing the flexibility and service extensibility of client side.
They are promoting a bunch of benefits, but actually inducing a false
impression of offering extra security and other b**ls**t-bingo
capabilities -- a short analyze proves all of them useless. If I have to
name the top enemies of SIP, the order is ALG (since affects
irremediably at some point SIP signaling) then SBCs/B2BUAs (not breaking
a call in two legs, but in a set of troubles, stopping evolution,
bringing devolution).
To clarify my statement, this is not like I will be against a b2bua
contribution in the form of a module (which has no or insignificant
impact on the core and commonly used modules) -- this is a project open
to contributions, just that I don't expect at all to get my attention
for testing or maintenance.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
For
platforms where you want some sort of integrity check in the
message, like with S/MIME or SIP Identity, rewriting the message will
break security. If we want to build secure platforms in SIP, we need
to find solutions that doesn't require SDP and SIP rewrites in the
proxys.
based on my observations from many users and also based what kind of new
modules people have written for sr lately, there is more and more
tendency towards adding b2bua kind of stuff to sip proxy.
11 Oct
11 Oct
8:30 a.m.
2011/10/10 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
who is working on such extensions for our project? I am not aware of anyone
trying to push b2bua in kamailio/ser and very happy with that.
My personal opinion is not against a b2bua in the proxy, but against any
b2bua in SIP.
Good ;)
based on my observations from many users and also
based what kind of new
modules people have written for sr lately, there is more and more
tendency towards adding b2bua kind of stuff to sip proxy.
Indeed. And honestly I don't like that at all. This concept brought the PSTN architecture back to
life in
SIP, killing the flexibility and service extensibility of client side. They
are promoting a bunch of benefits, but actually inducing a false impression
of offering extra security and other b**ls**t-bingo capabilities -- a short
analyze proves all of them useless. If I have to name the top enemies of
SIP, the order is ALG (since affects irremediably at some point SIP
signaling) then SBCs/B2BUAs (not breaking a call in two legs, but in a set
of troubles, stopping evolution, bringing devolution).
To clarify my statement, this is not like I will be against a b2bua
contribution in the form of a module (which has no or insignificant impact
on the core and commonly used modules) -- this is a project open to
contributions, just that I don't expect at all to get my attention for
testing or maintenance.
SBCs exist because they offer "some services" like for example... hum?
and due the fact that no vendor implements SIP security at all.
We need cool features in clients and proxies:
- ICE (RFC 5245): The best solution for NAT, validation of the peer
(who is sending RTP to me?) and IPv4/IPv6 transition.
- Outbound (RFC 5626): The ellegant solution for TCP/TLS clients
behind NAT. No hacks.
- GRUU (RFC 5627): Required for setting in your "Contact" something
really reachable by others (rather than your private IP). Problems
sending a REFER? GRUU is the solution.
- SRTP (RFC 3711): Why are we so happy with unencrypted audio/video media??
- SIP over TLS: But it needs to be reworked as the current spec sucks!
Let's open SIP to Internet, but for that it must work and it must be *safe*.
Cheers.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
8:55 a.m.
El Tue, 11 Oct 2011 14:30:49 +0200
Iñaki Baz Castillo <ibc(a)aliax.net> escribió:
SBCs exist because they offer "some services" like for example... hum?
and due the fact that no vendor implements SIP security at all.
b2buas are not really defined so they can be intrusive and bad or a good thing
depending on what you need. In my experience, my company's product could not
provide some cool features to our customers without a b2bua as sems.
For me, it offers topoh hiding, response mapping, codec filtering, session
timers, some accounting stuff, session duration limit and some sbc
capabilities. I agree that I would like to see the inteligence at endpoint
level but that's not true life. So yes, b2buas are necesary for me at this
point.
You're talking about SIP on the web, where it does not exist at the moment.
Nowadays, SIP exists in telcos' wallet gardens and in companies' PBX systems. If
SIP will expand to the internet at some point, it will/should do from where
it's now (telcos) and not from scratch.
We need cool features in clients and proxies:
Agree but some comments out here:
- ICE (RFC 5245): The best solution for NAT,
validation of the peer
(who is sending RTP to me?) and IPv4/IPv6 transition.
As Ole mentioned and I discussed with him last week, ICE may break LI (lawful
interception) requirements for some vendors. It needs some switch to be able to
disable it when LI is required.
- Outbound (RFC 5626): The ellegant solution for
TCP/TLS clients
behind NAT. No hacks.
- GRUU (RFC 5627): Required for setting in your "Contact" something
really reachable by others (rather than your private IP). Problems
sending a REFER? GRUU is the solution.
- SRTP (RFC 3711): Why are we so happy with unencrypted audio/video media??
Because we're in closed networks. This is becoming more important each day as
federation, internet users and mobile device users come to the SIP world. The
TLS and SRTP/ZRTP requirements from my customers has increased this year 1000%
- SIP over TLS: But it needs to be reworked as the
current spec sucks!
Let's open SIP to Internet, but for that it must work and it must be *safe*.
Open SIP to the internet. Yes. Open which is already in place. SIP in internet
from scratch is a no go. Google talk, Skype and Facebook (with Skype
integration or whatever) have thousands of millions of users in advantage. But
if you start opening the wallet gardens, you'll start with millions of users
that don't know they already use SIP and corporate customers which means money
behind the protocol. You need to play poker with the cards you've been given.
Must work: yes. I would drop the whole SIMPLE specification (all the RFCs) to
have some really functional. As it is now we won't have any compatible
federated presence mechanism ever.
Must be safe: Agree. No doubts here.
btw: This is becoming a mayor OT for this list, isn't it?
cheers,
Jon
9:01 a.m.
El Tue, 11 Oct 2011 14:55:08 +0200
Jon Bonilla (Manwe) <manwe(a)aholab.ehu.es> escribió:
%s,wallet/wallen/g
9:29 a.m.
2011/10/11 Jon Bonilla <manwe(a)aholab.ehu.es>es>:
Right, but those are no intrusive features and are desirable when
users talk to a PSTN gateway (as you need accounting, session timers,
codec filtering and so).
Then you can set a B2BUA in the middle of the call so the audio passes
through the media address set by the B2BUA.
Good.
SBCs exist because they offer "some services" like for example... hum?
and due the fact that no vendor implements SIP security at all.
b2buas are not really defined so they can be intrusive and bad or a good thing
depending on what you need. In my experience, my company's product could not
provide some cool features to our customers without a b2bua as sems.
For me, it offers topoh hiding, response mapping, codec filtering, session
timers, some accounting stuff, session duration limit and some sbc
capabilities. I agree that I would like to see the inteligence at endpoint
level but that's not true life. So yes, b2buas are necesary for me at this
point. - ICE (RFC
5245): The best solution for NAT, validation of the peer
(who is sending RTP to me?) and IPv4/IPv6 transition.
As Ole mentioned and I discussed with him last week, ICE may break LI (lawful
interception) requirements for some vendors. It needs some switch to be able to
disable it when LI is required. - SRTP (RFC
3711): Why are we so happy with unencrypted audio/video media??
Because we're in closed networks. This is becoming more important each day as
federation, internet users and mobile device users come to the SIP world. The
TLS and SRTP/ZRTP requirements from my customers has increased this year 1000% Open SIP to the internet. Yes. Open which is already
in place. SIP in internet
from scratch is a no go. Google talk, Skype and Facebook (with Skype
integration or whatever) have thousands of millions of users in advantage. But
if you start opening the wallet gardens, you'll start with millions of users
that don't know they already use SIP and corporate customers which means money
behind the protocol. You need to play poker with the cards you've been given.
Must work: yes. I would drop the whole SIMPLE specification (all the RFCs) to
have some really functional. As it is now we won't have any compatible
federated presence mechanism ever.
Just drop SIMPLE for presence. MSRP is not bad ;)
Must be safe: Agree. No doubts here.
btw: This is becoming a mayor OT for this list, isn't it?
Well, IMHO a conversation about current status of SIP world is good
anywhere, even more in the maillist of an open source and nice SIP
proxy ;)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
10 Oct
10 Oct
9:42 a.m.
Juha Heinanen wrote:
Iñaki Baz Castillo writes:
Do I understand you correctly that you want to use a set of edge proxies
plus a set of registrars and it should create connections to all edge
proxies and then register with all registrars via each of these
connections?
Regards,
Martin
Forget the two ob proxies if you want. The rest
of the specification
is the best answer for NAT and TCP/TLS, much better than the
half-solutions we use today (those that makes the registrar to mantain
40 bindings for the same AoR when the device is a movile using SIP
over TCP and reconnects every few minutes).
i don't have anything against that when ua registers it tells its unique
id so that registrar can discard the old ones.
what i was trying to say that outbound does not bring any help to
implementing redundant sip infrastructure, where two active proxies
could have worked together each with its own ip address.
8:47 a.m.
Martin Hoffmann writes:
Do I understand you correctly that you want to use a
set of edge proxies
plus a set of registrars and it should create connections to all edge
proxies and then register with all registrars via each of these
connections?
if outbound rfc would have made it a requirement that each ua must
register via at least two proxies in its ob proxy set, then i would have
configured them with two and i could have been able to run those two
proxies in parallel (both active at the same time listening at their own
ip address).
but according to ob rfc, an ua is allowed to register only via one ob
proxy (for example in order to save power) in the set, which means that
in order to achieve redundancy, i have to setup a passive standby proxy
that receives the single ip address if the currently active proxy one
fails.
-- juha
9:58 a.m.
Juha Heinanen wrote:
Martin Hoffmann writes:
Right. Except:
| If the [outbound-proxy-set] has more than
| one URI, the UAC MUST send a REGISTER request to at least two of the
| default outbound proxies from the set.
(RFC 5626, section 4.2.1.)
Regards,
Martin
Do I understand you correctly that you want to
use a set of edge proxies
plus a set of registrars and it should create connections to all edge
proxies and then register with all registrars via each of these
connections?
if outbound rfc would have made it a requirement that each ua must
register via at least two proxies in its ob proxy set, then i would have
configured them with two and i could have been able to run those two
proxies in parallel (both active at the same time listening at their own
ip address).
but according to ob rfc, an ua is allowed to register only via one ob
proxy (for example in order to save power) in the set, which means that
in order to achieve redundancy, i have to setup a passive standby proxy
that receives the single ip address if the currently active proxy one
fails.
9:03 a.m.
Martin Hoffmann writes:
Right. Except:
| If the [outbound-proxy-set] has more than
| one URI, the UAC MUST send a REGISTER request to at least two of the
| default outbound proxies from the set.
ok, good i didn't read far enough. then also that part of ob rfc makes
sense, i.e., registering via two ob proxies.
-- juha
9:59 a.m.
2011/10/10 Juha Heinanen <jh(a)tutpro.com>om>:
but according to ob rfc, an ua is allowed to register
only via one ob
proxy (for example in order to save power) in the set, which means that
in order to achieve redundancy, i have to setup a passive standby proxy
that receives the single ip address if the currently active proxy one
fails
Wrong, really wrong. Please Juha check the example in section 9.2:
http://tools.ietf.org/html/rfc5626#section-9.2
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
9:20 a.m.
10 okt 2011 kl. 13:39 skrev Juha Heinanen:
Olle E. Johansson writes:
The main difference compared with RFC 3261 is that the burden of
connection management - UDP, TCP or STCP - is put on the UA.
The proxy reuse the connection created by the UA for outbound
requests, but does NOT open new connections.
The specification also adds the ability, but not the requirement,
to handle multiple connections (flows) from the same UA to different proxys
as failover connections. This will indeed make TCP failover faster and propably
SHOULD be a requirement for TCP/TLS. Previously it was impossible to
recognize that multiple registrations was from the same UA, so the proxy
had to fork to all of them and just hope that the UA had some merged fork
detection.
I think both of these solutions are huge improvements.
/O
The idea is that a client has two open
connections and two
registrations from the same device. The registrations has the same
UUID in the contact, but different reg-id's. When an edge proxy
returns 430 when the registrar uses one reg-id contact, the registrar
needs to retry with the other reg-id.
i just checked rfc5626 and in my opinion it has big flaw in that even if
an ua is configured with two ob proxies, rfc5626 does not require that
ua registers via both of them. rfc5626 thus just brings more complexity
without any benefit for implementing proxy redundancy.
8:31 a.m.
Olle E. Johansson writes:
The main difference compared with RFC 3261 is that the
burden of
connection management - UDP, TCP or STCP - is put on the UA.
The proxy reuse the connection created by the UA for outbound
requests, but does NOT open new connections.
there is no difference to what my proxy does today. it does not try to
setup tcp connections to ua (set_forward_no_connect()) and udp is a bad
idea anyway.
The specification also adds the ability, but not the
requirement,
to handle multiple connections (flows) from the same UA to different proxys
as failover connections. This will indeed make TCP failover faster and
propably SHOULD be a requirement for TCP/TLS.
yes, but since it is NOT a requirement, you don't get any benefit.
Previously it was impossible to
recognize that multiple registrations was from the same UA, so the proxy
had to fork to all of them and just hope that the UA had some merged fork
detection.
this is indeed an improvement as i have already mentioned and very easy
to implement in the ua. baresip, for example, does add +sip.instance
param to contact header:
REGISTER sip:test.fi SIP/2.0.
Via: SIP/2.0/TCP 188.67.205.145:35327;branch=z9hG4bKfa4a89e63adaf759;rport.
Contact:
<sip:jh@188.67.205.145:35327;transport=tcp>;expires=600;+sip.instance="<urn:uuid:c79b8de4-6c2f-4d48-a347-d13d9b19d255>".
but does not add Supported: gruu in requests.
so my suggestion is to put priority in adding +sip.instance support to
sr registrar/usrloc implementation.
-- juha
7:51 a.m.
2011/10/10 Henning Westerholt <hw(a)kamailio.org>rg>:
Yes. But IMHO it's not so interesting as it would just occur in case
the proxy between client and registrar does not support RFC 5626 (and
I suppose that both servers would always be provided and configured by
the same admin).
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
Some other
collateral changes needed for the above to work properly:
- 430 status code MUST have less priority than any other 4XX response
since such 430 response can only be replied by edge proxies and means
"the TCP/TLS connection with the user is closed".
What about the 439 code, i guess we need support in the server for this as
well?
4642
days inactive
4645
days old
34 comments
9 participants
participants (9)
-
Alfred E. Heggestad -
Andrew Miller -
Daniel-Constantin Mierla -
Henning Westerholt -
Iñaki Baz Castillo -
Jon Bonilla -
Juha Heinanen -
Martin Hoffmann -
Olle E. Johansson