2009/1/24 mayamatakeshi mayamatakeshi@gmail.com:
Hello, I'm trying to understand this sample cfg: http://voip-info.org/wiki/view/OpenSER+And+RTPProxy
This cfg is used as foundation for some of our cfg files here but nobody is sure about exactly how some things work. So I'm trying to clear things up. In particular, I am clueless about why there is code removing "nat=yes" from the URI and adding it to the Contact header (actually I don't know what is its meaning. I suppose this is a way of a client advertising that it is behind NAT, but I couldn't find which RFC defines this):
subst_uri('/(sip:.*);nat=yes/\1/')
search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes');
Is this something that always must be done when dealing with nat or it was a particular situation that the writer of the cfg had to workaround? I'm rewriting our cfg file (to be used with m4) and I'm trying to remove unnecessary things.
The Contact header of the caller (in the initial INVITE) and the Contact header of the callee (in the 200 OK) remain during a dialog. This is, if the caller Contact contains "sip:alice@domain;param=qwerty" then when the callee creates an in-dialog request in that dialog (BYE, re-INVITE, INFO...) the RURI will be "sip:alice@domain;param=qwerty".
In this way, the trick is done by the proxy who adds that parameter "nat=yes" to the Contact of both (caller and callee) when the call is detected to be behind NAT. In this way, for in-dialog requests the proxy just must examine the RURI to know if the related dialog has NAT or not, and just in that case reuse RtpProxy and so.
Another way is the proxy adding "nat=yes" parameter to the Record-Route header in the initial INVITE, since RR header will become a Route header in every in-dialog message for that dialog.
Another thing in the cfg: in case a reinvite is issued, should not unforce_rtp_proxy be called before force_rtp_proxy is called again? Could this lead to having rtpproxy leaking resources?
No, you should call RtpProxy with "l" parameter so it just will take an action is there is *already* a RTP session for that dialog.