<br><br><div class="gmail_quote">On Wed, Feb 2, 2011 at 6:20 AM, Bogdan-Andrei Iancu <span dir="ltr">&lt;<a href="mailto:bogdan@opensips.org">bogdan@opensips.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Jock,<div class="im"><br>
<br>
Jock McKechnie wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Greetings;<br>
<br>
I apologise in advance for this one. I _know_ I screwed it up, but I just cannot see how. I&#39;m sure it&#39;s something blazingly obvious, but I just cannot find it and it&#39;s driving me nuts.<br>
<br>
I&#39;ve written an OpenSIPS config that uses an external perl &#39;helper&#39; to do an LCR lookup (it incorporates a bunch more things that the built-in OpenSIPS LCR can&#39;t do, elsewise I&#39;d use it),<br>
</blockquote></div>
Have you looked at Dynamic Routing module (a more powerful LCR) - <a href="http://www.opensips.org/html/docs/modules/1.6.x/drouting.html" target="_blank">http://www.opensips.org/html/docs/modules/1.6.x/drouting.html</a><div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I&#39;ve rewritten the configuration several times over, and somewhere along the way I&#39;ve borked it, I guess. When the system receives a call it&#39;ll do the LCR lookup, find a route, and sends the call out to that route.<br>

The gateway it sends the call to responds with a &#39;100 Trying&#39;.... and then a second later OpenSIPS sends the INVITE again, and gets another &#39;100 Trying&#39;. And then a second later, OpenSIPS sends the INVITE again, etc. Even when the call comes up, sometimes OpenSIPS isn&#39;t &quot;seeing&quot; the &#39;200 OK&#39; and continues sending INVITES until it times out the call.<br>

</blockquote>
<br></div>
Set debug=6, make a call, and post the output somewhere - most probably the replies from GW are not matching the INVITE transaction....but let&#39;s see what the logs say. (attaching a SIP capture of the call will help)<br>
</blockquote><div><br>Thanks, Bogdan.<br><br>I&#39;m staring at this and I&#39;m not seeing where it&#39;s getting the &#39;100 Tryings&#39; at all, but perhaps it&#39;s forest/trees for me. I&#39;ve stripped off all the syslog date/time headers, but during this time space it sent out the initial INVITE, received a 100, send a second INVITE, a second 100 back, received a 183 Session Progress (presumably from the first INVITE)... after the time frame included it sent another three INVITEs and received two 183s back before everything BYE&#39;d out.<br>
<br>[Wed Feb  2 09:05:38 2011] Attempting to relay call to <a href="mailto:sip%3A%2B16414560000@192.168.1.99">sip:+16414560000@192.168.1.99</a><br>DBG:tm:t_newtran: transaction on entrance=0xffffffffffffffff<br>DBG:core:parse_headers: flags=ffffffffffffffff<br>
DBG:core:parse_headers: flags=78<br>DBG:tm:t_lookup_request: start searching: hash=22751, isACK=0<br>DBG:tm:matching_3261: RFC3261 transaction matching failed<br>DBG:tm:t_lookup_request: no transaction found<br>DBG:tm:run_reqin_callbacks: trans=0x7f5d8c2a14e8, callback type 1, id 1 entered<br>
DBG:core:parse_headers: flags=78<br>DBG:dialog:new_dlg_val: inserting &lt;accX_created&gt;=&lt;<br>DBG:tm:run_reqin_callbacks: trans=0x7f5d8c2a14e8, callback type 1, id 0 entered<br>DBG:dialog:get_dlg_timeout: invalid AVP value, use default timeout<br>
DBG:core:parse_headers: flags=ffffffffffffffff<br>DBG:core:check_ip_address: params 10.10.101.101, 10.10.101.101, 0<br>DBG:core:_shm_resize: resize(0) called<br>DBG:tm:_reply_light: reply sent out. buf=0x7b21d8: SIP/2.0 1..., shmem=0x7f5d8c2942b8: SIP/2.0 1<br>
DBG:tm:_reply_light: finished<br>DBG:core:mk_proxy: doing DNS lookup...<br>DBG:tm:set_timer: relative timeout is 500000<br>DBG:tm:insert_timer_unsafe: [4]: 0x7f5d8c2a1708 (446000000)<br>DBG:tm:set_timer: relative timeout is 30<br>
DBG:tm:insert_timer_unsafe: [0]: 0x7f5d8c2a1738 (475)<br>DBG:tm:t_relay_to: new transaction fwd&#39;ed<br>DBG:tm:t_unref: UNREF_UNSAFE: [0x7f5d8c2a14e8] after is 0<br>DBG:dialog:unref_dlg: unref dlg 0x7f5d8c294d68 with 1 -&gt; 2<br>
DBG:core:destroy_avp_list: destroying list (nil)<br>DBG:core:receive_msg: cleaning up<br>DBG:tm:utimer_routine: timer routine:4,tl=0x7f5d8c2a1708 next=(nil), timeout=446000000<br>DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0x7f5d8c2a14e8, INVITE si ... )<br>
DBG:tm:set_timer: relative timeout is 1000000<br>DBG:tm:insert_timer_unsafe: [5]: 0x7f5d8c2a1708 (447000000)<br>DBG:tm:retransmission_handler: retransmission_handler : done<br>DBG:tm:utimer_routine: timer routine:5,tl=0x7f5d8c2a1708 next=(nil), timeout=447000000<br>
DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0x7f5d8c2a14e8, INVITE si ... )<br>DBG:tm:utimer_routine: timer routine:7,tl=0x7f5d8c292a20 next=(nil), timeout=448000000<br>DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0x7f5d8c292800, INVITE si ... )<br>
DBG:tm:set_timer: relative timeout is 4000000<br>DBG:tm:insert_timer_unsafe: [7]: 0x7f5d8c292a20 (452000000)<br>DBG:tm:retransmission_handler: retransmission_handler : done<br>DBG:tm:utimer_routine: timer routine:6,tl=0x7f5d8c2a1708 next=(nil), timeout=449000000<br>
DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0x7f5d8c2a14e8, INVITE si ... )<br>DBG:tm:set_timer: relative timeout is 4000000<br>DBG:tm:insert_timer_unsafe: [7]: 0x7f5d8c2a1708 (453000000)<br>
DBG:tm:retransmission_handler: retransmission_handler : done<br>DBG:tm:utimer_routine: timer routine:7,tl=0x7f5d8c2a4408 next=(nil), timeout=449000000<br>DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0x7f5d8c2a41e8, INVITE si ... )<br>
DBG:tm:set_timer: relative timeout is 4000000<br>DBG:tm:insert_timer_unsafe: [7]: 0x7f5d8c2a4408 (453000000)<br>DBG:tm:retransmission_handler: retransmission_handler : done<br><br>The only way I have of replicating this is when I stick live system traffic to it - so providing logs is a bit troublesome as it will have several calls going through at once. But if more is required, I should be able to scrub out identifying information and provider better details.<br>
<br>Thanks;<br><br> - JP<br></div></div><br>