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.
On 10/9/11 8:14 AM, Juha Heinanen wrote:
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?
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
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
On 10/9/11 4:06 PM, Juha Heinanen wrote:
Alfred E. Heggestad writes:
I know a good one that I can warmly recommend :)
http://www.creytiv.com/baresip.htmli 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.
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
2011/10/10 Alfred E. Heggestad aeh@db.org:
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.
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.instanc...
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. Heggestadaeh@db.org:
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.
2011/10/10 Daniel-Constantin Mierla miconda@gmail.com:
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.
2011/10/9 Juha Heinanen jh@tutpro.com:
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.
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 Heinanenjh@tutpro.com:
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.
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 Heinanenjh@tutpro.com:
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
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
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
10 okt 2011 kl. 13:38 skrev Henning Westerholt:
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?
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
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
2011/10/10 Juha Heinanen jh@tutpro.com:
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.
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 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
2011/10/10 Juha Heinanen jh@tutpro.com:
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.
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 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
10 okt 2011 kl. 14:15 skrev Juha Heinanen:
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.
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
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
2011/10/10 Juha Heinanen jh@tutpro.com:
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.
Indeed. And honestly I don't like that at all.
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.
That's not security, it's just "local policy". Mandating the audio through a RTP tunnel is not "security".
On 10/10/11 3:58 PM, Iñaki Baz Castillo wrote:
2011/10/10 Juha Heinanenjh@tutpro.com:
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.
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
2011/10/10 Daniel-Constantin Mierla miconda@gmail.com:
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.
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 ;)
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.
El Tue, 11 Oct 2011 14:30:49 +0200 Iñaki Baz Castillo ibc@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
El Tue, 11 Oct 2011 14:55:08 +0200 Jon Bonilla (Manwe) manwe@aholab.ehu.es escribió:
%s,wallet/wallen/g
2011/10/11 Jon Bonilla manwe@aholab.ehu.es:
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.
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).
- 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.
Then you can set a B2BUA in the middle of the call so the audio passes through the media address set by the B2BUA.
- 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%
Good.
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 ;)
Juha Heinanen wrote:
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.
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
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
Juha Heinanen wrote:
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.
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
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
2011/10/10 Juha Heinanen jh@tutpro.com:
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
10 okt 2011 kl. 13:39 skrev Juha Heinanen:
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.
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
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
2011/10/10 Henning Westerholt hw@kamailio.org:
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?
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).
-
Alfred E. Heggestad -
Andrew Miller -
Daniel-Constantin Mierla -
Henning Westerholt -
Iñaki Baz Castillo -
Jon Bonilla -
Juha Heinanen -
Martin Hoffmann -
Olle E. Johansson