opensips.cfg file example with use_media_proxy and end_media_session.

opensips.cfg file with use_media_proxy() and end_media_session()  :

1. # log levels:
2. # 1 warn
3. # 2 notice
4. # 3 info
5. # 4 debug (default)
6.                                    # globals
7. listen=udp:sip.example.com:5060
8. fifo="/tmp/openser_fifo"
9.  
10.                                  # load modules
11. loadmodule "/usr/lib/openser/modules/sl.so"
12. loadmodule "/usr/lib/openser/modules/tm.so"
13. loadmodule "/usr/lib/openser/modules/rr.so"
14. loadmodule "/usr/lib/openser/modules/maxfwd.so"
15. loadmodule "/usr/lib/openser/modules/usrloc.so"
16. loadmodule "/usr/lib/openser/modules/registrar.so"
17. loadmodule "/usr/lib/openser/modules/textops.so"
18. loadmodule "/usr/lib/openser/modules/auth.so"
19. loadmodule "/usr/lib/openser/modules/domain.so"
20. loadmodule "/usr/lib/openser/modules/mediaproxy.so"
21. loadmodule "/usr/lib/openser/modules/acc.so"
22. loadmodule "/usr/lib/openser/modules/exec.so"
23. loadmodule "/usr/lib/openser/modules/xlog.so"
24.  
25.  
26.                                 # module params
27. # rr
28. # add value to ;lr param to make some broken UAs happy
29. modparam("rr", "enable_full_lr", 1)
30.  
31. # mediaproxy
32. #modparam("mediaproxy", "mediaproxy_socket", "/var/run/proxydispatcher.sock")
33. #modparam("mediaproxy", "natping_interval", 60)
34. modparam("registrar", "nat_flag", 2)
35.  
36.                            # request routing logic
37. alias="example.com"
38. alias="voip.example.com"
39. route
40. {
41.     # sanity checks
42.     if (!mf_process_maxfwd_header("10"))
43.     {
44.         sl_send_reply("483","Too Many Hops");
45.         exit;
46.     }
47.     if (msg:len >= max_len)
48.     {
49.         sl_send_reply("513", "Message too big");
50.         exit;
51.     }
52.  
53.     # apply loose (normal) routing rules
54.     loose_route();
55.  
56.     # NAT test
57.     if (client_nat_test("3") && !search("^Route:"))
58.     {
59.         setflag(2); # flag for NAT
60.         force_rport();
61.         fix_contact();
62.         append_hf("P-hint: NAT\r\n");
63.     }
64.  
65.     # outbound routing if not for me
66.     lookup("aliases");
67.     if (uri != myself)
68.     {
69.         route(1);
70.         exit;
71.     }
72.  
73.     # Registration
74.     if (method == "REGISTER")
75.     {
76.         save("location"); # simple no-auth registration
77.         exit;
78.     }
79.  
80.     if (method == "INVITE")
81.     {
82.         # enable Record-Route
83.         record_route();
84.  
85.         # Is this to one of our numbers
86.         if (lookup("location"))
87.         {
88.             append_hf("P-hint: userloc applied\r\n");
89.         }
90.         else
91.         {
92.             sl_send_reply("404","Not found");
93.         }
94.     }
95.     route(1);
96. }
97.  
98.  
99. route[1]
100. {
101.     if (isflagset(2))
102.     {
103.         if (method == "INVITE")
104.         {
105.             t_on_reply("1");
106.             t_on_failure("1");
107.             use_media_proxy();
108.         }
109.         else if (method == "BYE" || method == "CANCEL")
110.         {
111.             end_media_session();
112.         }
113.     }
114.  
115.     # send it out now; use stateful forwarding as it works reliably
116.     # even for UDP2TCP
117.     if (!t_relay())
118.     {
119.         sl_reply_error();
120.     }
121.     exit;
122. }
123.  
124. onreply_route[1]
125. {
126.     if (status =~ "(183)|(2[0-9][0-9])")
127.     {
128.         if (client_nat_test("1"))
129.         {
130.             fix_contact();
131.         }
132.         use_media_proxy();
133.     }
134. }
135.  
136. failure_route[1]
137. {
138.     end_media_session();
139. }
140.  
141. # The perl filetype works pretty well for this
142. # vim: filetype=perl

How Mediaproxy works ?? how opensips and mediaproxy works together to solve NAT problems

This NAT traversal solution operates by placing a media relay in the middle between 2 SIP user-agents. It mangles the SDP messages for both of them in a way that will make the parties talk with the relay while they think they talk directly with each other.

Mediaproxy consists of 2 components:

• The OpenSIPS mediaproxy module
• An external application called MediaProxy which employs a dispatcher and multiple distributed media relays. This is available from http://ag-projects.com/MediaProxy.html (version 2.0.0 or newer is required by this module).

