Hi Klaus,<br><br>For me the same problem , But problem in Bye message , openser system didn't recieve the Bye request from the UAC's.....<br><br>When its connected Behind the NAT with Different networks...<br>IN local network its really fine...
<br><br>that means Not working in outside the world..<br><br><div><span class="gmail_quote">On 8/2/06, <b class="gmail_sendername">Klaus Darilion</b> <<a href="mailto:klaus.mailinglists@pernau.at">klaus.mailinglists@pernau.at
</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Carsten!<br><br>First I would differ between ACK and CANCEL.<br><br>
If you use statefull forwarding, then it is sufficient to just t_relay,<br>as tm will take care of hop-by-hop canceling. There is no need to<br>rewrite the R-URI. There is only one problem: If the INVITE processing<br>takes more time, than it may happen that the CANCEL hits the tm module
<br>before the tm module created a transaction. Thus, I discard CANCEL<br>without existing transactions.<br><br>ACK: There are 3 kinds of possible ACK.<br>1. stateless, e.g. if you use sl_send_reply("404",""), then the client
<br>will send a "stateless" ACK. This ACK will be absorbed by openser as<br>soon as it is received and will never enter the routing logic. Thus, we<br>do not have to care about them.<br><br>2. statefull, sucessful call: The INVITE was answered with 200, thus the
<br>caller sends an ACK to the callee. This ACK is in-dialog, and thus<br>should be routed by the loose_route block (no need to rewrite any URI)<br><br>3. statefull, unsuccessful call: The call was rejected or cancelled.<br>
Thus, we have hop-by-hop ACKs. Thus, the ACK must be handled to the tm<br>moudle, which takes care of it (no need to rewrite any URI).<br><br>here is how I handle ACK and CANCEL. I did not had any issues with this<br>(running now since 1 year).
<br><br><br> if ( is_method("CANCEL") && !t_check_trans() ) {<br> # CANCEL without matching INVITE transaction, ignore<br> # may happen if the INVITE is slower than the CANCEL<br> # ignore the CANCEL, as the client will retransmit it, and maybe
<br>next time<br> # the INVITE transaction is already created<br> xlog("L_WARN","$ci CANCEL without matching transaction ... ignore<br>and discard.\n");<br> exit;<br> }<br> route(8); # disable mediaproxy (needs to see valid CANCEL requests)
<br> force_send_socket(<a href="http://83.136.32.160:5060">83.136.32.160:5060</a>); # force port 5060 as sending port<br> if ( is_method("CANCEL") ) {<br> # CANCEL with matching INVITE transaction, just
<br> # t_relay<br> xlog("L_INFO","$ci CANCEL with matching transaction ... t_relay.\n");<br> t_relay();<br> exit;<br> }<br> # check every message for Remote-Party-Id: header and remove it
<br> if (is_present_hf("Remote-Party-ID")) {<br> xlog("L_INFO", "$ci Remote-Party-ID header present ...removing\n");<br> remove_hf("Remote-Party-ID");<br> }<br> if (loose_route()) {
<br> # loose route requests are not authenticated<br> xlog("L_INFO","$ci beginning loose_route processing...\n");<br> route(32); # handle in-dialog requests<br> exit;<br> }<br> if ( is_method("ACK") ) {
<br> if ( t_check_trans() ) {<br> # non loose-route, but stateful ACK; must be an ACK after a 487<br> xlog("L_INFO","$ci local end-to-end ACK for an existent INVITE<br>transaction detected ...t_relay()\n");
<br> t_relay();<br> } else {<br> xlog("L_WARN","$ci ACK without matching transaction ... ignore<br>and discard.\n");<br> }<br> exit;<br> }<br> if ( has_totag() ) {<br> # in-dialog requests should be handled by loose_route
<br> # this should be fixed in the client or in openser<br> xlog("L_ERR","$ci in-dialog request was not catched by loose_route<br>block, 403... \n");<br> xlog("L_ERR","$ci this is the complete message:\n");
<br> xlog("L_ERR","$ci $mb\n");<br> sl_send_reply("403","in-dialog request without loose_route is not<br>allowed, this is a bug in the client or in this proxy\n");<br> exit;
<br> }<br> route(7); # proxy authentication<br><br><br><br>regards<br>Klaus<br><br><br><br><br><br><br><br><br><br><br><br><br>Carsten Bock wrote:<br>> Hi everybody,<br>><br>> Short question: Are there any best practices regarding the routing of
<br>> ACK Messages?<br>> Currently we have the following logic implemented:<br>><br>> route {<br>> [...]<br>><br>> ##################################################################################################################
<br>><br>> # Check for Re-Transmissions (not ACK/CANCEL)<br>><br>> ###############################################################################################################<br>><br>> if ((method != "CANCEL") && (method != "ACK")) {
<br>> if (t_check_trans()) {<br>> log(1, "Re-Transmission detected, message dropped.\n");<br>> # Drop the message silently.<br>> return;<br>> }<br>> }
<br>><br>> ##################################################################################################################<br>><br>> # Loose-Routing (RFC3261)<br>><br>> ###############################################################################################################
<br>><br>> if (loose_route()) {<br>> route(10);<br>> return;<br>> }; # if (loose_route()) {<br>> ##################################################################################################################
<br>><br>> # ACK/CANCEL Messages may be relayed<br>><br>> ###############################################################################################################<br>><br>> if ((method == "CANCEL") || (method == "ACK")) {
<br>> if (uri != myself) {<br>> # Und das Paket entsprechend weiterleiten<br>> if (!t_relay("udp:outbound_proxy:outbound_proxy_port")) {<br>> log(1, "Not possible to relay\n");
<br>> # Fehler melden<br>> sl_reply_error();<br>> return;<br>> }<br>> return;<br>> }<br>> }<br>> [...]<br>><br>> ##################################################################################################################
<br>><br>> # Rest of "normal" Routing logic with number manipulation / Routing<br>> to different Gateways / User Authorization/Authentication<br>><br>> ###############################################################################################################
<br>><br>> }<br>><br>> Is there any other method, to improve the routing of ACK/CANCEL<br>> Messages? I would like to avoid all the number manipulation, checking<br>> and choosing of a proper gateway....
<br>> I thought, this must (somehow) be possible since from a technical<br>> perspective the ACK and CANCEL Message can be associated with a<br>> corresponding INVITE Message (and the corresponding Transaction).<br>
> I've looked in the manual of the TM-Module and found the following example:<br>> if ( is_method("CANCEL") ) {<br>> if ( t_check_trans() )<br>> t_relay();<br>> exit;<br>> }<br>> (<a href="http://openser.org/docs/modules/1.1.x/tm.html#AEN460">
http://openser.org/docs/modules/1.1.x/tm.html#AEN460</a>)<br>><br>> I guess, this example does not mean, that the URI gets rewritten<br>> properly and the CANCEL-/ACK-Message would get properly relayed to the<br>
> destination, where it is supposed to end.<br>> Is there any way to do it best? I've seen, that some clients do proper<br>> loose-routing for ACK-Messages, but not all clients, so this is not a<br>> solution.
<br>> Are there any other suggestions?<br>><br>> Thanks in advance,<br>><br>> Carsten<br>><br>><br>><br>> ____________<br>> Virus checked by G DATA AntiVirusKit<br>><br>><br>><br>> _______________________________________________
<br>> Users mailing list<br>> <a href="mailto:Users@openser.org">Users@openser.org</a><br>> <a href="http://openser.org/cgi-bin/mailman/listinfo/users">http://openser.org/cgi-bin/mailman/listinfo/users</a><br><br>
<br>_______________________________________________<br>Users mailing list<br><a href="mailto:Users@openser.org">Users@openser.org</a><br><a href="http://openser.org/cgi-bin/mailman/listinfo/users">http://openser.org/cgi-bin/mailman/listinfo/users
</a><br></blockquote></div><br><br clear="all"><br>-- <br>Thanks and Regards with cheers<br>Sunkara Ravi Prakash (Voip Developer)<br>Hyperion Technology<br>Kondapur, Hi-tech city,<br>Hyderabad.<br><a href="http://www.hyperion-tech.com">
www.hyperion-tech.com</a><br>+91-9985077535