<!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">
The BYE should have a Route header, which is used for routing. If it
does not have a Route header, the UA originating the BYE must be fixed.
Of course, you can hack the BYE by doing the same kind of alias
rewriting as the INVITE, but it is not RFC-compliant.<br>
g-)<br>
<br>
Jeremy A wrote:
<blockquote cite="mid:474DF0BE.1020600@electrosilk.net" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
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 moz-do-not-send="true"
class="moz-txt-link-abbreviated" href="mailto:2311@fesa.sto">2311@fesa.sto</a>.
It gets reformed to
<a moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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>
</blockquote>
</body>
</html>