[Spce-user] New Version of Sipwise and external dispoatchers

Andreas Granig agranig at sipwise.com
Mon Jun 6 09:24:54 EDT 2011


Hi,

On 06/06/2011 01:19 PM, Andrew Pogrebennyk wrote:
> Hello,
> I have had exactly the same error when service bound on 127.0.0.1
> attempted to send message to the internet due to incorrect RR - I'm
> almost certain sipwise team will ask you for a network trace. Could you
> please collect one e.g. with ngrep?

Actually I don't need traces in this case, because with the 2.2 version
it's clear that it doesn't work that way anymore. Let me explain:

In 2.1, everything was running in one Kamailio instance, which was bound
to the public interface, so you were able to add stuff to the dispatcher
table.

In 2.2, the proxy/registrar instance is hidden behind a load-balancer
instance, and in the SPCE it's bound to localhost (actually to
networking.iaddress in /etc/ngcp-config/config.yml). That's why you see
these socket errors. Actually, the dispatcher table was meant for SPCE
internal things, whereas the external peerings are configured in the lcr
tables, and these calls are routed via sems-sbc and the kamailio-lb to
the outside.

So there are 3 ways you can tackle your problem:

1. if you've an RFC1918 network where your fax servers are running, and
your clients connect via a public network, then you could just change
networking.iaddress from 127.0.0.1 to an IP in this network, where also
the fax servers reside. It's not pretty because it exposes some SPCE
components to the internal network, but it should be pretty safe anyways
(and you can still protect them via iptables if you want).

2. the cleaner way would be to dig a bit into
/etc/ngcp-config/templates/etc/kamailio/proxy/proxy.cfg and check how in
BRANCH_ROUTE_CLI_RTP the $var(no_sbc) and $var(to_pstn) are used to set
the next hop and the hop after the next hop (which is b2bua and lb) in
order to route a call from the proxy bound on localhost via the b2bua
and the lb to some external peer. So in your route selecting the fax
server from dispatcher table, you need to set $var(no_sbc)=0 to force
the call via the b2bua, and in BRANCH_ROUTE_CLI_RTP you need to set the
hop after the b2bua also, like it's done inside the condition where
$var(to_pstn) is checked (search for "TODO: choose lbs from dispatcher
list").

3. the way how it's really intended to be (but I'm not sure if it can be
done in your specific environment) is to create a Peering Group in the
SIP Peerings section of the admin panel with the fax servers as Peering
Servers, and create proper Peering Rules to route specific numbers (e.g.
based by prefix) to these servers.

Andreas



> 
> On 06.06.2011 14:13, Klaus Peter v. Friedeburg wrote:
>> Hello SIPWISE-team,
>>
>> first I must say you have made a good job with version 2.2! Some
>> problems we have with older version are fixed.
>>
>> But there ist a new problem:
>>
>> In older version it was possible to edit the table “dispatcher” f.e to
>> use an external faxserver like hylafax. In the new version is the
>> problem when you enter a record with an external IP the service is not
>> established. The following error are record in the logs:
>>
>> kamailio-proxy.log:
>>
>> Jun  6 12:23:39 sip1 /usr/sbin/kamailio[30117]: ERROR: <core>
>> [udp_server.c:586]: ERROR: udp_send:
>> sendto(sock,0x7f7d685f2ac0,1951,0,81.90.192.204:5070,16): Invalid
>> argument(2
>>
>> 2)
>>
>> Jun  6 12:23:39 sip1 /usr/sbin/kamailio[30117]: : <core>
>> [udp_server.c:591]: CRITICAL: invalid sendtoparameters#012one possible
>> reason is the server is bound to localhost and#
>>
>> 012attempts to send to the net
>>
>> Jun  6 12:23:39 sip1 /usr/sbin/kamailio[30117]: ERROR: tm
>> [../../forward.h:149]: msg_send: ERROR: udp_send failed
>>
>> Jun  6 12:23:39 sip1 /usr/sbin/kamailio[30117]: ERROR: tm
>> [t_fwd.c:1382]: ERROR: t_send_branch: sending request on branch 0 failed
>>
>> Jun  6 12:23:39 sip1 /usr/sbin/kamailio[30117]: ERROR: sl
>> [sl_funcs.c:282]: ERROR: sl_reply_error used: Unfortunately error on
>> sending to next hop occurred (477/SL)
>>
>> How ist the way to fix that, so that we are able to use external
>> dispatchers …
>>
>> Mit freundlichen Grüßen
>>
>>            Klaus Peter v. Friedeburg
>>
> 
> 
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com
> http://lists.sipwise.com/listinfo/spce-user

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20110606/d41ea1b6/attachment-0001.asc>


More information about the Spce-user mailing list