SRX

Hi,

 

we have a voip central(PBX) which works fine when calling out but then calling in through the SRX call gets through and starts but it ends after 32 seconds into the conversation and cuts off the connection.

 

the SIP ALG is deactivated and we use static nat to access the pbx from provider/clients

 

is the some settings which can be activated/tuned to fix this or troubleshoot this somehow?

Hi,

 

How are you doing the NAT?   You need to use static NAt to do a one to one translation of the IP addrress and also have you tried enabling SIP ALG?

Hi there and thanks for reply!

 

We are using static-nat from provider to PBX(phone central)

 

No, I have not tried enabling SIP ALG because our telephone-guys say that I shouldn't.

We have other phone lines on same PBX which I worry might die if I enable SIP ALG.

 

one thing I have been thinking about is that our IPT sip provider is NATed to PBX box on one IP but all other ips(the rest of the network) are source NATed to another(default) IP on the way out to the internet.

 

I dont know anything about how SIP works but then calling out from softphone(a phone software on windows desktop) the connection stays on, but when calling from outside to softphone the connection dies after 30-32 seconds

 

go figure..

 

I'll try to enable SIP ALG and be back with results

 

 

hi guys,

 

I'm afraid enabling SIP ALG didn't help.

 

any other thoughts?

Hello ,

 

What evrsion of Junos are you running in the SRX . Since you are not using SIP ALG , do you have a security policy to allow all ports ?

JUNOS 12.1X46-D25.7

In addition to enabling the SIP ALG you would need to apply the application to the policy used by the phones to establish the session so that the ALG is engaged for the phone calls.

I just enabled sip alg on the custom application and tested again, same result, it does not work.

calling from softphone to the outside phone works fine but calling from outside to the inside does not.

 

 

I assume it's enough to allow TCP/UDP from IPT SIP provider to the PBX(tele central).

 

All ip-phones/softphones have no restriction to the outside world.

At this point I think you will need to walk through the details of your sip nat scenario and then run the ALG verification commands.

 

Have a look at the SIP section of the documentation starting here with how the ALG works with NAT.  Locate your call direction and situation and walk down the configuration list to be sure all the pieces are in place.  If you think they are all there, then go to the ALG verification section to see what the ALG is actually doing.

 

http://www.juniper.net/techpubs/en_US/junos12.3x48/topics/concept/alg-security-sip-and-nat-understanding.html

 

Thank you for trying spuluka!

 

I'll follow this up and be back with result some time in near future!

Hey,

You might wanna try this command :

# set applications application <voice> inactivity-timeout never

Define voice application .

will be tested as well, thanks

You might wanna try this command :

# set applications application <voice> inactivity-timeout never

Define voice application .

This may be alright for a brief test but turning timeouts to never opens the door for filling your session table and prevent new traffic from flowing through the SRX.

 

If this is a premature tear down of a session, the better approach is to assign longer and longer custom timeouts to the application until the problemis resovled.  

 

If you use this approach I would never go longer than 24 hours personally.

Hey spuluka,

 

Thanks for the warning 🙂

Hi again guys,

 

I've checked the setup/documentation.

 

 

difference here is that we have PBX-phone server on static-nat on wap-ip2 and all clients/softphones on source-nat on

wan -ip1

 

we cannot do static-nat to every PC which runs softphone or another IP-phone as described in the documentation.

 

I've monitored(with wireshark) communication on my client where I'd installed softphone and called it.

 

I changed the T1 timeout on the srx but it didn't make any difference

 

I attach the sip table from srx and wireshark sip-call.

 

148.122.x.x is our sip-provider

1.200/23 is our pbx

0.62/23 is my laptop

 

From sip-call export I can see that the last message is that our provider tries to contact my laptop on port 3000, which I had opened just for test at the time of the test which again didn't help.

 

   Method              T            1xx            2xx            3xx            4xx            5xx            6xx
                      RT             RT             RT             RT             RT             RT             RT

   INVITE             20             22              4              2              7              0              0
                       7              0              0              0              0              0              0
   CANCEL             13              0              6              0              0              0              0
                       6              0              0              0              0              0              0
      ACK             13              0              0              0              0              0              0
                       0              0              0              0              0              0              0
      BYE              4              0              4              0              0              0              0
                       0              0              0              0              0              0              0
 REGISTER         256620              0           3049              0         253561              0              0
                       7              0              0              0              7              0              0
  OPTIONS          25788              0          20987              0              0              0              0
                       1              0              1              0              0              0              0
     INFO              0              0              0              0              0              0              0
                       0              0              0              0              0              0              0
  MESSAGE              0              0              0              0              0              0              0
                       0              0              0              0              0              0              0
   NOTIFY           1556              0           1548              0              0              0              0
                       1              0              0              0              0              0              0
    PRACK              0              0              0              0              0              0              0
                       0              0              0              0              0              0              0
  PUBLISH              0              0              0              0              0              0              0
                       0              0              0              0              0              0              0
    REFER              0              0              0              0              0              0              0
                       0              0              0              0              0              0              0
SUBSCRIBE           1106              0           1106              0              0              0              0
                       0              0              0              0              0              0              0
   UPDATE              0              0              0              0              0              0              0
                       0              0              0              0              0              0              0
 BENOTIFY              0              0              0              0              0              0              0
                       0              0              0              0              0              0              0
  SERVICE              0              0              0              0              0              0              0
                       0              0              0              0              0              0              0
    OTHER              0              0              0              0              0              0              0
                       0              0              0              0              0              0              0

SIP Error Counters:
  Total Pkt-in                      : 569119
  Total Pkt dropped on error        : 3673
  Call error                        : 0
  IP resolve error                  : 0
  NAT error                         : 0
  Resource manager error            : 0
  RR header exceeded max            : 0
  Contact header exceeded max       : 0
  Call Dropped due to limit         : 0
  SIP stack error                   : 3671
  SIP decode error                  : 2
  SIP unknown method error          : 0
  SIP dscp marked                   : 0
  SIP dscp marked error             : 0
  RTO message sent                  : 0
  RTO message received              : 0
  RTO buffer allocation failure     : 0
  RTO buffer transmit failure       : 0
  RTO send processing error         : 0
  RTO receive processing error      : 0
  RTO receive invalid length        : 0
  RTO receive call process error    : 0

these stats are from the beginning of testing several weeks ago(which started before I enabled SIP ALG), its clearly is that there are some error with sip.

But I dont understand what "SIP stack error" means.

 

 

Is there anything obvios which points you to any thought?

strange as it may sound the was a sec. policy which overruled the sip-allow policy...

 

moving sip-policy above that policy fixed the issue.

Well that makes sense.  No wonder the ALG was not kicking in to permit the calls.  thanks for the update.

There you said something,

 

the only policy we have implemented was to allow the IPT provider connect to the PBX on port 5060TCP/UDP, but we did explicitly disable SIP ALG in the custom application..

 

I'll try to enable it and check again!!