21 Jul
2010
21 Jul
'10
4 a.m.
Hello,
as discussed during our devel meeting, next major release 3.1 is
scheduled for this autumn. Therefore the freezing should happen soon.
Would be 2 weeks from now enough for everyone to push planned new
features to repo?
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/
21 Jul
21 Jul
6:47 a.m.
New subject: [SR-Users] freezing for major release 3.1
Hi,
for me, it's fine. I have some changes, which i will commit to the trunk in
the next few days:
Nathelper-Improvements:
- allow the configuration of a timeout socket which will be sent to the
RTP-Proxy (i have a patch for the rtpproxy in order to terminate calls via
XML-RPC)
- if time allows and the change is finished by then: Retrieve RTP-Statistics
from the RTP-Proxy.
Carsten
2010/7/21 Daniel-Constantin Mierla <miconda(a)gmail.com>
Hello,
as discussed during our devel meeting, next major release 3.1 is scheduled
for this autumn. Therefore the freezing should happen soon. Would be 2 weeks
from now enough for everyone to push planned new features to repo?
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/
_______________________________________________
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
--
Carsten Bock
Schomburgstr. 80
22767 Hamburg
Germany
Mobile +49 179 2021244
Home +49 40 34927217
Fax +49 40 34927218
mailto:carsten@bock.info
6:57 a.m.
New subject: [SR-Users] freezing for major release 3.1
2010/7/21 Carsten Bock <lists(a)bock.info>fo>:
- allow the configuration of a timeout socket which
will be sent to the
RTP-Proxy (i have a patch for the rtpproxy in order to terminate calls via
XML-RPC)
Couuld you please ellaborate this a bit more? it sound really interesting :)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
8:50 a.m.
New subject: [SR-Users] freezing for major release 3.1
Hi,
it is rather simple:
The command specification (http://rtpproxy.org/wiki/RTPproxy/Protocol)
states the following:
Update session, creating a new one if it doesn't exist.
U[args] callid addr port from_tag [to_tag [notify_socket [notify_args]]]
The NATHelper Module currently does not send the optional notify
socket to the RTPProxy. The enhancement makes this "notify_socket"
configurable and will send it to the RTP-Proxy, if set. On the other
end, i have modified the RTP-Proxy to check, if it is an HTTP-Socket
(XML-RPC) or an Unix-Socket. If it is a Unix-Socket, it works as it
does now. If the Socket starts with "http://", it will query the Proxy
by executing "dlg_list" with the "Call-ID" and the
"From-Tag". If the
dialog is found, it will call "dlg_end_dlg" with the according
parameters...
Rather simple - that's it. Currently i have this running using some
wrappers in Python, which is rather quick and dirty.
Kind regards,
Carsten
2010/7/21 Iñaki Baz Castillo <ibc(a)aliax.net>
2010/7/21 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
- allow the configuration of a timeout socket
which will be sent to the
RTP-Proxy (i have a patch for the rtpproxy in order to terminate calls via
XML-RPC)
Couuld you please ellaborate this a bit more? it sound really interesting :)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
9:03 a.m.
New subject: [SR-Users] freezing for major release 3.1
2010/7/21 Carsten Bock <lists(a)bock.info>fo>:
Hi,
it is rather simple:
The command specification (http://rtpproxy.org/wiki/RTPproxy/Protocol)
states the following:
Update session, creating a new one if it doesn't exist.
U[args] callid addr port from_tag [to_tag [notify_socket [notify_args]]]
The NATHelper Module currently does not send the optional notify
socket to the RTPProxy. The enhancement makes this "notify_socket"
configurable and will send it to the RTP-Proxy, if set. On the other
end, i have modified the RTP-Proxy to check, if it is an HTTP-Socket
(XML-RPC) or an Unix-Socket. If it is a Unix-Socket, it works as it
does now. If the Socket starts with "http://", it will query the Proxy
by executing "dlg_list" with the "Call-ID" and the
"From-Tag". If the
dialog is found, it will call "dlg_end_dlg" with the according
parameters...
It's great :)
However take into account that "dlg_end_dlg" just works for confirmed
dialogs (state 4).
There are new fixes about it by Timo so it doesn't leak when running
"dlg_end_dlg" for an in-progress dialog.
Also I think that a new commit from Time makes "dlg_end_dlg" just to
work in case the dialog state is 4 so nothing would be required from
the Rtpproxy.
Terminating in-progress dialog is still not implemented (but planned AFAIK).
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
9:30 a.m.
New subject: [SR-Users] freezing for major release 3.1
Iñaki Baz Castillo wrote:
2010/7/21 Carsten Bock <lists(a)bock.info>fo>:
All correct; little addendum: Proxy-initiated dialog termination works
both in state 3 (2xx response received but ACK request from UAC yet
missing) and 4 (2xx response and ACK request received) because the
dialog module stores caller data already in state 3. I neglected that
detail in the commit message as both states are denoted "committed" in
Kamailio but it doesn't make much of a difference.
Cheers,
--Timo
Hi,
it is rather simple:
The command specification (http://rtpproxy.org/wiki/RTPproxy/Protocol)
states the following:
Update session, creating a new one if it doesn't exist.
U[args] callid addr port from_tag [to_tag [notify_socket [notify_args]]]
The NATHelper Module currently does not send the optional notify
socket to the RTPProxy. The enhancement makes this "notify_socket"
configurable and will send it to the RTP-Proxy, if set. On the other
end, i have modified the RTP-Proxy to check, if it is an HTTP-Socket
(XML-RPC) or an Unix-Socket. If it is a Unix-Socket, it works as it
does now. If the Socket starts with "http://", it will query the Proxy
by executing "dlg_list" with the "Call-ID" and the
"From-Tag". If the
dialog is found, it will call "dlg_end_dlg" with the according
parameters...
It's great :)
However take into account that "dlg_end_dlg" just works for confirmed
dialogs (state 4).
There are new fixes about it by Timo so it doesn't leak when running
"dlg_end_dlg" for an in-progress dialog.
Also I think that a new commit from Time makes "dlg_end_dlg" just to
work in case the dialog state is 4 so nothing would be required from
the Rtpproxy.
Terminating in-progress dialog is still not implemented (but planned AFAIK).
9:36 a.m.
New subject: [SR-Users] freezing for major release 3.1
2010/7/21 Timo Reimann <timo.reimann(a)1und1.de>de>:
All correct; little addendum: Proxy-initiated dialog
termination works
both in state 3 (2xx response received but ACK request from UAC yet
missing) and 4 (2xx response and ACK request received) because the
dialog module stores caller data already in state 3.
Sure, from the point of view of a SIP dialog, it's established after
the 200 OK, regardless the ACK arrives or not as the ACK doesn't
provide new info to the SIP dialog (perhaps it does for the media
negociation, but just it).
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
10:12 a.m.
New subject: [SR-Users] freezing for major release 3.1
Timo Reimann wrote:
Iñaki Baz Castillo wrote:
s/committed/confirmed/
--Timo
2010/7/21 Carsten Bock <lists(a)bock.info>fo>:
All correct; little addendum: Proxy-initiated dialog termination works
both in state 3 (2xx response received but ACK request from UAC yet
missing) and 4 (2xx response and ACK request received) because the
dialog module stores caller data already in state 3. I neglected that
detail in the commit message as both states are denoted "committed" in
Kamailio but it doesn't make much of a difference. Hi,
it is rather simple:
The command specification (http://rtpproxy.org/wiki/RTPproxy/Protocol)
states the following:
Update session, creating a new one if it doesn't exist.
U[args] callid addr port from_tag [to_tag [notify_socket [notify_args]]]
The NATHelper Module currently does not send the optional notify
socket to the RTPProxy. The enhancement makes this "notify_socket"
configurable and will send it to the RTP-Proxy, if set. On the other
end, i have modified the RTP-Proxy to check, if it is an HTTP-Socket
(XML-RPC) or an Unix-Socket. If it is a Unix-Socket, it works as it
does now. If the Socket starts with "http://", it will query the Proxy
by executing "dlg_list" with the "Call-ID" and the
"From-Tag". If the
dialog is found, it will call "dlg_end_dlg" with the according
parameters...
It's great :)
However take into account that "dlg_end_dlg" just works for confirmed
dialogs (state 4).
There are new fixes about it by Timo so it doesn't leak when running
"dlg_end_dlg" for an in-progress dialog.
Also I think that a new commit from Time makes "dlg_end_dlg" just to
work in case the dialog state is 4 so nothing would be required from
the Rtpproxy.
Terminating in-progress dialog is still not implemented (but planned AFAIK). 
3 Aug
3 Aug
12:18 p.m.
On Wednesday 21 July 2010, Daniel-Constantin Mierla wrote:
as discussed during our devel meeting, next major
release 3.1 is
scheduled for this autumn. Therefore the freezing should happen soon.
Would be 2 weeks from now enough for everyone to push planned new
features to repo?
Hi Daniel,
Marius B. is working on some last cleanups for one module that we would like
to add, but it should be ready and commited tomorrow afternoon or so.
Cheers,
Henning
4:39 p.m.
I have a fix for nathelper module. The commit will come by the end of
the week due to traveling.
Regards,
Ovidiu Sas
On Tue, Aug 3, 2010 at 12:18 PM, Henning Westerholt
<henning.westerholt(a)1und1.de> wrote:
On Wednesday 21 July 2010, Daniel-Constantin Mierla
wrote:
as discussed during our devel meeting, next major
release 3.1 is
scheduled for this autumn. Therefore the freezing should happen soon.
Would be 2 weeks from now enough for everyone to push planned new
features to repo?
Hi Daniel,
Marius B. is working on some last cleanups for one module that we would like
to add, but it should be ready and commited tomorrow afternoon or so.
Cheers,
Henning
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
5264
days inactive
5277
days old
9 comments
6 participants
participants (6)
-
Carsten Bock -
Daniel-Constantin Mierla -
Henning Westerholt -
Iñaki Baz Castillo -
Ovidiu Sas -
Timo Reimann