24 Jan
2009
24 Jan
'09
7:06 p.m.
2009/1/24 mayamatakeshi <mayamatakeshi(a)gmail.com>om>:
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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>