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
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
