[Kamailio-Users] [SR-Users] force_rtp_proxy() vis-a-vis BYE

Daniel-Constantin Mierla miconda at gmail.com
Tue Jul 7 13:22:26 CEST 2009



On 07/07/2009 12:41 PM, Alex Balashov wrote:
> Daniel-Constantin Mierla wrote:
>>
>>
>> On 07/07/2009 12:14 PM, Alex Balashov wrote:
>>>
>>> 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.
>
> 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.
 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/





More information about the sr-users mailing list