7 Jul
2009
7 Jul
'09
2:22 p.m.
On 07/07/2009 12:41 PM, Alex Balashov wrote:
Daniel-Constantin Mierla wrote:
From my point of view, since the
rtp proxying applies to particular
cases of SIP, audio/video calls, I would preferred to deal with only to
functions:
- rtpproxy_session_init(flags)
- rtpproxy_session_update()
First one to be used with initial invite and the second for replies,
re-invite, cancel, ack, bye. The other logic, like whether sdp is in
invite/200ok or 200ok/ack could be hidden inside the module and/or rtpproxy.
I think there is room to add these functions, calling inside the other
existing functions with the right flags. Existing functions can stay for
the sake of flexibility, for those willing to deal with more complex
config file coding.
Right now, I am not aware of the code that covers the all scenarios in
one invocation, but there can be done in the config with some routes
(partial pseudo-code):
route[rtp_session_init] {
if(!is_method("INVITE") || has_totag())
return;
if(!has_sdp())
{
setflag(nosdp);
return;
}
...
force_rtp_proxy();
}
route[rtp_session_update] {
if(is_method("CANCEL|BYE") {
unforce_rtp_proxy();
return;
}
if(is_reply()) {
if(isflagset(nosdp)) {
...
} else {
...
}
return;
}
if(is_method("ACK") && has_sdp())
{
...
}
}
cc-ed the k users list, just in case someone pops up a better idea.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/
On 07/07/2009 12:14 PM, Alex Balashov wrote:
I appreciate your efforts to find out, thank you.
My main concern, aside from whether to use unforce_rtp_proxy(), is to
know what is the orthodox way to manipulate rtpproxy in response to
CANCELs (at early dialog state as well as not) and BYEs. Also, per
RFC 3261 an SDP answer may also come in an ACK, so I guess that needs
to be handled too.
Just wondering if there is some reference implementation or
boilerplate code that covers all the scenarios.
According to the Kamailio 1.5.x docs, force_rtp_proxy() is
deprecated and rtpproxy_offer() and rtpproxy_answer() should be used
instead.
Does that mean unforce_rtp_proxy() is also deprecated?
seems this one is not deprecated. I am still using the old style, I
am going to look at the code for more insights.
From docs, rtpproxy_offer() and rtpproxy_answer() are like aliases
to force_rtp_proxy(), having a more meaningful naming.