Thread Info
  • State Not Answered
  • Replies 14 replies
  • Subscribers 0 subscribers
  • Views 3213 views
  • Users 0 members are here
Options
Suggested

[7.460][FEATURE][NOTABUG] SIP Proxy over UDP

microgluf
HI,

I realise we've been talking about that for a long time now.
With VoIP becoming standard for about every business, having the SIP proxy handle SIP over UDP is getting somewhat urgent. Any idea when you plan to implement that ??

Cheers.
Parents Reply Children
  • 0 in reply to RFCat_vk_01
    We believe there is still a major issue surrounding the VoIP proxy.  Its fine if you want to only connect out to VoIP servers, but if you host your own VoIP server, and if you have multiple IP addresses, then presumably you will want to have your VoIP proxy operating on other than the default gateway.  As I understand things this is not possible at this time, which prevents corporate users from taking advantage of the proxy.  Whilst you can SNAT the fixed SIP ports (5060) it does not seem to be feasible to SNAT the RTP ports as they can range over 20,000 ports.

    What we would like to see is the ability to have the proxy assigned to a selected IP address so that it automatically (without SNAT) provides outgoing VoIP traffic with the correct source address.  Also, if we have a separate link for a dedicated VoIP link, we would like to be able to assign the proxy to that link (think leased lines and separate ADSL links).

    As an aside, the ability to select an IP address or interface for all of the Astaro proxies would be welcome.  Saves a lot of work!
  • 0 in reply to BangkokBob
    Hi again,

    Now I am confused...
    Has the SIP proxy over UDP made it's way to the 7.460 yet ??
    Because from where I am looking at it, it doesn't seem to work.

    Cheers.
  • 0 in reply to microgluf
    Hi,
    yes, it is in v7.460b. I have 2 voip phones on different providers and both work, both use SIP UDP 5060. I have a different ATA for each phone.

    Ian M[:)]
  • 0 in reply to RFCat_vk_01
    AFAIK nothing has been changed between v7.402 and 7.500 Beta regarding SIP.

    I also want to clarify that there is no actual 'SIP Proxy' anymore. In v7.402 we replaced the old proxy with a SIP conntrack helper kernel module which handles the connections.
  • 0 in reply to trollvottel
    Hi Mario,
    based on your answer, in theory then we should be able to NAT SIP traffic to different interfaces? 

    Ian M
  • 0 in reply to RFCat_vk_01
    Mario, Ian,

    Then I am having a problem. 
    Outgoing calls are working, but the ASG logs reports some dropped traffic during outgoing calls (see logs below)
    I also get a 2-3 seconds disconnection (no remote party sound) during the calls after about 5 minutes in the call. 


    23:53:23 SIP or H323 call ICMP 125.213.160.80 → 172.16.0.2 len=88 ttl=58 tos=0x00 srcmac=00:04:23:cc:38:f8 dstmac=00:00:00:00:00:00

    23:53:23 SIP or H323 call ICMP 125.213.160.80 → 172.16.0.2 len=88 ttl=58 tos=0x00 srcmac=00:04:23:cc:38:f8 dstmac=00:00:00:00:00:00

    23:53:23 SIP or H323 call ICMP 125.213.160.80 → 172.16.0.2 len=88 ttl=58 tos=0x00 srcmac=00:04:23:cc:38:f8 dstmac=00:00:00:00:00:00

    23:53:24 Default DROP UDP 125.213.160.81 : 5060 → nnn.nnn.201.114 : 5062 len=497 ttl=59 tos=0x00 srcmac=00:00:00:00:00:00 dstmac=00:00:00:00:00:00

    23:53:25 SIP or H323 call ICMP 125.213.160.80 → 172.16.0.2 len=88 ttl=58 tos=0x00 srcmac=00:04:23:cc:38:f8 dstmac=00:00:00:00:00:00

    23:53:26 SIP or H323 call ICMP 125.213.160.80 → 172.16.0.2 len=88 ttl=58 tos=0x00 srcmac=00:04:23:cc:38:f8 dstmac=00:00:00:00:00:00

    23:53:27 SIP or H323 call ICMP 125.213.160.80 → 172.16.0.2 len=88 ttl=58 tos=0x00 srcmac=00:04:23:cc:38:f8 dstmac=00:00:00:00:00:00

    23:53:27 SIP or H323 call ICMP 125.213.160.80 → 172.16.0.2 len=88 ttl=58 tos=0x00 srcmac=00:04:23:cc:38:f8 dstmac=00:00:00:00:00:00

    23:53:28 Default DROP UDP 125.213.160.81 : 5060 → nnn.nnn.201.114 : 5062 len=497 ttl=59 tos=0x00 srcmac=00:00:00:00:00:00 dstmac=00:00:00:00:00:00

    23:53:29 SIP or H323 call ICMP 125.213.160.80 → 172.16.0.2 len=88 ttl=58 tos=0x00 srcmac=00:04:23:cc:38:f8 dstmac=00:00:00:00:00:00

    23:53:30 SIP or H323 call ICMP 125.213.160.80 → 172.16.0.2 len=88 ttl=58 tos=0x00 srcmac=00:04:23:cc:38:f8 dstmac=00:00:00:00:00:00

    23:53:31 SIP or H323 call ICMP 125.213.160.80 → 172.16.0.2 len=88 ttl=58 tos=0x00 srcmac=00:04:23:cc:38:f8 dstmac=00:00:00:00:00:00

    23:53:31 SIP or H323 call ICMP 125.213.160.80 → 172.16.0.2 len=88 ttl=58 tos=0x00 srcmac=00:04:23:cc:38:f8 dstmac=00:00:00:00:00:00

    23:53:32 Default DROP UDP 125.213.160.81 : 5060 → nnn.nnn.201.114 : 5062 len=497 ttl=59 tos=0x00 srcmac=00:00:00:00:00:00 dstmac=00:00:00:00:00:00

    23:53:33 SIP or H323 call ICMP 125.213.160.80 → 172.16.0.2 len=88 ttl=58 tos=0x00 srcmac=00:04:23:cc:38:f8 dstmac=00:00:00:00:00:00

    23:53:34 SIP or H323 call ICMP 125.213.160.80 → 172.16.0.2 len=88 ttl=58 tos=0x00 srcmac=00:04:23:cc:38:f8 dstmac=00:00:00:00:00:00

    23:53:35 SIP or H323 call ICMP 125.213.160.80 → 172.16.0.2 len=88 ttl=58 tos=0x00 srcmac=00:04:23:cc:38:f8 dstmac=00:00:00:00:00:00

    23:53:36 Default DROP UDP 125.213.160.81 : 5060 → nnn.nnn.201.114 : 5062 len=497 ttl=59 tos=0x00 srcmac=00:00:00:00:00:00 dstmac=00:00:00:00:00:00

    23:53:37 SIP or H323 call ICMP 125.213.160.80 → 172.16.0.2 len=88 ttl=58 tos=0x00 srcmac=00:04:23:cc:38:f8 dstmac=00:00:00:00:00:00

    23:53:38 SIP or H323 call ICMP 125.213.160.80 → 172.16.0.2 len=88 ttl=58 tos=0x00 srcmac=00:04:23:cc:38:f8 dstmac=00:00:00:00:00:00

    23:53:40 Default DROP UDP 125.213.160.81 : 5060 → nnn.nnn.201.114 : 5062 len=497 ttl=59 tos=0x00 srcmac=00:00:00:00:00:00 dstmac=00:00:00:00:00:00

    23:53:44 Default DROP UDP 125.213.160.81 : 5060 → nnn.nnn.201.114 : 5062 len=497 ttl=59 tos=0x00 srcmac=00:00:00:00:00:00 dstmac=00:00:00:00:00:00


    ALSO Incoming calls are being rejected for the same reason... calling party get's engaged signal when calling in. (Incoming call log below) 


    00:19:51 Default DROP UDP 125.213.160.81 : 5060 → nnn.nnn.201.114 : 5062 len=1029 ttl=59 tos=0x00 srcmac=00:00:00:00:00:00 dstmac=00:00:00:00:00:00

    00:19:52 Default DROP UDP 125.213.160.81 : 5060 → nnn.nnn.201.114 : 5062 len=1029 ttl=59 tos=0x00 srcmac=00:00:00:00:00:00 dstmac=00:00:00:00:00:00

    00:19:54 Default DROP UDP 125.213.160.81 : 5060 → nnn.nnn.201.114 : 5062 len=1029 ttl=59 tos=0x00 srcmac=00:00:00:00:00:00 dstmac=00:00:00:00:00:00


    I've also attached the SIP logs from the LAN Proxy.
    Due to these errors and incoming calls being rejected I assumed the SIP proxy (now conntrack helper) wasn't working over UDP yet.

    info: The VoIP provider defined on the ASG is 125.213.160.81
  • 0 in reply to microgluf
    Hi,
    a couple of things,
    1/. not sure what you mean by a LAN proxy?
    2/. mynetfone uses a range of devices to provide their VoIP services. I created a DNS range because of the number of devices that could respond to a call.
    The mynetfone IP range I use as provided by DNS lookup is 125.213.160.64/27 which probably should be a /28. But it works.

    The address you are using for mynetfone is one of a number they use, they also use .90 and .80.  Now part of my configuration is a hangover from the SIP proxy, but why change it, it works. Being stateful, the ASG should pickup the return packets.

    Ian M
  • 0 in reply to RFCat_vk_01
    Hi Ian,

    1/ LAN Proxy... I agree isn't clear.
    My setup is a bit funky. Basically, I have an Asterisk server that is using an Epygi isdn gateway as my outgoing proxy. On a separate network, I also have a Linksys ATA that bypasses the gateway and connects directly to MNF.
    So to resume: 
    network 1: snom -> asterisk -> epygi -> astaro -> MNF.
    network 2: linksys -> astaro -> MNF.
    I also tried with the asterisk direct to MNF with the same results: no incoming calls.
    For info, I also use nodephone, epygi's own sip service as well as the Siemens sip server.

    2/ I had it also configured all the way to a 125.213.160.0/24 (just to be on the safe side) without success.

    The weird thing is that I use 5060 on the gateway and everywhere else on my network, but MNF always contacts me on 5062 when a call come in. And yes I agree it should in theory be stateful, but it won't work ... it's getting frustrating.

    Since it seems to be working for you, I will do a bit of trial tonight with the other SIP services. Although MNF is the one I use 98% of the time.

    Cheers, Pierre
  • 0 in reply to microgluf
    Hi Pierre,
    seeing you can make and receive calls I have to assume that the phone is registering. The other thing I found was mnf SIP keeps changing I have alternate between sip01 ans sip10 to get a registration.  I must admit under v7.500b the registration has improved and requires a lot less intervention.

    Is there anyway you can disable the proxy?

    I thought I had a strange setup, but yours is stranger.

    I have each phone configured separately. I have each destination configured separately and add each one to the appropriate place on the VOIP security tab.
    My MNF is only for outgoing, so I can't test the incoming component, but my iinet is bothway.  MNF to iiphone worked. Don't what the logs look like though.
    I have the iiphone connected through the MNF linksys ATA which is in bridge mode.

    Ian M
  • 0 in reply to RFCat_vk_01
    Hi Mario,

    Is there anywhere where I can find an explanation of what you are referring to in your comment above "I also want to clarify that there is no actual 'SIP Proxy' anymore. In v7.402 we replaced the old proxy with a SIP conntrack helper kernel module which handles the connections."

    The help section as regards this does not do anything to help my understanding, nor is there anything in knowledgebase.  Was the change related to a performance issue or a security issue?

    VoIP is particularly interesting both to ourselves and many of our customers.  Understanding the best and most secure way to configure it through an ASG would be of great help.

    My main interest is in optimal configuration for ASG fronting an internal VoIP server (Asterisk) which connects both to external VoIP providers, as well as having external client phones connecting back to the internal server.  Any pointers on this appreciated.