Hello,
fyi, we entered in testing phase in order to prepare next major release, numbered 3.1.0.
Please help to fill the wiki pages for what is new in this version and migration from 3.0.x: http://sip-router.org/wiki/install/3.0.x-to-3.1.x http://sip-router.org/wiki/features/new-in-devel
Testing and feedback are very much appreciated!
Cheers, Daniel
Hi everyone,
i know, i am a little late (due to a new job since the beginning of the month), but is it ok to push some last-minute changes (some changes to the nathelper/rtpproxy-module) to the git? I have the changes ready for K1.5 and i would migrate them to K-Trunk tonight...
The changes are: - Retrieval of RTP-Statistics from RTP-Proxy (as PV) - Submit a RTP-Timeout-Socket towards the RTP-Proxy (this requires some changes to the RTP-Proxy as well, which are not ready yet) - some minor changes
If i am too late, i will wait for the next release, that is fine for me.
Kind regards, Carsten
If i am too late, i will wait to the next release...
2010/8/17 Daniel-Constantin Mierla miconda@gmail.com
Hello,
fyi, we entered in testing phase in order to prepare next major release, numbered 3.1.0.
Please help to fill the wiki pages for what is new in this version and migration from 3.0.x: http://sip-router.org/wiki/install/3.0.x-to-3.1.x http://sip-router.org/wiki/features/new-in-devel
Testing and feedback are very much appreciated!
Cheers, Daniel
-- Daniel-Constantin Mierla http://www.asipto.com/
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Carsten Bock Schomburgstr. 80 22767 Hamburg Germany
Mobile +49 179 2021244 Home +49 40 34927217 Fax +49 40 34927218 mailto:carsten@bock.info
Hello,
On 8/18/10 8:59 AM, Carsten Bock wrote:
Hi everyone,
i know, i am a little late (due to a new job since the beginning of the month), but is it ok to push some last-minute changes (some changes to the nathelper/rtpproxy-module) to the git? I have the changes ready for K1.5 and i would migrate them to K-Trunk tonight...
The changes are:
- Retrieval of RTP-Statistics from RTP-Proxy (as PV)
- Submit a RTP-Timeout-Socket towards the RTP-Proxy (this requires
some changes to the RTP-Proxy as well, which are not ready yet)
- some minor changes
If i am too late, i will wait for the next release, that is fine for me.
if the patches are not very intrusive, then is fine for me, since you have them for a while and tested. You can upload first on tracker - it is another patch for nathelper that is on to-do to integrate.
I guess the extension for rtp proxy is optional, so will it work with current or older versions of rtpproxy?
Cheers, Daniel
Kind regards, Carsten
If i am too late, i will wait to the next release...
2010/8/17 Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com>
Hello, fyi, we entered in testing phase in order to prepare next major release, numbered 3.1.0. Please help to fill the wiki pages for what is new in this version and migration from 3.0.x: http://sip-router.org/wiki/install/3.0.x-to-3.1.x http://sip-router.org/wiki/features/new-in-devel Testing and feedback are very much appreciated! Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com/ _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev -- Carsten Bock Schomburgstr. 80 22767 Hamburg Germany Mobile +49 179 2021244 Home +49 40 34927217 Fax +49 40 34927218 mailto:carsten@bock.info
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
Hi,
I will put my patches on the tracker then, ok, great :-)
The extensions for the RTP-Proxy are the following: - if the name of the timeout-socket starts with "http://", it assumes it is an Kamailio-XML-RPC-Server. It will then retrieve the according dialog-info by issueing a dlg_list with the call-id and with this information execute a dlg_end_dlg using XML-RPC. - the RTP-Proxy-API is extended by a "deactivate independent timeout"-option. This is useful, when you are playing music on hold and one party does not send an announcement. - some minor changes in order to improve compability to some CPE's with T.38(e.g. Zyxel devices)
I need to add an Option for Kamailio 3 support (it is dlg.end_dlg and not dlg_end_dlg) and some more documentation. I wanted to add an Version-Info in order to retrieve an information about the extension of the API. And last, but not least, my RTP-Proxy changes need some more testing :-)
Kind regards, Carsten
2010/8/18 Daniel-Constantin Mierla miconda@gmail.com
Hello,
On 8/18/10 8:59 AM, Carsten Bock wrote:
Hi everyone,
i know, i am a little late (due to a new job since the beginning of the month), but is it ok to push some last-minute changes (some changes to the nathelper/rtpproxy-module) to the git? I have the changes ready for K1.5 and i would migrate them to K-Trunk tonight...
The changes are:
- Retrieval of RTP-Statistics from RTP-Proxy (as PV)
- Submit a RTP-Timeout-Socket towards the RTP-Proxy (this requires some
changes to the RTP-Proxy as well, which are not ready yet)
- some minor changes
If i am too late, i will wait for the next release, that is fine for me.
if the patches are not very intrusive, then is fine for me, since you have them for a while and tested. You can upload first on tracker - it is another patch for nathelper that is on to-do to integrate.
I guess the extension for rtp proxy is optional, so will it work with current or older versions of rtpproxy?
Cheers, Daniel
Kind regards, Carsten
If i am too late, i will wait to the next release...
2010/8/17 Daniel-Constantin Mierla miconda@gmail.com
Hello,
fyi, we entered in testing phase in order to prepare next major release, numbered 3.1.0.
Please help to fill the wiki pages for what is new in this version and migration from 3.0.x: http://sip-router.org/wiki/install/3.0.x-to-3.1.x http://sip-router.org/wiki/features/new-in-devel
Testing and feedback are very much appreciated!
Cheers, Daniel
-- Daniel-Constantin Mierla http://www.asipto.com/
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Carsten Bock Schomburgstr. 80 22767 Hamburg Germany
Mobile +49 179 2021244 Home +49 40 34927217 Fax +49 40 34927218 mailto:carsten@bock.info
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierlahttp://www.asipto.com/
2010/8/18 Carsten Bock lists@bock.info:
- if the name of the timeout-socket starts with "http://", it assumes it is
an Kamailio-XML-RPC-Server. It will then retrieve the according dialog-info by issueing a dlg_list with the call-id and with this information execute a dlg_end_dlg using XML-RPC.
Hi. Having to retrieve the dialogs full list for each time a rtpproxy session expires wouldn't be efficient, am I right? IMHO there could be a new MI function in dialog module allowing to terminate a dialog by providing its Call-ID and From-tag rather than the internal hash_id:hash_entry.
Regards.
Hi Inaki,
probably you are right. I have not thought about this. I will take a look at it and put a patch for this on the tracker. But i think, you are right, that should be easy to implement. By the way: If you make a dlg_list_dlg with Call-ID and From-Tag (what i do), you just get the one dialog and you do not get the full list...
Carsten
2010/8/18 Iñaki Baz Castillo ibc@aliax.net
2010/8/18 Carsten Bock lists@bock.info:
- if the name of the timeout-socket starts with "http://", it assumes it
is
an Kamailio-XML-RPC-Server. It will then retrieve the according
dialog-info
by issueing a dlg_list with the call-id and with this information execute
a
dlg_end_dlg using XML-RPC.
Hi. Having to retrieve the dialogs full list for each time a rtpproxy session expires wouldn't be efficient, am I right? IMHO there could be a new MI function in dialog module allowing to terminate a dialog by providing its Call-ID and From-tag rather than the internal hash_id:hash_entry.
Regards.
-- Iñaki Baz Castillo ibc@aliax.net
2010/8/18 Carsten Bock lists@bock.info:
Hi Inaki, probably you are right. I have not thought about this. I will take a look at it and put a patch for this on the tracker. But i think, you are right, that should be easy to implement.
I've added a comment about it in the wiki: http://www.kamailio.com/dokuwiki/doku.php/modules-new-design:dialog-module-d...
By the way: If you make a dlg_list_dlg with Call-ID and From-Tag (what i do), you just get the one dialog and you do not get the full list...
Yes, but anyhow it requires two MI calls and makes the operation complex (the "terminating" party must first invoke "dlg_list", then parse the MI body and finally invoke "dlg_end_dlg").
Regards.
Carsten
2010/8/18 Iñaki Baz Castillo ibc@aliax.net
2010/8/18 Carsten Bock lists@bock.info:
- if the name of the timeout-socket starts with "http://", it assumes it
is an Kamailio-XML-RPC-Server. It will then retrieve the according dialog-info by issueing a dlg_list with the call-id and with this information execute a dlg_end_dlg using XML-RPC.
Hi. Having to retrieve the dialogs full list for each time a rtpproxy session expires wouldn't be efficient, am I right? IMHO there could be a new MI function in dialog module allowing to terminate a dialog by providing its Call-ID and From-tag rather than the internal hash_id:hash_entry.
Regards.
-- Iñaki Baz Castillo ibc@aliax.net
-- Carsten Bock Schomburgstr. 80 22767 Hamburg Germany
Mobile +49 179 2021244 Home +49 40 34927217 Fax +49 40 34927218 mailto:carsten@bock.info
Hi,
I've noticed, my RTP-Proxy changes where for the latest K already. I have modified them, to work with the latest rtpproxy/nathelper split. I will do some more testing.... (they are in the branch carstenbock/rtpproxy). I have added the suggested extension to the K-Dialog-mi-Interface: I have created a method called "mi_terminate_dlgs" which allows to terminate either all calls (e.g. before a proxy shutdown) or a specific dialog by providing call-id and optionally the fromtag (in branch carstenbock/dialog). These changes require a little more testing, which i wil do in the next days, but probably will only be able to finish by next week...
Kind regards, Carsten
2010/8/18 Iñaki Baz Castillo ibc@aliax.net
2010/8/18 Carsten Bock lists@bock.info:
Hi Inaki, probably you are right. I have not thought about this. I will take a look
at
it and put a patch for this on the tracker. But i think, you are right,
that
should be easy to implement.
I've added a comment about it in the wiki:
http://www.kamailio.com/dokuwiki/doku.php/modules-new-design:dialog-module-d...
By the way: If you make a dlg_list_dlg with Call-ID and From-Tag (what i do), you just get the one dialog and you do not get the full list...
Yes, but anyhow it requires two MI calls and makes the operation complex (the "terminating" party must first invoke "dlg_list", then parse the MI body and finally invoke "dlg_end_dlg").
Regards.
Carsten
2010/8/18 Iñaki Baz Castillo ibc@aliax.net
2010/8/18 Carsten Bock lists@bock.info:
- if the name of the timeout-socket starts with "http://", it assumes
it
is an Kamailio-XML-RPC-Server. It will then retrieve the according dialog-info by issueing a dlg_list with the call-id and with this information execute a dlg_end_dlg using XML-RPC.
Hi. Having to retrieve the dialogs full list for each time a rtpproxy session expires wouldn't be efficient, am I right? IMHO there could be a new MI function in dialog module allowing to terminate a dialog by providing its Call-ID and From-tag rather than the internal hash_id:hash_entry.
Regards.
-- Iñaki Baz Castillo ibc@aliax.net
-- Carsten Bock Schomburgstr. 80 22767 Hamburg Germany
Mobile +49 179 2021244 Home +49 40 34927217 Fax +49 40 34927218 mailto:carsten@bock.info
-- Iñaki Baz Castillo ibc@aliax.net
2010/8/18 Carsten Bock lists@bock.info:
Hi, I've noticed, my RTP-Proxy changes where for the latest K already. I have modified them, to work with the latest rtpproxy/nathelper split. I will do some more testing.... (they are in the branch carstenbock/rtpproxy). I have added the suggested extension to the K-Dialog-mi-Interface: I have created a method called "mi_terminate_dlgs" which allows to terminate either all calls (e.g. before a proxy shutdown) or a specific dialog by providing call-id and optionally the fromtag (in branch carstenbock/dialog). These changes require a little more testing, which i wil do in the next days, but probably will only be able to finish by next week...
Hi, it sounds very good. Just take into account that current dialog module can only terminate dialogs in "stablished" status and it cannot terminate early-dialogs. So it's required that your new MI function checks whenever dialog state is 4 or 5. Timo fixed this issue some weeks ago in dld_end_dlg MI function.
I will test it when I finish my holidays :)
Regards.
Hi,
i have just commited some latest changes to my branches. I did some more testing and did fix a few things. I have also added the modified RTP-Proxy in order to test the RTP-Timeout (with my two User-Agents it worked pretty well). The RTP-Kamailio-Timeout-Notification will only be enabled, when you have libcurl and the libxmlrpc-client-dev-libs installed (using autoconf).
I had to change one thing to the dialog module, in order to make it work, where i'd like to get some feedback:
I had to change the method, how the "h_id" is calculated. Until now, it was calculated using the Call-Id and the From-Tag, making it impossible to find the dialog when you only have Call-ID. When calling dlg_list_dlg the From-Tag was not optional, it would simply not find the dialog. My new MI-Method "dlg_terminate_dlg" would also require both call-id and from-tag. Are there any objections in changing the method, how the "h_id" is calculated?
Kind regards, Carsten
2010/8/19 Iñaki Baz Castillo ibc@aliax.net
2010/8/18 Carsten Bock lists@bock.info:
Hi, I've noticed, my RTP-Proxy changes where for the latest K already. I have modified them, to work with the latest rtpproxy/nathelper split. I will
do
some more testing.... (they are in the branch carstenbock/rtpproxy). I have added the suggested extension to the K-Dialog-mi-Interface: I have created a method called "mi_terminate_dlgs" which allows to terminate
either
all calls (e.g. before a proxy shutdown) or a specific dialog by
providing
call-id and optionally the fromtag (in branch carstenbock/dialog). These changes require a little more testing, which i wil do in the next days, but probably will only be able to finish by next week...
Hi, it sounds very good. Just take into account that current dialog module can only terminate dialogs in "stablished" status and it cannot terminate early-dialogs. So it's required that your new MI function checks whenever dialog state is 4 or 5. Timo fixed this issue some weeks ago in dld_end_dlg MI function.
I will test it when I finish my holidays :)
Regards.
-- Iñaki Baz Castillo ibc@aliax.net
Hey,
"Iñaki Baz Castillo" ibc@aliax.net schrieb:
2010/8/18 Carsten Bock lists@bock.info:
Hi, I've noticed, my RTP-Proxy changes where for the latest K already. I have modified them, to work with the latest rtpproxy/nathelper split. I will do some more testing.... (they are in the branch carstenbock/rtpproxy). I have added the suggested extension to the K-Dialog-mi-Interface: I have created a method called "mi_terminate_dlgs" which allows to terminate either all calls (e.g. before a proxy shutdown) or a specific dialog by providing call-id and optionally the fromtag (in branch carstenbock/dialog). These changes require a little more testing, which i wil do in the next days, but probably will only be able to finish by next week...
Hi, it sounds very good. Just take into account that current dialog module can only terminate dialogs in "stablished" status and it cannot terminate early-dialogs. So it's required that your new MI function checks whenever dialog state is 4 or 5. Timo fixed this issue some weeks ago in dld_end_dlg MI function.
I will test it when I finish my holidays :)
Being on vacation too right now, I cannot add much to this topic at the moment but this: If I remember correctly my fix should operate at a lower call hierarchy level and therefore be effective for Carsten's new feature automatically. However, this should be double-checked which I can do as soon as I switch off tourist mode :).
Cheers,
Timo
Hey,
Timo Reimann wrote:
"Iñaki Baz Castillo" ibc@aliax.net schrieb:
2010/8/18 Carsten Bock lists@bock.info:
Hi, I've noticed, my RTP-Proxy changes where for the latest K already. I have modified them, to work with the latest rtpproxy/nathelper split. I will do some more testing.... (they are in the branch carstenbock/rtpproxy). I have added the suggested extension to the K-Dialog-mi-Interface: I have created a method called "mi_terminate_dlgs" which allows to terminate either all calls (e.g. before a proxy shutdown) or a specific dialog by providing call-id and optionally the fromtag (in branch carstenbock/dialog). These changes require a little more testing, which i wil do in the next days, but probably will only be able to finish by next week...
Hi, it sounds very good. Just take into account that current dialog module can only terminate dialogs in "stablished" status and it cannot terminate early-dialogs. So it's required that your new MI function checks whenever dialog state is 4 or 5. Timo fixed this issue some weeks ago in dld_end_dlg MI function.
I will test it when I finish my holidays :)
Being on vacation too right now, I cannot add much to this topic at the moment but this: If I remember correctly my fix should operate at a lower call hierarchy level and therefore be effective for Carsten's new feature automatically. However, this should be double-checked which I can do as soon as I switch off tourist mode :).
AFAICS, Carsten's function calls send_bye_all() which in turn calls send_bye() which implements the "no BYE requests for non-confirmed dialogs" protection.
Concluding, non-confirmed dialog termination should be effective out of the box.
Cheers,
--Timo
Hi,
if no one objects, i would push my changes into master then tonight....
Kind regards, Carsten
2010/8/30 Timo Reimann timo.reimann@1und1.de:
Hey,
Timo Reimann wrote:
"Iñaki Baz Castillo" ibc@aliax.net schrieb:
2010/8/18 Carsten Bock lists@bock.info:
Hi, I've noticed, my RTP-Proxy changes where for the latest K already. I have modified them, to work with the latest rtpproxy/nathelper split. I will do some more testing.... (they are in the branch carstenbock/rtpproxy). I have added the suggested extension to the K-Dialog-mi-Interface: I have created a method called "mi_terminate_dlgs" which allows to terminate either all calls (e.g. before a proxy shutdown) or a specific dialog by providing call-id and optionally the fromtag (in branch carstenbock/dialog). These changes require a little more testing, which i wil do in the next days, but probably will only be able to finish by next week...
Hi, it sounds very good. Just take into account that current dialog module can only terminate dialogs in "stablished" status and it cannot terminate early-dialogs. So it's required that your new MI function checks whenever dialog state is 4 or 5. Timo fixed this issue some weeks ago in dld_end_dlg MI function.
I will test it when I finish my holidays :)
Being on vacation too right now, I cannot add much to this topic at the moment but this: If I remember correctly my fix should operate at a lower call hierarchy level and therefore be effective for Carsten's new feature automatically. However, this should be double-checked which I can do as soon as I switch off tourist mode :).
AFAICS, Carsten's function calls send_bye_all() which in turn calls send_bye() which implements the "no BYE requests for non-confirmed dialogs" protection.
Concluding, non-confirmed dialog termination should be effective out of the box.
Cheers,
--Timo
Carsten Bock wrote:
if no one objects, i would push my changes into master then tonight....
Fine with me.
Concluding, non-confirmed dialog termination should be effective out of the box.
Just realizing that this doesn't make sense, what I meant to say was: Termination of non-confirmed dialogs will be prohibited automatically.
--Timo
-
Carsten Bock -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Timo Reimann