Hi,
After next_gw(), openser appends "64.231.23.234:5060;transport=tcp" as the domain of th ruri.
When doing a t_relay with that ruri, I am getting ERROR:tm:update_uac_dst.
before relay ruri = sip:86143455048@64.231.23.234:5060;transport=tcp starting to relay May 29 21:18:04 [12107] ERROR:tm:update_uac_dst: failed to fwd to af 2, proto 2 (no corresponding listening socket) May 29 21:18:04 [12107] ERROR:tm:t_forward_nonack: failure to add branches
However, if I do a t_relay with ruri= "sip:86143455048@64.231.23.234sip%3A86143455048@64.231.23.234", then the call can go through. Could anyone tell me why?
A workaround that I can think of is to reconstruct the ruri to get rid of the port and the "transport=tcp" with something like:
rewriteuri("sip:$rU@$rd");
But, the above line gives "sip:$rU@$rd" instead of the desired " sip:86143455048@64.231.23.234 sip%3A86143455048@64.231.23.234". Is there anyway of using psuedo variable in rewriteuri?
Thanks alot in advance for your help.
Regards, Pete
El Thursday 29 May 2008 18:37:39 Pete Kay escribió:
Hi,
After next_gw(), openser appends "64.231.23.234:5060;transport=tcp" as the domain of th ruri.
When doing a t_relay with that ruri, I am getting ERROR:tm:update_uac_dst.
before relay ruri = sip:86143455048@64.231.23.234:5060;transport=tcp starting to relay May 29 21:18:04 [12107] ERROR:tm:update_uac_dst: failed to fwd to af 2, proto 2 (no corresponding listening socket) May 29 21:18:04 [12107] ERROR:tm:t_forward_nonack: failure to add branches
However, if I do a t_relay with ruri= "sip:86143455048@64.231.23.234sip%3A86143455048@64.231.23.234", then the call can go through. Could anyone tell me why?
Are your OpenSer listening in TCP? or just UDP? You need adding a "listen" in TCP to send TCP request.
A workaround that I can think of is to reconstruct the ruri to get rid of the port and the "transport=tcp" with something like:
rewriteuri("sip:$rU@$rd");
But, the above line gives "sip:$rU@$rd" instead of the desired " sip:86143455048@64.231.23.234 sip%3A86143455048@64.231.23.234". Is there anyway of using psuedo variable in rewriteuri?
Of course:
$ru = "sip" + $rU + "@" + $rd;
but is better if you use the "uri" module that has functions to handle RURI parameters.
Hi,
I have added "listen=tcp:192.168.1.104" to the openser.cfg and when openser starts up, it shows that it is listening on both tcp and udp. However, I am still getting "ERROR:tm:update_uac_dst: failed to fwd to af 2, proto 2 (no corresponding listening socket)" I think the problem is with the ";transport=tcp" string that next_gw() is appending at the end. Is there anyway to fix it?
Are your OpenSer listening in TCP? or just UDP? You need adding a "listen" in TCP to send TCP request.
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
mark morreny writes:
I have added "listen=tcp:192.168.1.104" to the openser.cfg and when openser starts up, it shows that it is listening on both tcp and udp. However, I am still getting "ERROR:tm:update_uac_dst: failed to fwd to af 2, proto 2 (no corresponding listening socket)" I think the problem is with the ";transport=tcp" string that next_gw() is appending at the end. Is there anyway to fix it?
next_gw() should not on its own invent ;transport=tcp. it should only do it if you have specified tcp transport for this gw in transport column of gw table. see lcr README.
-- juha
Hi guys,
The topic was solved on the IRC channel - the error means that RURI forces TCP as transport (proto 2), but openser has no TCP interface configured. The bottom issue is the misconfiguration in LCR of the GW, where proto 2 was set for one of the GWs.
Regards, Bogdan
Juha Heinanen wrote:
mark morreny writes:
I have added "listen=tcp:192.168.1.104" to the openser.cfg and when openser starts up, it shows that it is listening on both tcp and udp. However, I am still getting "ERROR:tm:update_uac_dst: failed to fwd to af 2, proto 2 (no corresponding listening socket)" I think the problem is with the ";transport=tcp" string that next_gw() is appending at the end. Is there anyway to fix it?
next_gw() should not on its own invent ;transport=tcp. it should only do it if you have specified tcp transport for this gw in transport column of gw table. see lcr README.
-- juha
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
-
Bogdan-Andrei Iancu -
Iñaki Baz Castillo -
jh＠tutpro.com -
mark morreny -
Pete Kay