[Spce-user] multiple ethernet interfaces on SIPwise CE
Bob Fryer
bob at netintegrity.com.au
Tue Jun 25 21:25:23 EDT 2013
Dear All,
Hoping that someone can provide further information or clarification.
We have a SIPWISE CE setup.
Has gone pretty smooth, testing Subscribers connecting, setup simple
peer test account (out via the public Interface), Everything working
well.
However we went to stick a new Peer on which required use to implement a
third network card with a specific address.
Eth0 - Internal Network
Eth1 - public Interface (Subscribers connect via here) and used for our
Test Peer)
Eth2 - Dedicated Interface for Peer (Basically VLAN to Peer) - we have
routing in place for traffic for this peer to go via this interface
No NAT involved - all routed
An example of our network.yml file is as follows (addresses changed to
protect the innocent)
---
hosts:
self:
eth0:
type: []
eth1:
ip: 203.12.24.83
netmask: 255.255.255.192
type:
- web_ext
- sip_ext
- rtp_ext
- ssh_ext
eth2:
ip: 10.23.215.20
netmask: 255.255.255.248
type:
- sip_ext
- rtp_ext
interfaces:
- lo
- eth1
- eth2
lo:
ip: 127.0.0.1
netmask: 255.255.255.0
shared_ip: []
shared_v6ip: []
type:
- sip_int
- ha_int
- web_int
v6ip: '::1'
role:
- proxy
- lb
- mgmt
tcp 0 0 127.0.0.1:5060 0.0.0.0:*
LISTEN 0 1193218 7276/kamailio
tcp 0 0 10.23.215.20:5060 0.0.0.0:*
LISTEN 0 1193217 7276/kamailio
tcp 0 0 203.12.24.83:5060 0.0.0.0:*
LISTEN 0 1193216 7276/kamailio
udp 0 0 127.0.0.1:5060 0.0.0.0:*
0 1193214 7237/kamailio
udp 0 0 10.23.215.20:5060 0.0.0.0:*
0 1193213 7237/kamailio
udp 0 0 203.12.24.83:5060 0.0.0.0:*
0 1193212 7237/kamailio
All appears in terms of listening interfaces they all appear to be ok.
Now the issue we have is the SIP header is wrong (from) so we
implemented
kamailio:
lb:
extra_sockets:
telcoprivateint: udp: 10.23.215.20:5060
and set this as selected in the Peer (outbound Socket)
ok we now have SIP flowing to the carrier. We can make a call out, phone
rings on other end, person picks up....all the SIP Signalling working.
However no Voice either way.
Confirmed that RTP is using the eth1 interface and not over the private
link(eth2). Main issue is that RTP negotiation in the SDP is showing
coming from the Eth1 interface and appears no way of overriding this.
Any proven ideas on correcting this issue?
Any confirmation that we generally understand the issue correctly? We
are not seasoned professionals with SIP but strong IP Networkng skills,
but have a reasonable handle on sip, but first time on SIPwise. My
wording may not be correct either as writing this quicker than I would
like.
Any Assistance or thoughts would be appreciated, even if it is
confirmation that we have no choice but to place another SIP Proxy
between SIPwise and Private Peer.
Regards
Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/mailman/private/spce-user_lists.sipwise.com/attachments/20130626/e2207ea9/attachment.html>
More information about the Spce-user
mailing list