Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS 1.9.0 major release
Hi All, If oversip uses Path extension OpenSIPS must support it. 1- Sending Path header values in 200 ok REGISTER response 2- Path header files syntax must confom to Route syntax 3- When look up the opensips must copies the stored path header fileds into Route header fileds - preloaded route. Reference: RFC 3327 Here i think adding one Route header pointing to OverSIP (second Path URI) is enough in simple case (UA OverSIP--- OpenSIPS). OverSIP removes the Route header and route the request based on RURI (first Path URI). OpenSIPs support this http://www.opensips.org/html/docs/modules/devel/registrar.html#id248705 flag px (path support) of save function in Registrar module. So still parsing VIA header is required to add WS and WSS. I think this patch is already posted. Binan. Från: Iñaki Baz Castillo i...@aliax.net Till: Bogdan-Andrei Iancu bog...@opensips.org Kopia: OpenSIPS users mailling list us...@lists.opensips.org Skickat: torsdag, 1 november 2012 20:36 Ämne: Re: [OpenSIPS-Users] [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.9.0 major release 2012/11/1 Bogdan-Andrei Iancu bog...@opensips.org Hi Inaki, Please correct me if I'm wrong, but reading the draft and listing you guys all, I would say the right approach is to : (1) use OverSIP as gw (to extract SIP traffic from WebSocket) and (2) make OpenSIPS to support SIP traffic resulted from websocket extraction. If so, OpenSIPS has nothing to do with the WebSocket protocol itself, but only to support the extensions from the draft (like new protocols and eventually the SIP server location). Right. As Saul pointed out, this scenario (which is a pure RFC 5626 Outbound scenario with a Edge Proxy in front of the registrar/authentication-proxy) requires: - Path support in OpenSIPS for storing the Path URI(s). Note: It's important to increase the path column size in the location table. The current value is to small and cannot store two URI's (OverSIP adds double Path headers). - OpenSIPS should improve the parser of the Via transport field since currently it only accepts UDP, TCP, TLS and SCTP. It should also accept WS and WSS, but better if it accepts any token (as the RFC 3261 BNF grammar states). Otherwise OpenSIPS will discard SIP requests coming from OverSIP (since the non top Via header, that created by the SIP WebSocket client, has WS as transport protocol). And nothing else at all, but the above two points are important. Regards. -- Iñaki Baz Castillo i...@aliax.net ___ Users mailing list us...@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS 1.9.0 major release
On Mon, Nov 5, 2012 at 7:40 AM, Dan Pascu d...@ag-projects.com wrote: On 31 Oct 2012, at 21:59, Ryan Bullock wrote: These would make pinging a bit more complicated but may help avoid races: 1. Have the ping aware of when the last INVITE was seen in the dialog (sent from anyone) and only issue its own re-INVITE if it has not seen an INVITE for X seconds in the dialog. Perhaps X could be a lower value if the previous re-INVITE had a negative reply (many clients locally end the call when they receive a negative reply to an INVITE, but may not issue a BYE). Add a little session timer awareness and you may be able to avoid most races. This will not solve anything. Client behavior is unpredictable from the server point of view. You cannot estimate when the client will send the next re-INVITE in order to avoid the race. If session timers are negotiated for the call you actually do have an idea of how often refresh should be seen. If the timer passes and no refresh has occurred it should be a safe bet that the call is gone and it is safe to check its status via a re-INVITE. What might be nice is if you could use the SST module and set an absolute duration on the call. I believe the SST module overwrites the dlg timeout AVP values so you can use one or the other, but not both (someone please correct me if I am wrong). 2. Combine 1 with OPTIONS between INVITES. For example, send an OPTION ping every minute, but you also want to see a re-INVITE every 15 minutes. This could allow quick detection for clients that support OPTION properly and the re-INVITE would help detect dead calls when the client is a bit buggy. It doesn't matter if you send in-dialog OPTIONs or INVITEs. Two in-dialog requests cannot overlap, no matter if it's an OPTION or an INVITE. The issue is the same regardless of the method you use. Nothing that I am aware of in the SIP RFC restricts parallel in-dialog transactions. However, since INVITEs (an UPDATEs) can modify the dialog and session information, it's hard to processes them in parallel. OPTIONs do not modify the dialog or session and can be processed in parallel. So, by sending OPTIONS frequently you get a cheaper, safer, but less reliable way to check the dialog, and then on top of that you do INVITES infrequently for those clients that don't always properly respond with a 481 for calls that are gone. In my opinion the worry about 'breaking' calls is moot, as these clients are already broken and may have their calls terminated anyways if both sides attempt re-INVITEs at the same time (I see this all the time). The only difference is now, instead of Opensips leaving the call up forever because neither side ever sent a BYE, Opensips would have a more reliable method for checking if the call actually ended. This is needed to detect when calls have ended because of the clients already broken behavior. Currently the only other options are to use Opensips in conjunction with rtpproxy/mediaproxy and to use media timeouts to determine when calls have ended, but that's an awful heavy solution compared to re-INVITES. Buggy implementations will always have problems, but you can only do so much to work around them. Regards, Ryan ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS 1.9.0 major release
On 31 Oct 2012, at 21:59, Ryan Bullock wrote: These would make pinging a bit more complicated but may help avoid races: 1. Have the ping aware of when the last INVITE was seen in the dialog (sent from anyone) and only issue its own re-INVITE if it has not seen an INVITE for X seconds in the dialog. Perhaps X could be a lower value if the previous re-INVITE had a negative reply (many clients locally end the call when they receive a negative reply to an INVITE, but may not issue a BYE). Add a little session timer awareness and you may be able to avoid most races. This will not solve anything. Client behavior is unpredictable from the server point of view. You cannot estimate when the client will send the next re-INVITE in order to avoid the race. 2. Combine 1 with OPTIONS between INVITES. For example, send an OPTION ping every minute, but you also want to see a re-INVITE every 15 minutes. This could allow quick detection for clients that support OPTION properly and the re-INVITE would help detect dead calls when the client is a bit buggy. It doesn't matter if you send in-dialog OPTIONs or INVITEs. Two in-dialog requests cannot overlap, no matter if it's an OPTION or an INVITE. The issue is the same regardless of the method you use. -- Dan ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS 1.9.0 major release
On 1 Nov 2012, at 13:02, Bogdan-Andrei Iancu wrote: Hi Dan, Well, as Ovidiu said, it is prone. BUT, this is not something particular to re-INVITE, but to whatever in-dialog pinging you may have from a mid-proxy. I never said otherwise. On the other hand, as Ryan pointed out here, the need to check the dialog health from proxy side, without relying on special end-UA features (like SST), is really critical. While it may be useful (I would not call it exactly critical), this doesn't mean that the implementation should introduce new issues. I'm not arguing against the idea of having a keep-alive mechanism here, but against particular implementations that introduce new issues. So, I see two approaches: 1) either simply live with the fact that races may occure and calls may be dropped during a re-INVITE, but at least is a clear drop /cut I'm not sure you can explain your customers that their calls are being dropped because you have a race condition in your implementation which you are willing to live with... 2) theoretically we can try to address the race at dialog modules level : (a) If you have ongoing in-dialog transaction, do not do your ping , This was never the issue. You can always avoid this. (b) if you have an ongoing in-dialog ping and receive another in-dilog request from end point, try to delay it until your pinging is done. This should work, but I don't see it working without a proper async reactor model. How do you plan to delay it, without blocking the worker? On another note, I also believe that a re-INVITE based keep-alive is also problematic because it has to implement the whole stream selection mechanism in the clients in order to know what streams to propose in the re-INVITE. Even so, triggering a SDP renegotiation every now and then is not very nice, regardless of it changing nothing in the streams. -- Dan ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS 1.9.0 major release
Hi Dan, I agree it is not a easy thing to do, neither bullet proofed, but the big question is : does it do more good than harm ? also, what are the other options we have here ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 11/05/2012 05:57 PM, Dan Pascu wrote: On 1 Nov 2012, at 13:02, Bogdan-Andrei Iancu wrote: Hi Dan, Well, as Ovidiu said, it is prone. BUT, this is not something particular to re-INVITE, but to whatever in-dialog pinging you may have from a mid-proxy. I never said otherwise. On the other hand, as Ryan pointed out here, the need to check the dialog health from proxy side, without relying on special end-UA features (like SST), is really critical. While it may be useful (I would not call it exactly critical), this doesn't mean that the implementation should introduce new issues. I'm not arguing against the idea of having a keep-alive mechanism here, but against particular implementations that introduce new issues. So, I see two approaches: 1) either simply live with the fact that races may occure and calls may be dropped during a re-INVITE, but at least is a clear drop /cut I'm not sure you can explain your customers that their calls are being dropped because you have a race condition in your implementation which you are willing to live with... 2) theoretically we can try to address the race at dialog modules level : (a) If you have ongoing in-dialog transaction, do not do your ping , This was never the issue. You can always avoid this. (b) if you have an ongoing in-dialog ping and receive another in-dilog request from end point, try to delay it until your pinging is done. This should work, but I don't see it working without a proper async reactor model. How do you plan to delay it, without blocking the worker? On another note, I also believe that a re-INVITE based keep-alive is also problematic because it has to implement the whole stream selection mechanism in the clients in order to know what streams to propose in the re-INVITE. Even so, triggering a SDP renegotiation every now and then is not very nice, regardless of it changing nothing in the streams. -- Dan ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS 1.9.0 major release
Hi Binan, Yes the patch is there, we need to review it. Also Inaki sugested some tunings in the PATH module (to fully support websocket). Thanks and regards, Bogdan Sent from Samsung MobileBinan AL Halabi binanalhal...@yahoo.com wrote: Hi All, If oversip uses Path extension OpenSIPS must support it. 1- Sending Path header values in 200 ok REGISTER response 2- Path header files syntax must confom to Route syntax 3- When look up the opensips must copies the stored path header fileds into Route header fileds - preloaded route. Reference: RFC 3327 Here i think adding one Route header pointing to OverSIP (second Path URI) is enough in simple case (UA OverSIP--- OpenSIPS). OverSIP removes the Route header and route the request based on RURI (first Path URI). OpenSIPs support this http://www.opensips.org/html/docs/modules/devel/registrar.html#id248705 flag px (path support) of save function in Registrar module. So still parsing VIA header is required to add WS and WSS. I think this patch is already posted. Binan. Från: Iñaki Baz Castillo i...@aliax.net Till: Bogdan-Andrei Iancu bog...@opensips.org Kopia: OpenSIPS users mailling list us...@lists.opensips.org Skickat: torsdag, 1 november 2012 20:36 Ämne: Re: [OpenSIPS-Users] [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.9.0 major release 2012/11/1 Bogdan-Andrei Iancu bog...@opensips.org Hi Inaki, Please correct me if I'm wrong, but reading the draft and listing you guys all, I would say the right approach is to : (1) use OverSIP as gw (to extract SIP traffic from WebSocket) and (2) make OpenSIPS to support SIP traffic resulted from websocket extraction. If so, OpenSIPS has nothing to do with the WebSocket protocol itself, but only to support the extensions from the draft (like new protocols and eventually the SIP server location). Right. As Saul pointed out, this scenario (which is a pure RFC 5626 Outbound scenario with a Edge Proxy in front of the registrar/authentication-proxy) requires: - Path support in OpenSIPS for storing the Path URI(s). Note: It's important to increase the path column size in the location table. The current value is to small and cannot store two URI's (OverSIP adds double Path headers). - OpenSIPS should improve the parser of the Via transport field since currently it only accepts UDP, TCP, TLS and SCTP. It should also accept WS and WSS, but better if it accepts any token (as the RFC 3261 BNF grammar states). Otherwise OpenSIPS will discard SIP requests coming from OverSIP (since the non top Via header, that created by the SIP WebSocket client, has WS as transport protocol). And nothing else at all, but the above two points are important. Regards. -- Iñaki Baz Castillo i...@aliax.net ___ Users mailing list us...@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS 1.9.0 major release
2012/11/2 Binan AL Halabi binanalhal...@yahoo.com: Hi All, If oversip uses Path extension OpenSIPS must support it. 1- Sending Path header values in 200 ok REGISTER response Even if this is required by RFC, the fact is that it's not needed at all for this stuff to work. 2- Path header files syntax must confom to Route syntax Right. 3- When look up the opensips must copies the stored path header fileds into Route header fileds - preloaded route. Reference: RFC 3327 Right. Here i think adding one Route header pointing to OverSIP (second Path URI) is enough in simple case (UA OverSIP--- OpenSIPS). OverSIP removes the Route header and route the request based on RURI (first Path URI). Also right, but due the design of OverSIP (basically an Outbound EDGE proxy) it was easier for me to always use double Record-Route and double Path header. In Outbound (RFC 5626) the Record-Route header added by the EDGE proxy contains a username in the URI that identifies the client connection. For some reasons it was easier always to use double Path. Anyhow, consider also the case in which there are two proxies between clients and OpenSIPS, so increasing the size of the path column is required. -- Iñaki Baz Castillo i...@aliax.net ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS 1.9.0 major release
2012/11/2 Bogdan-Andrei Iancu bog...@opensips.org: Yes the patch is there, we need to review it. Also Inaki sugested some tunings in the PATH module (to fully support websocket). Well, there is no special needs for the PATH module to support WebSocket. In fact, nothing must be done if it already works ok (but just increasing the path column size to be able to store two URIs). Regards. -- Iñaki Baz Castillo i...@aliax.net ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS 1.9.0 major release
On 11/02/2012 02:17 PM, Iñaki Baz Castillo wrote: 2012/11/2 Bogdan-Andrei Iancubog...@opensips.org: Yes the patch is there, we need to review it. Also Inaki sugested some tunings in the PATH module (to fully support websocket). Well, there is no special needs for the PATH module to support WebSocket. In fact, nothing must be done if it already works ok (but just increasing the path column size to be able to store two URIs). Yes, that's the kind of things I was referring at. Also looking in the patch module code, there are several things that can be improved there (how path is built, mem usag, etc). There are still some faulty things also there - there was recently a fix on TCP handling (proto changing) in PATH hdr. Regards, Bogdan ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS 1.9.0 major release
Hi Dan, Well, as Ovidiu said, it is prone. BUT, this is not something particular to re-INVITE, but to whatever in-dialog pinging you may have from a mid-proxy. On the other hand, as Ryan pointed out here, the need to check the dialog health from proxy side, without relying on special end-UA features (like SST), is really critical. So, I see two approaches: 1) either simply live with the fact that races may occure and calls may be dropped during a re-INVITE, but at least is a clear drop /cut 2) theoretically we can try to address the race at dialog modules level : (a) If you have ongoing in-dialog transaction, do not do your ping , (b) if you have an ongoing in-dialog ping and receive another in-dilog request from end point, try to delay it until your pinging is done.just some ideas Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/31/2012 09:03 PM, Dan Pascu wrote: On 29 Oct 2012, at 12:11, Bogdan-Andrei Iancu wrote: Hi Saul, We were thinking at re-INVITE pinging from OpenSIPs level towards the caller and callee. There will be 2 modes (at least this is the current plan). 1) remember all the time the last SDPs from each side and re-use them when pining the other sides (just to trick the SDP negotiation) 2) start with a lateSDP negotiation on one side and do normal SDP on the other side (to avoid SDP storing), but this means at least one of the parties should support late SDP negotiations 3) open to other suggestions I think this invites trouble as it is prone to race conditions. If any of the clients send a re-INVIVITE of their own while OpenSIPs does it's pinging, it will fail as there is already an active unanswered re-INVITE in progress. The client will be confused as it didn't send another re-INVITE itself and the negative reply to its own re-INVITE will probably just prompt the client to terminate the session thinking there is some issue with it. I cannot see this working without a full B2BUA, where OpenSIPs would queue the client requests if there is a ping in progress and only forward them after it has finished the ping transaction. About the GRUU stuff, could you detail a bit :D ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/26/2012 06:51 PM, Saúl Ibarra Corretgé wrote: Hi, On Oct 26, 2012, at 5:20 PM, Bogdan-Andrei Iancu wrote: Hi all, I would like to start a discussion about the next OpenSIPS major release - and in this discussion anyone is welcomed with options, ideas, critics and other. Your feedback is important to drive the project into a direction that reflects the user's needs!. So, I will here the starting points, for both release planing and release content. Content --- What was done: http://www.opensips.org/Main/Ver190#toc2 What is planned: http://www.opensips.org/Main/Ver190#toc9 Planned items have priorities (for being addressed); it is a must to have all items done for the next release, as we need to fit into a time frame. Whatever is not done, will be left for the next release (1.10) Planing --- Release candidate: second half of January 2012, depending on the progress with the items to be done. Testing phase: 1 month allocated (it may be extended if critical problems show up) Stable release: second half of February (after the testing phase is done). Once again, your feedback on these matters is important to us. I'll edit the wiki with the items we've been working on for presence. Can you give a bit more detail on the dialog ping with re-INVITEs? re-INVITEs are particularly troublesome, because there can only be one of them at a time. Also, can we add the in-dialog requests when using GRUU bug to the wishlist? :-) Keep up the good work guys! Regards, -- Saúl Ibarra Corretgé AG Projects ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Users mailing list us...@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Dan ___ Users mailing list us...@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS 1.9.0 major release
On 29 Oct 2012, at 12:11, Bogdan-Andrei Iancu wrote: Hi Saul, We were thinking at re-INVITE pinging from OpenSIPs level towards the caller and callee. There will be 2 modes (at least this is the current plan). 1) remember all the time the last SDPs from each side and re-use them when pining the other sides (just to trick the SDP negotiation) 2) start with a lateSDP negotiation on one side and do normal SDP on the other side (to avoid SDP storing), but this means at least one of the parties should support late SDP negotiations 3) open to other suggestions I think this invites trouble as it is prone to race conditions. If any of the clients send a re-INVIVITE of their own while OpenSIPs does it's pinging, it will fail as there is already an active unanswered re-INVITE in progress. The client will be confused as it didn't send another re-INVITE itself and the negative reply to its own re-INVITE will probably just prompt the client to terminate the session thinking there is some issue with it. I cannot see this working without a full B2BUA, where OpenSIPs would queue the client requests if there is a ping in progress and only forward them after it has finished the ping transaction. About the GRUU stuff, could you detail a bit :D ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/26/2012 06:51 PM, Saúl Ibarra Corretgé wrote: Hi, On Oct 26, 2012, at 5:20 PM, Bogdan-Andrei Iancu wrote: Hi all, I would like to start a discussion about the next OpenSIPS major release - and in this discussion anyone is welcomed with options, ideas, critics and other. Your feedback is important to drive the project into a direction that reflects the user's needs!. So, I will here the starting points, for both release planing and release content. Content --- What was done: http://www.opensips.org/Main/Ver190#toc2 What is planned: http://www.opensips.org/Main/Ver190#toc9 Planned items have priorities (for being addressed); it is a must to have all items done for the next release, as we need to fit into a time frame. Whatever is not done, will be left for the next release (1.10) Planing --- Release candidate: second half of January 2012, depending on the progress with the items to be done. Testing phase: 1 month allocated (it may be extended if critical problems show up) Stable release: second half of February (after the testing phase is done). Once again, your feedback on these matters is important to us. I'll edit the wiki with the items we've been working on for presence. Can you give a bit more detail on the dialog ping with re-INVITEs? re-INVITEs are particularly troublesome, because there can only be one of them at a time. Also, can we add the in-dialog requests when using GRUU bug to the wishlist? :-) Keep up the good work guys! Regards, -- Saúl Ibarra Corretgé AG Projects ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Users mailing list us...@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Dan ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS 1.9.0 major release
On Wed, Oct 31, 2012 at 3:03 PM, Dan Pascu d...@ag-projects.com wrote: On 29 Oct 2012, at 12:11, Bogdan-Andrei Iancu wrote: Hi Saul, We were thinking at re-INVITE pinging from OpenSIPs level towards the caller and callee. There will be 2 modes (at least this is the current plan). 1) remember all the time the last SDPs from each side and re-use them when pining the other sides (just to trick the SDP negotiation) 2) start with a lateSDP negotiation on one side and do normal SDP on the other side (to avoid SDP storing), but this means at least one of the parties should support late SDP negotiations 3) open to other suggestions I think this invites trouble as it is prone to race conditions. If any of the clients send a re-INVIVITE of their own while OpenSIPs does it's pinging, it will fail as there is already an active unanswered re-INVITE in progress. The client will be confused as it didn't send another re-INVITE itself and the negative reply to its own re-INVITE will probably just prompt the client to terminate the session thinking there is some issue with it. I cannot see this working without a full B2BUA, where OpenSIPs would queue the client requests if there is a ping in progress and only forward them after it has finished the ping transaction. Yes, it is prone to race conditions :( The UAS should detect such race and reply with 491 Request Pending in order to clear out this race, but I wonder how many SIP implementation are implementing this properly: https://tools.ietf.org/html/rfc3261#section-21.4.27 https://tools.ietf.org/html/rfc3261#section-14.2 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS 1.9.0 major release
On Wed, Oct 31, 2012 at 12:15 PM, Ovidiu Sas o...@voipembedded.com wrote: On Wed, Oct 31, 2012 at 3:03 PM, Dan Pascu d...@ag-projects.com wrote: On 29 Oct 2012, at 12:11, Bogdan-Andrei Iancu wrote: Hi Saul, We were thinking at re-INVITE pinging from OpenSIPs level towards the caller and callee. There will be 2 modes (at least this is the current plan). 1) remember all the time the last SDPs from each side and re-use them when pining the other sides (just to trick the SDP negotiation) 2) start with a lateSDP negotiation on one side and do normal SDP on the other side (to avoid SDP storing), but this means at least one of the parties should support late SDP negotiations 3) open to other suggestions I think this invites trouble as it is prone to race conditions. If any of the clients send a re-INVIVITE of their own while OpenSIPs does it's pinging, it will fail as there is already an active unanswered re-INVITE in progress. The client will be confused as it didn't send another re-INVITE itself and the negative reply to its own re-INVITE will probably just prompt the client to terminate the session thinking there is some issue with it. I cannot see this working without a full B2BUA, where OpenSIPs would queue the client requests if there is a ping in progress and only forward them after it has finished the ping transaction. Yes, it is prone to race conditions :( The UAS should detect such race and reply with 491 Request Pending in order to clear out this race, but I wonder how many SIP implementation are implementing this properly: https://tools.ietf.org/html/rfc3261#section-21.4.27 https://tools.ietf.org/html/rfc3261#section-14.2 In my experience, very few implementations handle a negative response to a re-INVITE well (491 included). These would make pinging a bit more complicated but may help avoid races: 1. Have the ping aware of when the last INVITE was seen in the dialog (sent from anyone) and only issue its own re-INVITE if it has not seen an INVITE for X seconds in the dialog. Perhaps X could be a lower value if the previous re-INVITE had a negative reply (many clients locally end the call when they receive a negative reply to an INVITE, but may not issue a BYE). Add a little session timer awareness and you may be able to avoid most races. 2. Combine 1 with OPTIONS between INVITES. For example, send an OPTION ping every minute, but you also want to see a re-INVITE every 15 minutes. This could allow quick detection for clients that support OPTION properly and the re-INVITE would help detect dead calls when the client is a bit buggy. The various implementations for re-INVITE and OPTION support make this an interesting problem. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS 1.9.0 major release
Hi Ovidiu, It could be - first we need to evaluate how large the code will be (or not) - but at the end it's not so relevant where it will end :) Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/26/2012 06:34 PM, Ovidiu Sas wrote: Locks for config could be integrated in cfgutils (instead of creating a new module). -ovidiu On Fri, Oct 26, 2012 at 11:20 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi all, I would like to start a discussion about the next OpenSIPS major release - and in this discussion anyone is welcomed with options, ideas, critics and other. Your feedback is important to drive the project into a direction that reflects the user's needs!. So, I will here the starting points, for both release planing and release content. Content --- What was done: http://www.opensips.org/Main/Ver190#toc2 What is planned: http://www.opensips.org/Main/Ver190#toc9 Planned items have priorities (for being addressed); it is a must to have all items done for the next release, as we need to fit into a time frame. Whatever is not done, will be left for the next release (1.10) Planing --- Release candidate: second half of January 2012, depending on the progress with the items to be done. Testing phase: 1 month allocated (it may be extended if critical problems show up) Stable release: second half of February (after the testing phase is done). Once again, your feedback on these matters is important to us. Best regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS 1.9.0 major release
Hi Saul, We were thinking at re-INVITE pinging from OpenSIPs level towards the caller and callee. There will be 2 modes (at least this is the current plan). 1) remember all the time the last SDPs from each side and re-use them when pining the other sides (just to trick the SDP negotiation) 2) start with a lateSDP negotiation on one side and do normal SDP on the other side (to avoid SDP storing), but this means at least one of the parties should support late SDP negotiations 3) open to other suggestions About the GRUU stuff, could you detail a bit :D ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/26/2012 06:51 PM, Saúl Ibarra Corretgé wrote: Hi, On Oct 26, 2012, at 5:20 PM, Bogdan-Andrei Iancu wrote: Hi all, I would like to start a discussion about the next OpenSIPS major release - and in this discussion anyone is welcomed with options, ideas, critics and other. Your feedback is important to drive the project into a direction that reflects the user's needs!. So, I will here the starting points, for both release planing and release content. Content --- What was done: http://www.opensips.org/Main/Ver190#toc2 What is planned: http://www.opensips.org/Main/Ver190#toc9 Planned items have priorities (for being addressed); it is a must to have all items done for the next release, as we need to fit into a time frame. Whatever is not done, will be left for the next release (1.10) Planing --- Release candidate: second half of January 2012, depending on the progress with the items to be done. Testing phase: 1 month allocated (it may be extended if critical problems show up) Stable release: second half of February (after the testing phase is done). Once again, your feedback on these matters is important to us. I'll edit the wiki with the items we've been working on for presence. Can you give a bit more detail on the dialog ping with re-INVITEs? re-INVITEs are particularly troublesome, because there can only be one of them at a time. Also, can we add the in-dialog requests when using GRUU bug to the wishlist? :-) Keep up the good work guys! Regards, -- Saúl Ibarra Corretgé AG Projects ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS 1.9.0 major release
+1for new module to drive SANGOMA cards in for transcoding (similar to driving the rtpproxy or mediaproxy) Regards, Sammy On Sat, Oct 27, 2012 at 4:41 AM, Ali Pey ali...@gmail.com wrote: I do also see a lot of value in sip over websocket. WebRTC is pretty much here and it makes much more sense to be able to support it on one proxy server rather than having to use OverSIP and then OpenSIPS. WebRTC seems to be very popular and the thing of tomorrow and it will be very important for a sip proxy server to support it. Regards, Ali Pey On Fri, Oct 26, 2012 at 11:54 AM, Saúl Ibarra Corretgé s...@ag-projects.com wrote: On Oct 26, 2012, at 5:46 PM, Duane Larson wrote: Is there any roadmap for SIP over Websocket? I know there is now OverSIP but wasn't sure if OpenSIPS had any plans to implement a module. Just asking since WebRTC is still evolving. I personally don't see the need to do it in the 1.x series. You can use OverSIP to do protocol translation to TCP/TLS and send the call to OpenSIPS. Now, IIRC there was some problem in parsing the Via headers, because they now have a different transport parameter (ws and wss), but I think someone posted a patch already. -- Saúl Ibarra Corretgé AG Projects ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Users mailing list us...@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS 1.9.0 major release
Bogdan, For both it would make sense to use JSON I think. Moreso for couchbase which understands JSON natively. For the key, just setting it as a TimeUUID I think would make a lot of sense. -Brett On Fri, Oct 26, 2012 at 5:02 PM, Bogdan-Andrei Iancu bog...@opensips.orgwrote: Hi Brett, Indeed that's something interesting...and how to pack all fields into a single value? Json ? Also the key name should be time basedi guess we need to dynamically generate them. Regards, Bogdan Sent from Samsung Mobile Brett Nemeroff br...@nemeroff.com wrote: Bogdan, Very excited to see NOSQL support. I know we discussed this before, but is there any possibility of native acc support for any NOSQL backend? Thanks! -Brett On Fri, Oct 26, 2012 at 10:20 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi all, I would like to start a discussion about the next OpenSIPS major release - and in this discussion anyone is welcomed with options, ideas, critics and other. Your feedback is important to drive the project into a direction that reflects the user's needs!. So, I will here the starting points, for both release planing and release content. Content --- What was done: http://www.opensips.org/Main/**Ver190#toc2http://www.opensips.org/Main/Ver190#toc2 What is planned: http://www.opensips.org/Main/**Ver190#toc9http://www.opensips.org/Main/Ver190#toc9 Planned items have priorities (for being addressed); it is a must to have all items done for the next release, as we need to fit into a time frame. Whatever is not done, will be left for the next release (1.10) Planing --- Release candidate: second half of January 2012, depending on the progress with the items to be done. Testing phase: 1 month allocated (it may be extended if critical problems show up) Stable release: second half of February (after the testing phase is done). Once again, your feedback on these matters is important to us. Best regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.**com http://www.opensips-solutions.com __**_ Users mailing list us...@lists.opensips.org http://lists.opensips.org/cgi-**bin/mailman/listinfo/usershttp://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS 1.9.0 major release
Hi Ali, I have to admit I'm not really familiar with the WebRTC and what are the requirements for this to work directly over OpenSIPS - there is pending patch for compatibility with WebRTC (parsing and detecting more VIA params, specific to WebRTC), but we will need to have a clear view on what needs to be done for a complete integration - and at that point to say if makes sense to do it or not. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/27/2012 02:41 AM, Ali Pey wrote: I do also see a lot of value in sip over websocket. WebRTC is pretty much here and it makes much more sense to be able to support it on one proxy server rather than having to use OverSIP and then OpenSIPS. WebRTC seems to be very popular and the thing of tomorrow and it will be very important for a sip proxy server to support it. Regards, Ali Pey On Fri, Oct 26, 2012 at 11:54 AM, Saúl Ibarra Corretgé s...@ag-projects.com mailto:s...@ag-projects.com wrote: On Oct 26, 2012, at 5:46 PM, Duane Larson wrote: Is there any roadmap for SIP over Websocket? I know there is now OverSIP but wasn't sure if OpenSIPS had any plans to implement a module. Just asking since WebRTC is still evolving. I personally don't see the need to do it in the 1.x series. You can use OverSIP to do protocol translation to TCP/TLS and send the call to OpenSIPS. Now, IIRC there was some problem in parsing the Via headers, because they now have a different transport parameter (ws and wss), but I think someone posted a patch already. -- Saúl Ibarra Corretgé AG Projects ___ Devel mailing list Devel@lists.opensips.org mailto:Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS 1.9.0 major release
Hi Bogdan, On Oct 29, 2012, at 11:26 AM, Bogdan-Andrei Iancu wrote: Hi Ali, I have to admit I'm not really familiar with the WebRTC and what are the requirements for this to work directly over OpenSIPS - there is pending patch for compatibility with WebRTC (parsing and detecting more VIA params, specific to WebRTC), but we will need to have a clear view on what needs to be done for a complete integration - and at that point to say if makes sense to do it or not. In a nutshell: WebRTC is a combined effort between IETF and W3C to bring realtime communications to web browsers. WebRTC only specifies the media plane, so signaling is up to applications. Here is the draft specifying the WebSocket transport for SIP: http://tools.ietf.org/html/draft-ietf-sipcore-sip-websocket-05 which allows applications written in JavaScript and running in web browsers to connect to existing SIP infrastructure. Since OpenSIPS is a SIP proxy and thus is not concerned by the media plane, supporting the WebSocket transport is what would be required for it to enter the WebRTC game. That said, IMHIO, makes little to no sense to do it until TCP works properly, given that WebSocket is a transport protocol on top of TCP. Regards, -- Saúl Ibarra Corretgé AG Projects ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS 1.9.0 major release
Hi Brett, Added this to the list. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/29/2012 08:12 AM, Brett Nemeroff wrote: Bogdan, For both it would make sense to use JSON I think. Moreso for couchbase which understands JSON natively. For the key, just setting it as a TimeUUID I think would make a lot of sense. -Brett On Fri, Oct 26, 2012 at 5:02 PM, Bogdan-Andrei Iancu bog...@opensips.org mailto:bog...@opensips.org wrote: Hi Brett, Indeed that's something interesting...and how to pack all fields into a single value? Json ? Also the key name should be time basedi guess we need to dynamically generate them. Regards, Bogdan Sent from Samsung Mobile Brett Nemeroff br...@nemeroff.com mailto:br...@nemeroff.com wrote: Bogdan, Very excited to see NOSQL support. I know we discussed this before, but is there any possibility of native acc support for any NOSQL backend? Thanks! -Brett On Fri, Oct 26, 2012 at 10:20 AM, Bogdan-Andrei Iancu bog...@opensips.org mailto:bog...@opensips.org wrote: Hi all, I would like to start a discussion about the next OpenSIPS major release - and in this discussion anyone is welcomed with options, ideas, critics and other. Your feedback is important to drive the project into a direction that reflects the user's needs!. So, I will here the starting points, for both release planing and release content. Content --- What was done: http://www.opensips.org/Main/Ver190#toc2 What is planned: http://www.opensips.org/Main/Ver190#toc9 Planned items have priorities (for being addressed); it is a must to have all items done for the next release, as we need to fit into a time frame. Whatever is not done, will be left for the next release (1.10) Planing --- Release candidate: second half of January 2012, depending on the progress with the items to be done. Testing phase: 1 month allocated (it may be extended if critical problems show up) Stable release: second half of February (after the testing phase is done). Once again, your feedback on these matters is important to us. Best regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com ___ Users mailing list us...@lists.opensips.org mailto:us...@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS 1.9.0 major release
Hi Brett, I have also done some research on NoSQL backends and I discovered that MongoDB is a much better suited candidate for storing accounting records an SIP traces than key/value store databases. http://cdrtool.ag-projects.com/projects/cdrtool/wiki/MongoDB Adrian On Oct 29, 2012, at 7:12 AM, Brett Nemeroff wrote: Bogdan, For both it would make sense to use JSON I think. Moreso for couchbase which understands JSON natively. For the key, just setting it as a TimeUUID I think would make a lot of sense. -Brett On Fri, Oct 26, 2012 at 5:02 PM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi Brett, Indeed that's something interesting...and how to pack all fields into a single value? Json ? Also the key name should be time basedi guess we need to dynamically generate them. Regards, Bogdan Sent from Samsung Mobile Brett Nemeroff br...@nemeroff.com wrote: Bogdan, Very excited to see NOSQL support. I know we discussed this before, but is there any possibility of native acc support for any NOSQL backend? Thanks! -Brett On Fri, Oct 26, 2012 at 10:20 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi all, I would like to start a discussion about the next OpenSIPS major release - and in this discussion anyone is welcomed with options, ideas, critics and other. Your feedback is important to drive the project into a direction that reflects the user's needs!. So, I will here the starting points, for both release planing and release content. Content --- What was done: http://www.opensips.org/Main/Ver190#toc2 What is planned: http://www.opensips.org/Main/Ver190#toc9 Planned items have priorities (for being addressed); it is a must to have all items done for the next release, as we need to fit into a time frame. Whatever is not done, will be left for the next release (1.10) Planing --- Release candidate: second half of January 2012, depending on the progress with the items to be done. Testing phase: 1 month allocated (it may be extended if critical problems show up) Stable release: second half of February (after the testing phase is done). Once again, your feedback on these matters is important to us. Best regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com ___ Users mailing list us...@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS 1.9.0 major release
Locks for config could be integrated in cfgutils (instead of creating a new module). -ovidiu On Fri, Oct 26, 2012 at 11:20 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi all, I would like to start a discussion about the next OpenSIPS major release - and in this discussion anyone is welcomed with options, ideas, critics and other. Your feedback is important to drive the project into a direction that reflects the user's needs!. So, I will here the starting points, for both release planing and release content. Content --- What was done: http://www.opensips.org/Main/Ver190#toc2 What is planned: http://www.opensips.org/Main/Ver190#toc9 Planned items have priorities (for being addressed); it is a must to have all items done for the next release, as we need to fit into a time frame. Whatever is not done, will be left for the next release (1.10) Planing --- Release candidate: second half of January 2012, depending on the progress with the items to be done. Testing phase: 1 month allocated (it may be extended if critical problems show up) Stable release: second half of February (after the testing phase is done). Once again, your feedback on these matters is important to us. Best regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS 1.9.0 major release
Hi, On Oct 26, 2012, at 5:20 PM, Bogdan-Andrei Iancu wrote: Hi all, I would like to start a discussion about the next OpenSIPS major release - and in this discussion anyone is welcomed with options, ideas, critics and other. Your feedback is important to drive the project into a direction that reflects the user's needs!. So, I will here the starting points, for both release planing and release content. Content --- What was done: http://www.opensips.org/Main/Ver190#toc2 What is planned: http://www.opensips.org/Main/Ver190#toc9 Planned items have priorities (for being addressed); it is a must to have all items done for the next release, as we need to fit into a time frame. Whatever is not done, will be left for the next release (1.10) Planing --- Release candidate: second half of January 2012, depending on the progress with the items to be done. Testing phase: 1 month allocated (it may be extended if critical problems show up) Stable release: second half of February (after the testing phase is done). Once again, your feedback on these matters is important to us. I'll edit the wiki with the items we've been working on for presence. Can you give a bit more detail on the dialog ping with re-INVITEs? re-INVITEs are particularly troublesome, because there can only be one of them at a time. Also, can we add the in-dialog requests when using GRUU bug to the wishlist? :-) Keep up the good work guys! Regards, -- Saúl Ibarra Corretgé AG Projects ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS 1.9.0 major release
On Oct 26, 2012, at 5:46 PM, Duane Larson wrote: Is there any roadmap for SIP over Websocket? I know there is now OverSIP but wasn't sure if OpenSIPS had any plans to implement a module. Just asking since WebRTC is still evolving. I personally don't see the need to do it in the 1.x series. You can use OverSIP to do protocol translation to TCP/TLS and send the call to OpenSIPS. Now, IIRC there was some problem in parsing the Via headers, because they now have a different transport parameter (ws and wss), but I think someone posted a patch already. -- Saúl Ibarra Corretgé AG Projects ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS 1.9.0 major release
Hi Brett, Indeed that's something interesting...and how to pack all fields into a single value? Json ? Also the key name should be time basedi guess we need to dynamically generate them. Regards, Bogdan Sent from Samsung MobileBrett Nemeroff br...@nemeroff.com wrote:Bogdan, Very excited to see NOSQL support. I know we discussed this before, but is there any possibility of native acc support for any NOSQL backend? Thanks! -Brett On Fri, Oct 26, 2012 at 10:20 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi all, I would like to start a discussion about the next OpenSIPS major release - and in this discussion anyone is welcomed with options, ideas, critics and other. Your feedback is important to drive the project into a direction that reflects the user's needs!. So, I will here the starting points, for both release planing and release content. Content --- What was done: http://www.opensips.org/Main/Ver190#toc2 What is planned: http://www.opensips.org/Main/Ver190#toc9 Planned items have priorities (for being addressed); it is a must to have all items done for the next release, as we need to fit into a time frame. Whatever is not done, will be left for the next release (1.10) Planing --- Release candidate: second half of January 2012, depending on the progress with the items to be done. Testing phase: 1 month allocated (it may be extended if critical problems show up) Stable release: second half of February (after the testing phase is done). Once again, your feedback on these matters is important to us. Best regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com ___ Users mailing list us...@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS 1.9.0 major release
I do also see a lot of value in sip over websocket. WebRTC is pretty much here and it makes much more sense to be able to support it on one proxy server rather than having to use OverSIP and then OpenSIPS. WebRTC seems to be very popular and the thing of tomorrow and it will be very important for a sip proxy server to support it. Regards, Ali Pey On Fri, Oct 26, 2012 at 11:54 AM, Saúl Ibarra Corretgé s...@ag-projects.com wrote: On Oct 26, 2012, at 5:46 PM, Duane Larson wrote: Is there any roadmap for SIP over Websocket? I know there is now OverSIP but wasn't sure if OpenSIPS had any plans to implement a module. Just asking since WebRTC is still evolving. I personally don't see the need to do it in the 1.x series. You can use OverSIP to do protocol translation to TCP/TLS and send the call to OpenSIPS. Now, IIRC there was some problem in parsing the Via headers, because they now have a different transport parameter (ws and wss), but I think someone posted a patch already. -- Saúl Ibarra Corretgé AG Projects ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS 1.9.0 major release
Maybe Jan 2013? I'd like to see in this release more complex support of cachedb. First is cachedb support for usrloc. I think it's good idea to save locations in cachedb, but not in sql database. -- Nick 2012/10/26 Bogdan-Andrei Iancu bog...@opensips.org Hi all, I would like to start a discussion about the next OpenSIPS major release - and in this discussion anyone is welcomed with options, ideas, critics and other. Your feedback is important to drive the project into a direction that reflects the user's needs!. So, I will here the starting points, for both release planing and release content. Content --- What was done: http://www.opensips.org/Main/**Ver190#toc2http://www.opensips.org/Main/Ver190#toc2 What is planned: http://www.opensips.org/Main/**Ver190#toc9http://www.opensips.org/Main/Ver190#toc9 Planned items have priorities (for being addressed); it is a must to have all items done for the next release, as we need to fit into a time frame. Whatever is not done, will be left for the next release (1.10) Planing --- Release candidate: second half of January 2012, depending on the progress with the items to be done. Testing phase: 1 month allocated (it may be extended if critical problems show up) Stable release: second half of February (after the testing phase is done). Once again, your feedback on these matters is important to us. Best regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.**com http://www.opensips-solutions.com __**_ Users mailing list us...@lists.opensips.org http://lists.opensips.org/cgi-**bin/mailman/listinfo/usershttp://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
