[OpenSIPS-Users] rtpproxy sends rtp from caller to callee before 200OK

[Răzvan Crainea]

Hi, Marco!

 From RTPProxy point of view, you can't differentiate between SIP 
replies, because for all of them you call the same function - 
rtpproxy_answer().
Now, if the client decides to send RTP for 183 (and indeed, I've seen 
this several times), there's not that much that you can do. Although 
it's kind of a hack, all I can think of is to not call rtpproxy_answer() 
for 180/183 and strip the body to prevent the client from sending RTP 
directly to the callee.
I hope this works for you.

Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 01/21/2015 04:07 PM, Marco Hierl wrote:
>
> Dear all,
>
> first of all I need to apologize that I was not able to find 
> information about this issue although I’m sure that I’m not the first 
> one complaining!
>
> The caller is sending an INVITE via OpenSIPS and rtpproxy_offer() is 
> executed, callee answers with REPLY 180 or REPLY 183 (with SDP) and 
> rtpproxy_answer() is made. In this status it should be ok that the rtp 
> stream from callee to caller is transferred via the rtpproxy (e.g. for 
> announcements), but I can see that rtp stream from caller to callee is 
> transferred too!!! This means that there can be a conversation without 
> receiving the 200OK and what is the real problem: that means (at least 
> for me) they can talk to each other without any charging !! A timer 
> will stop the conversion after the a while, but this can take time.
>
> How can I overcome this problem? How can prevent RTP to be send to the 
> callee before REPLY 200 is received?
>
> I can’t find any help in the RTPproxy protocol 
> http://www.b2bua.org/wiki/RTPproxy/Protocol, nor in the rtpproxy 
> module description in OpenSIPS.
>
> Thanks for your ideas, and best regards
>
>   Marco
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20150122/ea85283b/attachment.htm>