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

[Timo Reimann]

Timo Reimann wrote:
> Iñaki Baz Castillo wrote:
>> 2010/7/21 Carsten Bock <lists at 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