The mediaproxy dispatcher runs on the same machine as OpenSIPS and its purpose is to select a media relay for a call. The media relay may run on the same machine as the dispatcher or on multiple remote hosts and its purpose is to forward the streams between the calling parties. To find out more about the architecture of MediaProxy please read the documentation that comes with it.

To be able to act as a relay between the 2 user agents, the machine(s) running the module/proxy server must have a public IP address.

OpenSIPS will ask the media relay to allocate as many ports as there are media streams in the SDP offer and answer. The media relay will send back to OpenSIPS the IP address and port(s) for them. Then OpenSIPS will replace the original contact IP and RTP ports from the SDP messages with the ones provided by the media relay. By doing this, both user agents will try to contact the media relay instead of communicating directly with each other. Once the user agents contact the media relay, it will record the addresses they came from and will know where to forward packets received from the other endpoint. This is needed because the address/port the NAT box will allocate for the media streams is not known before they actually leave the NAT box. However the address of the media relay is always known (being a public IP) so the 2 endpoints know where to connect. After they do so, the relay learns their addresses and can forward packets between them.

The SIP clients that will work transparently behind NAT when using mediaproxy, are the so-called symmetric clients. The symmetric clients have the particularity that use the same port to send and receive data. This must be true for both signaling and media for a client to work transparently with mediaproxy without any configuration on the NAT box.

engage_media_proxy()

Trigger the use of MediaProxy for all the dialog requests and replies that have an SDP body. This needs to be called only once for the first INVITE in a dialog. After that it will use the dialog module to trace the dialog and automatically call use_media_proxy() on every request and reply that belongs to the dialog and has an SDP body. When the dialog ends it will also call automatically end_media_session(). All of these are called internally on dialog callbacks, so for this function to work, the dialog module must be loaded and configured.

This function is an advanced mechanism to use a media relay without having to manually call a function on each message that belongs to the dialog. However this method is less flexible, because once things were set in motion by calling this function on the first INVITE, it cannot be stopped, not even by calling end_media_session(). It will only stop when the dialog ends. Until then it will modify the SDP content of every in-dialog message to make it use a media relay. If one needs more control over the process, like starting to use mediaproxy only later in the failure route, or stopping to use mediaproxy in the failure route, then the use_media_proxy and end_media_session functions should be used, and manually called as appropriate. Using this function should NOT be mixed with either of use_media_proxy() or end_media_session().

This function can be used from REQUEST_ROUTE.

Example 1.8. Using the engage_media_proxy function

...
if (method==INVITE && !has_totag()) {
    # We can also use a specific media relay if we need to
    #$avp(media_relay) = "1.2.3.4";
    engage_media_proxy();
}
...
        

RTP proxy and How RTP proxy works ?? (source:VOIP-INFO)

About RTPproxy :

The RTPproxy is a high-performance software proxy for RTP streams that can work together with SER, OpenSER or Sippy B2BUA. Originally created for handling NAT scenarious it can also act as a generic media relay as well as gateway RTP sessions between IPv4 and IPv6 networks. RTPproxy was developed by Maxim Sobolev and now is being actively maintained by the Sippy Software, Inc..

                  The RTPproxy supports some advanced features, such as remote control mode, allowing building scalable distributed SIP VoIP networks. The nathelper module included into the SER or OpenSER SIP Proxy software as well as Sippy B2BUA allow using multiple RTPproxy instances running on remote machines for fault-tolerance and load-balancing purposes.

The software also supports video relaying and RTP session recording.

How it works :

• When SIP Proxy receives INVITE request, it extracts call-id from it and communicates it to the proxy via Unix domain socket. RTPProxy looks for an existing sessions with such id, if the session exists it returns UDP port for that session, if not, then it creates a new session, binds to a first empty UDP port from the range specified at the compile time and returns number of that port to a SIP Proxy. After receiving reply from the proxy, SIP Proxy replaces media ip:port in the SDP to point to the proxy and forwards the request as usual;
• when SIP Proxy receives non-negative SIP reply with SDP it again extracts call-id from it and communicates it to the proxy. In this case the proxy does not allocate a new session if it doesn't exist, but simply performs a lookup among existing sessions and returns either a port number if the session is found, or error code indicating that there is no session with such id. After receiving positive reply from the RTPproxy, SIP Proxy replaces media ip:port in the SIP Proxy reply to point to the proxy and forwards reply as usual;
• after the session has been created, the proxy listens on the port it has allocated for that session and waits to receive at least one UDP packet from each of the two parties participating in the call. Once these packet are received, the proxy fills one of two ip:port structures associated with each call with the source ip:port of that packet. When both structures are filled in, the proxy starts relaying UDP packets between parties;

the proxy tracks idle time for each of existing sessions (i.e. the time within which there were no packets relayed), and automatically cleans up a sessions whose idle times exceed the value specified at compile time (60 seconds by default).