17 Aug
2010
17 Aug
'10
11:44 a.m.
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/
18 Aug
18 Aug
8:59 a.m.
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(a)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(a)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
<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev>
9:44 a.m.
New subject: [SR-Users] testing phase for 3.1
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(a)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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://www.asipto.com/
9:55 a.m.
New subject: [SR-Users] testing phase for 3.1
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(a)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(a)gmail.com>
--
Carsten Bock
Schomburgstr. 80
22767 Hamburg
Germany
Mobile +49 179 2021244
Home +49 40 34927217
Fax +49 40 34927218
mailto:carsten@bock.info
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(a)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
<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev>
_______________________________________________
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/
10:33 a.m.
New subject: [SR-Users] testing phase for 3.1
2010/8/18 Carsten Bock <lists(a)bock.info>fo>:
- 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(a)aliax.net>
10:44 a.m.
New subject: [SR-Users] testing phase for 3.1
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(a)aliax.net>
2010/8/18 Carsten Bock <lists(a)bock.info>fo>:
--
Carsten Bock
Schomburgstr. 80
22767 Hamburg
Germany
Mobile +49 179 2021244
Home +49 40 34927217
Fax +49 40 34927218
mailto:carsten@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(a)aliax.net>
11 a.m.
New subject: [SR-Users] testing phase for 3.1
2010/8/18 Carsten Bock <lists(a)bock.info>fo>:
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-…
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(a)aliax.net>
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
2010/8/18 Carsten Bock <lists(a)bock.info>fo>:
--
Carsten Bock
Schomburgstr. 80
22767 Hamburg
Germany
Mobile +49 179 2021244
Home +49 40 34927217
Fax +49 40 34927218
mailto:carsten@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(a)aliax.net>
10:52 p.m.
New subject: [SR-Users] testing phase for 3.1
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(a)aliax.net>
2010/8/18 Carsten Bock <lists(a)bock.info>fo>:
--
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(a)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 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-…
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(a)aliax.net>
>
> 2010/8/18 Carsten Bock <lists(a)bock.info>fo>:
>
> > - 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(a)aliax.net>
19 Aug
19 Aug
12:06 a.m.
New subject: [SR-Users] testing phase for 3.1
2010/8/18 Carsten Bock <lists(a)bock.info>fo>:
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(a)aliax.net>
8:09 p.m.
New subject: [SR-Users] testing phase for 3.1
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(a)aliax.net>
2010/8/18 Carsten Bock <lists(a)bock.info>fo>:
--
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...
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(a)aliax.net>
20 Aug
20 Aug
12:44 a.m.
New subject: [SR-Users] testing phase for 3.1
Hey,
"Iñaki Baz Castillo" <ibc(a)aliax.net> schrieb:
2010/8/18 Carsten Bock <lists(a)bock.info>fo>:
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
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 :)
30 Aug
30 Aug
6:07 p.m.
New subject: [SR-Users] testing phase for 3.1
Hey,
Timo Reimann wrote:
"Iñaki Baz Castillo" <ibc(a)aliax.net>
schrieb:
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
2010/8/18 Carsten Bock <lists(a)bock.info>fo>:
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 :). 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 :)
31 Aug
31 Aug
8:36 a.m.
New subject: [SR-Users] testing phase for 3.1
Hi,
if no one objects, i would push my changes into master then tonight....
Kind regards,
Carsten
2010/8/30 Timo Reimann <timo.reimann(a)1und1.de>de>:
Hey,
Timo Reimann wrote:
--
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(a)aliax.net> schrieb:
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
2010/8/18 Carsten Bock <lists(a)bock.info>fo>:
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 :). 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 :)
11:06 a.m.
New subject: [SR-Users] testing phase for 3.1
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
4994
days inactive
5008
days old
13 comments
4 participants
participants (4)
-
Carsten Bock -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Timo Reimann