Hi,
first of all, I am new to the SIP world, so please forgive me if I ask anything dumb.
I am trying to set up a NAT-traversal SIP proxy, with the help of the nathelper module and rtpproxy. I only have access to the proxy and one softphone behind it.
I am facing two problems: when someone in the outer world wants to call my softphone (which is behind the proxy), the proxy forwards the INVITE message to itself and recurses until the mf_process_maxfwd_header() statement stops further processing. I am not sure how to handle this. My guess is that I should use the registrar module and when the proxy receives an INVITE message, it should use registered() method in order to know where to forward the request ; but I don't know how to do that. Help would be welcome.
My second problem is that when the peer hangs off the phone, I should receive a BYE message but I can't see it. Given I have no access on the other end, I guessed that the BYE message had been sent elsewhere. That's why I fixed the Contact header field. However, I still can't see actions coming from the outer phone. Any idea ?
(I didn't attached any packet dump for now because I think it can be more misleading than informative because there are two proxies on the same machine: one that is a tunnel broker to encapsulate VoIP traffic in HTTP, and the other one is OpenSER. Basically, every SIP session is being tunneled in HTTP, then the datagram in unwrapped by the first proxy and then forwarded to the second one, which is OpenSER. Nonetheless I would be glad to provide any packet dump upon request.)
My configuration file is attached. If you find any other mistakes or inconsistencies in this configuration file, please tell me.
Best regards,
Hi,
you should start with the config file from http://voip-info.org/wiki/view/OpenSER+And+RTPProxy It handles NAT traversal and user location.
Cheers, Ramona
Jeremie Le Hen wrote:
Hi,
first of all, I am new to the SIP world, so please forgive me if I ask anything dumb.
I am trying to set up a NAT-traversal SIP proxy, with the help of the nathelper module and rtpproxy. I only have access to the proxy and one softphone behind it.
I am facing two problems: when someone in the outer world wants to call my softphone (which is behind the proxy), the proxy forwards the INVITE message to itself and recurses until the mf_process_maxfwd_header() statement stops further processing. I am not sure how to handle this. My guess is that I should use the registrar module and when the proxy receives an INVITE message, it should use registered() method in order to know where to forward the request ; but I don't know how to do that. Help would be welcome.
My second problem is that when the peer hangs off the phone, I should receive a BYE message but I can't see it. Given I have no access on the other end, I guessed that the BYE message had been sent elsewhere. That's why I fixed the Contact header field. However, I still can't see actions coming from the outer phone. Any idea ?
(I didn't attached any packet dump for now because I think it can be more misleading than informative because there are two proxies on the same machine: one that is a tunnel broker to encapsulate VoIP traffic in HTTP, and the other one is OpenSER. Basically, every SIP session is being tunneled in HTTP, then the datagram in unwrapped by the first proxy and then forwarded to the second one, which is OpenSER. Nonetheless I would be glad to provide any packet dump upon request.)
My configuration file is attached. If you find any other mistakes or inconsistencies in this configuration file, please tell me.
Best regards,
# ----------- global configuration parameters ------------------------
log_facility=LOG_LOCAL0 unix_sock="/var/run/voipproxy/openser.sock" user=voipproxy group=voipproxy listen=1.2.3.4
# ------------------ module loading ---------------------------------- mpath="/usr/local/lib/openser/modules" loadmodule "nathelper.so" loadmodule "maxfwd.so" loadmodule "textops.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "registrar.so" loadmodule "usrloc.so" loadmodule "sl.so"
# 9Pass phone sets the Expires value to 3000, this is far too high. modparam("registrar", "max_expires", 600)
# modparam("registrar", "sip_natping_flag", 7)
modparam("nathelper", "rtpproxy_sock", "unix:/var/run/voipproxy/rtpproxy.sock")
# This parameter comes from a patch I got here # http://www.openser.org/pipermail/devel/2006-February/002103.html # and allows to force the Contact HF. modparam("nathelper", "contact_expander", "1.2.3.4:5060")
# ------------------ request-routing script --------------------------
# main routing logic
route { if (!mf_process_maxfwd_header("10")) { sl_send_reply("483", "Too many hops"); return; }
if (msg:len > max_len) { sl_send_reply("513", "Message too big"); return; };
loose_route();
if (method == "REGISTER") { fix_nated_register(); #fix_nated_contact(); #save_noreply("location"); } else { #lookup("htproxy"); if (method == "INVITE") { record_route(); force_rtp_proxy("r"); t_on_reply("1"); } else if (method == "BYE" || method == "CANCEL") { unforce_rtp_proxy(); }; };
fix_nated_contact();
/* * Set up reply processing and forward statefuly, so that we * don't bother rtpproxy each time we see a transaction. */ t_relay(); }
onreply_route[1] { if (status =~ "(183)|2[0-9][0-9]") { force_rtp_proxy("r"); }; }
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi Ramona,
you should start with the config file from http://voip-info.org/wiki/view/OpenSER+And+RTPProxy It handles NAT traversal and user location.
Thank you for your quick answer. I have a couple of questions about this configuration file.
1) I fumbled a bit through the various RFCs without - I must admit it - thorough attention, but I wasn't able to understand why record_route() should not be called with the "REGISTER" method.
2) Why fix_nated_contact() is not called in cas of a REGISTER method ? Instead fix_nated_register() is called, but I don't see the point in not fixing the Contact header field as well.
3) If loose_route() succeeds (by the way, what does the success of such a function means ?), the packet flow jumps to route[1], which is a dead-end path. This means when loose_route() is successful, we aren't going through the save/lookup magic. I have read what loose routing means in RFC3261 but I couldn't really understand what the point of this particular rule is.
Thank you for you help. Regards,