<!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">
I forgot to mention I am using the ser.cfg logic sample from the dbtext
module <br>
<br>
<a class="moz-txt-link-freetext" href="http://www.iptel.org/ser/doc/modules/dbtext">http://www.iptel.org/ser/doc/modules/dbtext</a><br>
<tt><br>
# main routing logic<br>
<br>
route{<br>
# initial sanity checks -- messages with<br>
# max_forwards==0, or excessively long requests<br>
if (!mf_process_maxfwd_header("10")) {<br>
sl_send_reply("483","Too Many Hops");<br>
break;<br>
};<br>
if (msg:len >= max_len ) {<br>
sl_send_reply("513", "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>
if (!method=="REGISTER") record_route();<br>
<br>
# subsequent messages withing a dialogi should take the<br>
# path determined by record-routing<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>
if (uri==myself) {<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>
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", "Not Found");<br>
break;<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 statefuli forwarding as it works reliably<br>
# even for UDP2TCP<br>
if (!t_relay()) {<br>
sl_reply_error();<br>
};<br>
}<br>
</tt><br>
<br>
Jeremy A wrote:
<blockquote cite="mid:474CDF07.2000104@electrosilk.net" type="cite">
<pre wrap="">Hello,
I'm need some help with SIP protocol / SER configuration to resolve a
problem.
I have a system with a SER instance and a SIP client application running
on the same box.
SER is 10.50.32.10:5060
APP is 10.50.32.10:5070
Remote SIP server 10.1.39.10
Remote phone is 10.1.39.202
The user agent is registered with the SER instance as extension 1009. It
has aliases 1001-1008 and is actually called as 231x which maps onto
100x which then connects to extension 1009.
The remote phone makes a call to the user agent application via the
remote SIP server and the SER instance. It dials 2311 which gets
automagically converted to extension 1009
The call is established but the user application times out and detects a
disconnect despite the calling phone not hanging up. In my wireshark
trace it seems that SER is ignoring some form of keep-alive from the
remote SIP server and this is causing the timeout. The lines of interest
include 39, 42, 45, 50, 53, 56, 59
Lines 28 and others similar are on the loopback interface and are
packets between port 5060 and 5070
Can someone please advise if the SIP protocol has problems and/or if SER
configuration has problems?
22 0.218826 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>
23 0.219570 127.0.0.1 -> 10.50.32.10 SIP Status: 200 OK (1
bindings)
24 19.472555 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
25 19.473394 10.50.32.10 -> 10.1.39.10 SIP Status: 100 trying --
your call is important to us
26 19.473596 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
27 19.484244 10.50.32.10 -> 10.50.32.10 SIP Status: 100 Trying
28 19.725476 10.50.32.10 -> 10.50.32.10 SIP Status: 180 Ringing
29 19.725828 10.50.32.10 -> 10.1.39.10 SIP Status: 180 Ringing
32 21.770798 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with
session description
33 21.782437 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with
session description
38 21.789396 10.50.32.10 -> 10.1.39.202 RTCP Source port: 8001
Destination port: 16391
39 21.800069 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>
40 22.278096 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with
session description
41 22.278713 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with
session description
42 22.298101 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>
43 23.285536 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with
session description
44 23.288988 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with
session description
45 23.307839 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>
48 25.298214 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with
session description
49 25.299105 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with
session description
50 25.317892 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>
51 29.306496 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with
session description
52 29.306758 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with
session description
53 29.328420 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>
54 33.314736 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with
session description
55 33.318736 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with
session description
56 33.338302 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>
57 37.323175 10.50.32.10 -> 10.50.32.10 SIP/SDP Status: 200 OK, with
session description
58 37.324791 10.50.32.10 -> 10.1.39.10 SIP/SDP Status: 200 OK, with
session description
59 37.347936 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>
--> client detects disconnect here
Thanks
jeremy
_______________________________________________
Serusers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Serusers@lists.iptel.org">Serusers@lists.iptel.org</a>
<a class="moz-txt-link-freetext" href="http://lists.iptel.org/mailman/listinfo/serusers">http://lists.iptel.org/mailman/listinfo/serusers</a>
</pre>
</blockquote>
<br>
</body>
</html>