<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Greger Viken Teigre wrote:
<blockquote cite="mid:200711280911.lAS9BrPw006253@pontius.teigre.com"
type="cite">
<pre wrap="">If you have alias=ip-of-ser in your config, ACK with port 5070 in ruri will match uri==myself.
The ACK should just be relayed.
See example cfg for ser used for sems for an example.
g-)
</pre>
</blockquote>
Unfortunately I am still quite puzzled by the SER configuration
process, so I have not been able to work out exactly what to do. The
ser/sems example uses pipes which doesn't help.<br>
<br>
So far I have simply added a clause to always forward ACK packets. This
is not sufficient.<br>
<br>
The ACK gets through but now the BYE command gets rejected 404 not
found on the user location lookup. I think this is caused by the
aliases involved in the call ?<br>
<br>
(Call is dialled as <a class="moz-txt-link-abbreviated" href="mailto:2311@fesa.sto">2311@fesa.sto</a>. It gets reformed to
<a class="moz-txt-link-abbreviated" href="mailto:1001@butler.fesa.sto">1001@butler.fesa.sto</a> and passed to the SER proxy for butler.fesa.sto.
SER knows 1001 is an alias of registered user 1009 and sends the call
to the user)<br>
<br>
Here is a log of a call made on the SER machine butler.fesa.sto<br>
<tt><br>
25.202593 10.50.32.10 -> 127.0.0.1 SIP Request: REGISTER
<a class="moz-txt-link-freetext" href="sip:localhost.localdomain">sip:localhost.localdomain</a> <-- my application registering<br>
25.213719 127.0.0.1 -> 10.50.32.10 SIP Status: 200 OK (1
bindings)<br>
75.234982 10.1.39.10 -> 10.50.32.10 SIP/SDP Request: INVITE
<a class="moz-txt-link-freetext" href="sip:1001@butler.fesa.sto;transport=udp">sip:1001@butler.fesa.sto;transport=udp</a>, with session description
<-- invite to alias<br>
75.255551 10.50.32.10 -> 10.1.39.10 SIP Status: 100 trying --
your call is important to us<br>
75.255867 10.50.32.10 -> 10.50.32.10 SIP/SDP Request: INVITE
<a class="moz-txt-link-freetext" href="sip:1009@10.50.32.10:5070;LINEID=1d5a67e38809">sip:1009@10.50.32.10:5070;LINEID=1d5a67e38809</a>, with session
description <-- Alias resolved and invite passed to registered
phone<br>
75.266591 10.50.32.10 -> 10.50.32.10 SIP Status: 100 Trying<br>
75.576971 10.50.32.10 -> 10.50.32.10 SIP Status: 180 Ringing<br>
75.578869 10.50.32.10 -> 10.1.39.10 SIP Status: 180 Ringing<br>
77.632370 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with
session description<br>
77.727289 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with
session description<br>
77.745453 10.1.39.10 -> 10.50.32.10 SIP Request: ACK
<a class="moz-txt-link-freetext" href="sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809">sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809</a> <-- ACK referencing
originally dialed extension<br>
77.746574 10.50.32.10 -> 10.50.32.10 SIP Request: ACK
<a class="moz-txt-link-freetext" href="sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809">sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809</a><br>
82.562176 10.1.39.10 -> 10.50.32.10 SIP Request: BYE
<a class="moz-txt-link-freetext" href="sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809">sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809</a> <--- BYE referencing
originally dialed extension<br>
82.563999 10.50.32.10 -> 10.1.39.10 SIP Status: 404 SER says Not
Found<br>
</tt><br>
I am guessing (not being an expert in SIP) that the line ID <tt>LINEID=1d5a67e38809
</tt>allows SER to route the call to the correct extension despite the
difference in SIP URI?<br>
<br>
So I guess I need a bit of code that says that matches an existing
LINEID and forwards the SIP message to the end user?<br>
<br>
Here is the current routing logic based on the textdb example but with
always forward ACK<br>
<br>
<tt><br>
# main routing logic<br>
<br>
route{<br>
# initial sanity checks -- messages with<br>
# max_forwards==0, or excessively long requests<br>
<br>
if (!mf_process_maxfwd_header("10")) {<br>
sl_send_reply("483","SER says Too Many Hops");<br>
break;<br>
};<br>
if (msg:len >= max_len ) {<br>
sl_send_reply("513", "SER says Message too big");<br>
break;<br>
};<br>
<br>
# we record-route all messages -- to make sure that<br>
# subsequent messages will go through our proxy; that's<br>
# particularly good if upstreami and downstreami entities<br>
# use different transport protocol<br>
<br>
if (!method=="REGISTER") record_route();<br>
<br>
# subsequent messages withing a dialogue should take the<br>
# path determined by record-routing<br>
<br>
if (loose_route()) {<br>
# mark routing logic in request<br>
append_hf("P-hint: rr-enforced\r\n");<br>
route(1);<br>
break;<br>
};<br>
<br>
if (!uri==myself) {<br>
# mark routing logic in request<br>
append_hf("P-hint: outbound\r\n");<br>
route(1);<br>
break;<br>
};<br>
<br>
# if the request is for other domain use UsrLoc<br>
# (in case, it does not work, use the following command<br>
# with proper names and addresses in it)<br>
<br>
if (uri==myself) {<br>
<br>
if (method=="REGISTER") {<br>
# digest authentication<br>
if (!www_authorize("", "subscriber")) {<br>
www_challenge("", "0");<br>
break;<br>
};<br>
<br>
save("location");<br>
break;<br>
};<br>
<br>
if (method=="ACK") {<br>
route(1);<br>
break;<br>
}<br>
<br>
lookup("aliases");<br>
if (!uri==myself) {<br>
append_hf("P-hint: outbound alias\r\n");<br>
route(1);<br>
break;<br>
};<br>
<br>
# native SIP destinations are handled using our USRLOC DB<br>
if (!lookup("location")) {<br>
sl_send_reply("404", "SER says Not Found");<br>
break;<br>
};<br>
};<br>
<br>
append_hf("P-hint: usrloc applied\r\n");<br>
route(1);<br>
}<br>
<br>
route[1]<br>
{<br>
# send it out now; use stateful forwarding as it works reliably<br>
# even for UDP2TCP<br>
if (!t_relay()) {<br>
sl_reply_error();<br>
};<br>
}<br>
</tt><br>
</body>
</html>