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
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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2010/7/21 Carsten Bock lists@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 :)
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@aliax.net
2010/7/21 Carsten Bock lists@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@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
2010/7/21 Carsten Bock lists@bock.info:
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 wrote:
2010/7/21 Carsten Bock lists@bock.info:
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).
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
2010/7/21 Timo Reimann timo.reimann@1und1.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.
Timo Reimann wrote:
Iñaki Baz Castillo wrote:
2010/7/21 Carsten Bock lists@bock.info:
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).
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.
s/committed/confirmed/
--Timo
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
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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-
Carsten Bock -
Daniel-Constantin Mierla -
Henning Westerholt -
Iñaki Baz Castillo -
Ovidiu Sas -
Timo Reimann