Re: [SR-Users] Fwd: [RAI] SIPit 28 summary
16 apr 2011 kl. 19.36 skrev Iñaki Baz Castillo: 2011/4/16 Olle E. Johansson o...@edvina.net: Yes, Kamailio is behind and after focusing so much on the merger of the code I think it would be good to plan some new features for a coming release. The issue is what of all the new SIP features we need. History-info seems useful for Asterisk, don't know how much it will affect Kamailio. Gruu, well. I haven't seen many implementations out there. If the registrar doesn't support GRUU then it doesn't matter whether clients support it or not :) I think GRUU can be really useful. Me too. So maybe that's a good start. /O ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Fwd: [RAI] SIPit 28 summary
16 apr 2011 kl. 20.27 skrev Daniel-Constantin Mierla: On 4/16/11 7:30 PM, Olle E. Johansson wrote: 16 apr 2011 kl. 15.59 skrev Iñaki Baz Castillo: 2011/4/15 Klaus Darilionklaus.mailingli...@pernau.at: Support for various items in the proxy/registrars: 50% path 50% outbound 33% sip/stun multiplexing 20% diversion 18% gruu 17% history-info 17% service-route Correct me if I'm wrong: Items implemented in Kamailio/sip-router: - path - diversion Yes, Kamailio is behind and after focusing so much on the merger of the code I think it would be good to plan some new features for a coming release. I think this statement is not true. While a lot of work was indeed done on merging code, there were a lot of new featured added, much more than we had we previous major releases, many based on standardizations (e.g., presence extensions to conference, dialog info, xcap, a.s.o). The the core supports processing stun, see ser_stun.{c,h} - the guys at ser added that very long time ago. As for next release, there are lot of features added (http://sip-router.org/wiki/features/new-in-devel), more to come, but I think most of developers here got tired hunting the ghosts of IETF specs that never were any useful nor had a touch with the reality. As of myself, I really work now on what is demanded, there is no time to jump and implement any rfc/draft published based on theories elaborated by guys that never implemented their specs. Moreover, some of them are now in different boat and make incredible statements about sip considering their role in the past with this protocol... That's good feedback. I meant that we're behind the IETF. But so are most implementations out there... Sorry if I upset anyone. That wasn't my intention. /O ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Fwd: [RAI] SIPit 28 summary
2011/4/15 Klaus Darilion klaus.mailingli...@pernau.at: Support for various items in the proxy/registrars: 50% path 50% outbound 33% sip/stun multiplexing 20% diversion 18% gruu 17% history-info 17% service-route Correct me if I'm wrong: Items implemented in Kamailio/sip-router: - path - diversion -- Iñaki Baz Castillo i...@aliax.net ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Fwd: [RAI] SIPit 28 summary
16 apr 2011 kl. 15.59 skrev Iñaki Baz Castillo: 2011/4/15 Klaus Darilion klaus.mailingli...@pernau.at: Support for various items in the proxy/registrars: 50% path 50% outbound 33% sip/stun multiplexing 20% diversion 18% gruu 17% history-info 17% service-route Correct me if I'm wrong: Items implemented in Kamailio/sip-router: - path - diversion Yes, Kamailio is behind and after focusing so much on the merger of the code I think it would be good to plan some new features for a coming release. The issue is what of all the new SIP features we need. History-info seems useful for Asterisk, don't know how much it will affect Kamailio. Gruu, well. I haven't seen many implementations out there. I can theoretically see a need for it both in NAT situations and IPv6. Diversion is deprecated. Outbound is the final NAT traversal solution - which seems to be getting a lot of traction. Remember that there was very few participants in this SIPit so 50% is not a market share - far from it. /O ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Fwd: [RAI] SIPit 28 summary
2011/4/16 Olle E. Johansson o...@edvina.net: Yes, Kamailio is behind and after focusing so much on the merger of the code I think it would be good to plan some new features for a coming release. The issue is what of all the new SIP features we need. History-info seems useful for Asterisk, don't know how much it will affect Kamailio. Gruu, well. I haven't seen many implementations out there. If the registrar doesn't support GRUU then it doesn't matter whether clients support it or not :) I think GRUU can be really useful. I can theoretically see a need for it both in NAT situations and IPv6. Diversion is deprecated. No, it became RFC 5806 past year: http://tools.ietf.org/html/rfc5806 Outbound is the final NAT traversal solution - which seems to be getting a lot of traction. Remember that there was very few participants in this SIPit so 50% is not a market share - far from it. -- Iñaki Baz Castillo i...@aliax.net ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Fwd: [RAI] SIPit 28 summary
2011/4/16 Iñaki Baz Castillo i...@aliax.net: Diversion is deprecated. No, it became RFC 5806 past year: http://tools.ietf.org/html/rfc5806 But it has Category: Historic. -- Iñaki Baz Castillo i...@aliax.net ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Fwd: [RAI] SIPit 28 summary
Iñaki Baz Castillo writes: No, it became RFC 5806 past year: http://tools.ietf.org/html/rfc5806 But it has Category: Historic. they could not make it anything else because official solution is history-info that almost no one has implemented. -- juha ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Fwd: [RAI] SIPit 28 summary
On 4/16/11 7:30 PM, Olle E. Johansson wrote: 16 apr 2011 kl. 15.59 skrev Iñaki Baz Castillo: 2011/4/15 Klaus Darilionklaus.mailingli...@pernau.at: Support for various items in the proxy/registrars: 50% path 50% outbound 33% sip/stun multiplexing 20% diversion 18% gruu 17% history-info 17% service-route Correct me if I'm wrong: Items implemented in Kamailio/sip-router: - path - diversion Yes, Kamailio is behind and after focusing so much on the merger of the code I think it would be good to plan some new features for a coming release. I think this statement is not true. While a lot of work was indeed done on merging code, there were a lot of new featured added, much more than we had we previous major releases, many based on standardizations (e.g., presence extensions to conference, dialog info, xcap, a.s.o). The the core supports processing stun, see ser_stun.{c,h} - the guys at ser added that very long time ago. As for next release, there are lot of features added (http://sip-router.org/wiki/features/new-in-devel), more to come, but I think most of developers here got tired hunting the ghosts of IETF specs that never were any useful nor had a touch with the reality. As of myself, I really work now on what is demanded, there is no time to jump and implement any rfc/draft published based on theories elaborated by guys that never implemented their specs. Moreover, some of them are now in different boat and make incredible statements about sip considering their role in the past with this protocol... Cheers, Daniel The issue is what of all the new SIP features we need. History-info seems useful for Asterisk, don't know how much it will affect Kamailio. Gruu, well. I haven't seen many implementations out there. I can theoretically see a need for it both in NAT situations and IPv6. Diversion is deprecated. Outbound is the final NAT traversal solution - which seems to be getting a lot of traction. Remember that there was very few participants in this SIPit so 50% is not a market share - far from it. /O ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla http://www.asipto.com ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Fwd: [RAI] SIPit 28 summary
I wholeheartedly agree with Daniel's assessment. 3.x and 3.1.x have seen incredibly important feature gains that have been revolutionary for our work. It is true that a lot of the feature growth has been in internal/runtime capabilities of Kamailio as a pseudoprogrammatic execution environment, but so what? The net benefit to implementors and users of features like configuration file splitting, new TM, rtimer, mqueue, HTTP server + XMLRPC, and many other things has been enormous. Also, I strongly agree that the focus of the project should not be to go around chasing someone's novel, indecipherable IETF draft of the hour. They come and go like influenza. Note how many expired drafts were adopted by the market de facto immortally despite their expiration, like RPID, or, more often, completely ignored despite persistent attempts at standardisation. As Daniel said, no relation to reality in a lot of them. It becomes clear over a much longer period what should ultimately be supported, and watching the standards track is not a practical way to try to make that determination. -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ On Apr 16, 2011, at 2:27 PM, Daniel-Constantin Mierla mico...@gmail.com wrote: On 4/16/11 7:30 PM, Olle E. Johansson wrote: 16 apr 2011 kl. 15.59 skrev Iñaki Baz Castillo: 2011/4/15 Klaus Darilionklaus.mailingli...@pernau.at: Support for various items in the proxy/registrars: 50% path 50% outbound 33% sip/stun multiplexing 20% diversion 18% gruu 17% history-info 17% service-route Correct me if I'm wrong: Items implemented in Kamailio/sip-router: - path - diversion Yes, Kamailio is behind and after focusing so much on the merger of the code I think it would be good to plan some new features for a coming release. I think this statement is not true. While a lot of work was indeed done on merging code, there were a lot of new featured added, much more than we had we previous major releases, many based on standardizations (e.g., presence extensions to conference, dialog info, xcap, a.s.o). The the core supports processing stun, see ser_stun.{c,h} - the guys at ser added that very long time ago. As for next release, there are lot of features added (http://sip-router.org/wiki/features/new-in-devel), more to come, but I think most of developers here got tired hunting the ghosts of IETF specs that never were any useful nor had a touch with the reality. As of myself, I really work now on what is demanded, there is no time to jump and implement any rfc/draft published based on theories elaborated by guys that never implemented their specs. Moreover, some of them are now in different boat and make incredible statements about sip considering their role in the past with this protocol... Cheers, Daniel The issue is what of all the new SIP features we need. History-info seems useful for Asterisk, don't know how much it will affect Kamailio. Gruu, well. I haven't seen many implementations out there. I can theoretically see a need for it both in NAT situations and IPv6. Diversion is deprecated. Outbound is the final NAT traversal solution - which seems to be getting a lot of traction. Remember that there was very few participants in this SIPit so 50% is not a market share - far from it. /O ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla http://www.asipto.com ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Fwd: [RAI] SIPit 28 summary
2011/4/16 Daniel-Constantin Mierla mico...@gmail.com: As for next release, there are lot of features added (http://sip-router.org/wiki/features/new-in-devel), more to come, but I think most of developers here got tired hunting the ghosts of IETF specs that never were any useful nor had a touch with the reality. As of myself, I really work now on what is demanded, there is no time to jump and implement any rfc/draft published based on theories elaborated by guys that never implemented their specs. Moreover, some of them are now in different boat and make incredible statements about sip considering their role in the past with this protocol... Hi Daniel, I strongly agree with you (and sure you know I'm a good friend of IETF-way= :) I just said that, IMHO, gruu and tcp-outbound are two cool features. Of course, both need implementation in client and server side. The fact that there are not gruu implementations yet doesn't mean that the feature is interesting. Cheers. -- Iñaki Baz Castillo i...@aliax.net ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users