23 Sep
2010
23 Sep
'10
8:50 p.m.
What you propose is a new functionality. I would prefer a new name
(engage_rtp_proxy) for this function and still drop the old
force_rtp_proxy.
ovidiu,
it may be confusing to call the new function engage_rtp_proxy, because
similar name is used in mediaproxy module for a dialog based function
that tries to handle the whole dialog, but fails to address important
issues, such as forking.
if the idea is not to have a dialog based thing, then function names
like use_rtp_proxy/end_rtp_session would be better.
-- juha
23 Sep
23 Sep
8:57 p.m.
Without using the dialog module, it will be difficult to keep track of
the rtpproxy session for the duration of the call.
It can be tracked for the duration of the transaction and in this case
we could have:
- use_rtp_proxy: for the creation of the rtpproxy session;
- update_rtp_proxy: for updating an rtpproxy session for an in-dialog request;
- end_rtp_session is just like unforce_rtp_proxy.
Regards,
Ovidiu Sas
On Thu, Sep 23, 2010 at 11:50 AM, Juha Heinanen <jh(a)tutpro.com> wrote:
What you propose is a new functionality. I would
prefer a new name
(engage_rtp_proxy) for this function and still drop the old
force_rtp_proxy.
ovidiu,
it may be confusing to call the new function engage_rtp_proxy, because
similar name is used in mediaproxy module for a dialog based function
that tries to handle the whole dialog, but fails to address important
issues, such as forking.
if the idea is not to have a dialog based thing, then function names
like use_rtp_proxy/end_rtp_session would be better.
-- juha
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
9:04 p.m.
Ovidiu Sas writes:
Without using the dialog module, it will be difficult
to keep track of
the rtpproxy session for the duration of the call.
what do you mean? use_mediaproxy for invites and re-invites plus
end_media_session have worked fine for me.
It can be tracked for the duration of the transaction
and in this case
we could have:
- use_rtp_proxy: for the creation of the rtpproxy session;
- update_rtp_proxy: for updating an rtpproxy session for an in-dialog request;
- end_rtp_session is just like unforce_rtp_proxy.
those names sound ok to me.
-- juha
9:12 p.m.
On Thu, Sep 23, 2010 at 12:04 PM, Juha Heinanen <jh(a)tutpro.com> wrote:
Ovidiu Sas writes:
I was under the impression that Klaus's request was to invoke the
function only _once_ per call (reINVITEs to be handled automatically).
Maybe I was wrong.
Regards,
Ovidiu Sas
Without using the dialog module, it will be
difficult to keep track of
the rtpproxy session for the duration of the call.
what do you mean? use_mediaproxy for invites and re-invites plus
end_media_session have worked fine for me.
9:20 p.m.
Ovidiu Sas writes:
I was under the impression that Klaus's request
was to invoke the
function only _once_ per call (reINVITEs to be handled automatically).
Maybe I was wrong.
if that is done, then the problems are likely to be the same as with
engage_mediaproxy, which makes the function useless.
-- juha
9:26 p.m.
Ovidiu-
Without using the dialog module, it will be difficult
to keep track of
the rtpproxy session for the duration of the call.
It can be tracked for the duration of the transaction and in this case
we could have:
- use_rtp_proxy: for the creation of the rtpproxy session;
- update_rtp_proxy: for updating an rtpproxy session for an in-dialog request;
- end_rtp_session is just like unforce_rtp_proxy.
Please allow me to suggest:
- create_rtp_session (or start_rtp_session)
- update_rtp_session
- end_rtp_session
It seems to me that the use of "proxy" is redundant... Kamailio is already a
proxy.
They key thing is when RTP gets involved.
-Jeff
On Thu, Sep 23, 2010 at 11:50 AM, Juha Heinanen
<jh(a)tutpro.com> wrote:
> What you propose is a new functionality. I would prefer a new name
> (engage_rtp_proxy) for this function and still drop the old
> force_rtp_proxy.
>
> ovidiu,
>
> it may be confusing to call the new function engage_rtp_proxy, because
> similar name is used in mediaproxy module for a dialog based function
> that tries to handle the whole dialog, but fails to address important
> issues, such as forking.
>
> if the idea is not to have a dialog based thing, then function names
> like use_rtp_proxy/end_rtp_session would be better.
>
> -- juha
9:38 p.m.
I second this.
On Thu, Sep 23, 2010 at 11:33 AM, Juha Heinanen <jh(a)tutpro.com> wrote:
Jeff Brower writes:
Please allow me to suggest:
- create_rtp_session (or start_rtp_session)
- update_rtp_session
- end_rtp_session
these sound really clear to me.
-- juha
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
9:45 p.m.
All good so far ...
Now we need someone to implement this new feature for the next 3.2.x release :)
Regards,
Ovidiu Sas
On Thu, Sep 23, 2010 at 12:33 PM, Juha Heinanen <jh(a)tutpro.com> wrote:
Jeff Brower writes:
Please allow me to suggest:
- create_rtp_session (or start_rtp_session)
- update_rtp_session
- end_rtp_session
these sound really clear to me.
-- juha 
29 Sep
29 Sep
3:09 p.m.
2010/9/23 Ovidiu Sas <osas(a)voipembedded.com>om>:
Without using the dialog module, it will be difficult
to keep track of
the rtpproxy session for the duration of the call.
Right, but current dialog module fails in several cases as explained
in the wiki [*], so any cool feature depending on "dialog" would do
better by waiting for improvements in dialog module :)
[*]
http://www.openser-project.org/dokuwiki/doku.php/modules-new-design:dialog-…
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
12 Oct
12 Oct
8:58 p.m.
Having a single function per transaction to deal with rtpproxy
sessions has some issues.
Let's imagine the following scenario:
- sip-router is used in bridged mode;
- rtpproxy is configured in bridged mode.
Let's assume that a call is made from the internal interface to the
external one. Proper flags needs to be set in order to have a correct
RTP bridging. Now, if the call fails and it needs to be redirected
back into the internal network, the flags needs to be updated and this
it defeats the purpose of having a new single function to be invoked
per transaction.
Mediaproxy doesn't have this issue because it doesn't have support for bridging.
Regards,
Ovidiu Sas
On Thu, Sep 23, 2010 at 12:04 PM, Juha Heinanen <jh(a)tutpro.com> wrote:
Ovidiu Sas writes:
Without using the dialog module, it will be
difficult to keep track of
the rtpproxy session for the duration of the call.
what do you mean? use_mediaproxy for invites and re-invites plus
end_media_session have worked fine for me.
It can be tracked for the duration of the
transaction and in this case
we could have:
- use_rtp_proxy: for the creation of the rtpproxy session;
- update_rtp_proxy: for updating an rtpproxy session for an in-dialog request;
- end_rtp_session is just like unforce_rtp_proxy.
those names sound ok to me.
-- juha
4946
days inactive
4965
days old
10 comments
5 participants
participants (5)
-
Brandon Armstead -
Iñaki Baz Castillo -
Jeff Brower -
Juha Heinanen -
Ovidiu Sas