Re: [SR-Users] [sr-dev] freezing for major release 3.1

2010-07-21 Thread Iñaki Baz Castillo
2010/7/21 Carsten Bock li...@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
i...@aliax.net

___
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


Re: [SR-Users] [sr-dev] freezing for major release 3.1

2010-07-21 Thread Carsten Bock
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 i...@aliax.net

 2010/7/21 Carsten Bock li...@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
 i...@aliax.net



--
Carsten Bock
Schomburgstr. 80
22767 Hamburg
Germany

Mobile +49 179 2021244
Home +49 40 34927217
Fax +49 40 34927218
mailto:cars...@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


Re: [SR-Users] [sr-dev] freezing for major release 3.1

2010-07-21 Thread Iñaki Baz Castillo
2010/7/21 Carsten Bock li...@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
i...@aliax.net

___
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


Re: [SR-Users] [sr-dev] freezing for major release 3.1

2010-07-21 Thread Timo Reimann
Iñaki Baz Castillo wrote:
 2010/7/21 Carsten Bock li...@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

___
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


Re: [SR-Users] [sr-dev] freezing for major release 3.1

2010-07-21 Thread Iñaki Baz Castillo
2010/7/21 Timo Reimann timo.reim...@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.



-- 
Iñaki Baz Castillo
i...@aliax.net

___
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


Re: [SR-Users] [sr-dev] freezing for major release 3.1

2010-07-21 Thread Timo Reimann
Timo Reimann wrote:
 Iñaki Baz Castillo wrote:
 2010/7/21 Carsten Bock li...@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

___
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


Re: [SR-Users] [sr-dev] freezing for major release 3.1

2010-07-21 Thread Iñaki Baz Castillo
2010/7/21 Timo Reimann timo.reim...@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. 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/

commited would be a cool new state for SIP dialogs, and also merged XD

-- 
Iñaki Baz Castillo
i...@aliax.net

___
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


Re: [SR-Users] [sr-dev] freezing for major release 3.1

2010-07-21 Thread Timo Reimann
Iñaki Baz Castillo wrote:
 2010/7/21 Timo Reimann timo.reim...@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. 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/
 
 commited would be a cool new state for SIP dialogs, and also merged XD

Oh how I wish I could revert some of the dialogs I established in the
past. ;)


Cheers,

--Timo

___
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