Fortinet FortiGate Router + sipXcom

[jkjk...@gmail.com]

Hi,

I am in the process of moving over to a FortiGate 100D.  This router is a bit different than my existing router.
I understand that I need to have the SIP ALG features disabled, but what about the SIP session-helper?

Any other input or "gotchas" related to sipXcom and configuring a Fortigate router would be greatly appreciated.

Thanks,
John

[Tony Graziano]

If you are supporting a sip trunk or remote users...

You should have both the alg and the session help too.

You should make sure your nat is 1:1 and symmetrical (ports) for source/destination of your server. In other words don't let the firewall randomize the ports destined or originating from your sip server.

[jkjk...@gmail.com]

Thanks Tony,

It's odd because when I was configuring my last router for sipX i was told to never use ALG.  Are you saying i should enable or disable ALG and session-helper?

I am just trying to learn so forgive me for the questions, but why go to 1:1 NAT?  From what I remember, most folks said 1:1 NAT was not necessary for a successful sipX configuration, but now you have me wondering because I did do 1:1 NAT on my last router/firewall.  I appreciate your time.

Thanks,
John

[Michael Picher]

I think he meant that you want to disable both.

--
You received this message because you are subscribed to the Google Groups "sipxcom-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-user...@googlegroups.com.
To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at http://groups.google.com/group/sipxcom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/f381c0b3-4382-4428-8174-63ab6185ee73%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Thanks,

   Mike

-----------------------------------------------------------------------------------------

There are 10 types of people in this world...  Those who understand binary and those who don't.

[João Veríssimo]

I have tested with 100D and let alg enabled, created a sip service port 5060, create a virtual ip mapping wan ip/port to lan ip/port, a voip security profile.
Create a policy with the above, income interface, destination interface,service, voip profile, action accept.
With alg enable you just need to allow sip, rtp ports will be open automatic.
I also create other policy to accept outgoing calls.
Hope this helps you.

[Michael Picher]

Somebody may want to create a page for this firewall under here: http://wiki.sipxcom.org/display/sipXcom/Other+Devices

Michael Picher, VP of Product Innovation
eZuce, Inc.

300 Brickstone Square

Suite 104

Andover, MA. 01810

O.978-296-1005 X2015 
M.207-956-0262
@mpicher <http://twitter.com/mpicher> 

linkedin
www.ezuce.com

Notice: This transmittal and/or attachments may be privileged or confidential. It is intended solely for the addressee(s) named above. Any dissemination, or copying is strictly prohibited. If you received this transmittal in error, please notify us immediately by reply and immediately delete this message and all its attachments. Thank you. FMS

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/11a30199-3a40-45a8-8ee9-8b3ab8706d18%40googlegroups.com.

[jkjk...@gmail.com]

On Thursday, December 10, 2015 at 9:54:34 AM UTC-5, João Veríssimo wrote:

I have tested with 100D and let alg enabled, created a sip service port 5060, create a virtual ip mapping wan ip/port to lan ip/port, a voip security profile.
Create a policy with the above, income interface, destination interface,service, voip profile, action accept.
With alg enable you just need to allow sip, rtp ports will be open automatic.
I also create other policy to accept outgoing calls.
Hope this helps you.

Thanks, Joao.  Do you also have sip session-helper enabled?  Are you using the default voip security profile?

Thanks,
John

[jkjk...@gmail.com]

I have everything working, except this scenario:

Someone calls from the outside.  The call is forwarded back out to a different phone outside - usually someones cell phone (setting configured within the sipxcom user settings).  The person's cell phone rings, but there is no audio either way.  I'm certain this is a nat issue, but am running out of ideas to make this work.  I had this working properly on my old firewall (so I don't believe it's a sipxcom configuration issue), but can't seem to get it functioning on the Fortigate 100d.

Here's my config:
Virtual IP from external to internal
sip session-helper and voip security features disabled

Firewall policy (outgoing traffic):
incoming interface: LAN
Source address: all
Outgoing interface: WAN1
Destination address: voip.ms servers
service: all (I will limit the ports once I can get things working properly)
Nat enabled
Use dynamic IP Pool enabled with the Virtual IP address


Any input would be greatly appreciated.

Thanks,
John

[Tommy Laino]

If you are using SIP trunks make sure that the Always Relay Media box is unchecked in the ITSP account info.

--
You received this message because you are subscribed to the Google Groups "sipxcom-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-user...@googlegroups.com.
To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at http://groups.google.com/group/sipxcom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/f78c9499-0c5d-48de-8f4f-6a9ef8e4d81f%40googlegroups.com.

[jkjk...@gmail.com]

On Friday, December 11, 2015 at 12:44:39 PM UTC-5, Tommy Laino wrote:

If you are using SIP trunks make sure that the Always Relay Media box is unchecked in the ITSP account info.

Thank you Tommy,
I tried this but it didn't fix the issue...Any other ideas?

[pmkr...@gmail.com]

I suggest performing traces on the WAN and LAN interfaces on the Fortigate during active calls and analyze - it will help with troubleshooting of NAT and firewall rule issues.

Peter

[João Veríssimo]

I have not tested that scenario. But in my configuration I use a voip profile, so from the fortigate handbook this mean I use sip alg on the that profile.
I hope to test your scenario soon and the of the works.

[jkjk...@gmail.com]

Here's a trace (scrubbed) of the issue occurring:

Can anyone identify the no-audio-after-forward issue by looking at this?

No.,"Time","Source","Destination","Protocol","Length","Info"

1,"0.000000","10.1.20.22","voip.ms.server","UDP","46","Source port: 5080  Destination port: 5060"

2,"5.238065","JuniperN_f8:43:01","Broadcast","ARP","64","Gratuitous ARP for 10.1.20.1 (Request) [ETHERNET FRAME CHECK SEQUENCE INCORRECT]"

3,"5.308443","10.1.20.22","voip.ms.server","SIP","639","Request: REGISTER sip:voip.ms.server  (1 binding) | "

4,"5.327347","voip.ms.server","10.1.20.22","SIP","627","Status: 401 Unauthorized | "

5,"5.335378","10.1.20.22","voip.ms.server","SIP","818","Request: REGISTER sip:voip.ms.server  (1 binding) | "

6,"5.351554","voip.ms.server","10.1.20.22","SIP","636","Request: OPTIONS sip:MyAc...@50.50.50.50:5080;transport=udp | "

7,"5.352074","voip.ms.server","10.1.20.22","SIP","660","Status: 200 OK  (1 binding) | "

8,"5.358080","10.1.20.22","voip.ms.server","SIP","445","Status: 406 Not acceptable | "

9,"6.239005","JuniperN_f8:43:01","Broadcast","ARP","64","Gratuitous ARP for 10.1.20.1 (Request) [ETHERNET FRAME CHECK SEQUENCE INCORRECT]"

10,"7.640965","JuniperN_f8:43:01","Broadcast","ARP","64","Gratuitous ARP for 10.1.20.1 (Request) [ETHERNET FRAME CHECK SEQUENCE INCORRECT]"

11,"8.641966","JuniperN_f8:43:01","Broadcast","ARP","64","Gratuitous ARP for 10.1.20.1 (Request) [ETHERNET FRAME CHECK SEQUENCE INCORRECT]"

12,"9.643094","JuniperN_f8:43:01","Broadcast","ARP","64","Gratuitous ARP for 10.1.20.1 (Request) [ETHERNET FRAME CHECK SEQUENCE INCORRECT]"

13,"10.644088","JuniperN_f8:43:01","Broadcast","ARP","64","Gratuitous ARP for 10.1.20.1 (Request) [ETHERNET FRAME CHECK SEQUENCE INCORRECT]"

14,"11.645048","JuniperN_f8:43:01","Broadcast","ARP","64","Gratuitous ARP for 10.1.20.1 (Request) [ETHERNET FRAME CHECK SEQUENCE INCORRECT]"

15,"18.000670","voip.ms.server","10.1.20.22","SIP/SDP","1005","Request: INVITE sip:72433...@10.1.20.22:5080 | "

16,"18.099974","voip.ms.server","10.1.20.22","SIP/SDP","1005","Request: INVITE sip:72433...@10.1.20.22:5080 | "

17,"18.151296","10.1.20.22","10.1.20.100","TCP","74","49178 > 5060 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=697762 TSecr=0 WS=128"

18,"18.151837","10.1.20.100","10.1.20.22","TCP","74","5060 > 49178 [SYN, ACK] Seq=0 Ack=1 Win=5776 Len=0 MSS=1456 SACK_PERM=1 TSval=31993445 TSecr=697762 WS=2"

19,"18.151865","10.1.20.22","10.1.20.100","TCP","66","49178 > 5060 [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=697763 TSecr=31993445"

20,"18.153311","10.1.20.22","10.1.20.100","TCP","1510","[TCP segment of a reassembled PDU]"

21,"18.153326","10.1.20.22","10.1.20.100","SIP/SDP","394","Request: INVITE sip:2...@10.1.20.100:5060;transport=tcp;line=jxf9g3j7;x-sipX-nonat | "

22,"18.153801","10.1.20.100","10.1.20.22","TCP","66","5060 > 49178 [ACK] Seq=1 Ack=1445 Win=8664 Len=0 TSval=31993445 TSecr=697764"

23,"18.153921","10.1.20.100","10.1.20.22","TCP","66","5060 > 49178 [ACK] Seq=1 Ack=1773 Win=8664 Len=0 TSval=31993445 TSecr=697764"

24,"18.181707","10.1.20.100","10.1.20.22","Syslog","146","KERN.NOTICE: Dec 11 12:45:28 snom870-44D134 00041344D134 [NOTICE] PHN: RTP: set_destination  adr=10.1.20.22:30502\\n"

25,"18.185882","10.1.20.100","10.1.20.22","SIP","952","Status: 100 Trying | "

26,"18.185897","10.1.20.22","10.1.20.100","TCP","66","49178 > 5060 [ACK] Seq=1773 Ack=887 Win=16384 Len=0 TSval=697797 TSecr=31993448"

27,"18.207977","10.1.20.22","voip.ms.server","SIP","421","Status: 100 Trying | "

28,"18.211981","10.1.20.100","10.1.20.22","SIP","1095","Status: 180 Ringing | "

29,"18.211998","10.1.20.22","10.1.20.100","TCP","66","49178 > 5060 [ACK] Seq=1773 Ack=1916 Win=18432 Len=0 TSval=697823 TSecr=31993451"

30,"18.225990","10.1.20.22","voip.ms.server","SIP","497","Status: 180 Ringing | "

31,"18.236172","SnomTech_41:a1:04","Broadcast","ARP","60","Who has 10.1.20.1?  Tell 10.1.20.100"

32,"18.479058","10.1.20.100","10.1.20.22","Syslog","153","NTP.NOTICE: Dec 11 12:45:28 snom870-44D134 00041344D134 [NOTICE] LID: CAudioSpirit::SetVolume: 28232 of 4 Ohm speaker\\n"

33,"20.000457","10.1.20.22","voip.ms.server","UDP","46","Source port: 5080  Destination port: 5060"

34,"21.454236","10.1.20.102","10.1.20.22","TCP","70","11891 > 5060 [PSH, ACK] Seq=1 Ack=1 Win=16710 Len=4 TSval=31975317 TSecr=678778"

35,"21.454570","10.1.20.22","10.1.20.102","TCP","68","5060 > 11891 [PSH, ACK] Seq=1 Ack=5 Win=501 Len=2 TSval=701066 TSecr=31975317"

36,"21.455089","10.1.20.102","10.1.20.22","TCP","66","11891 > 5060 [ACK] Seq=5 Ack=3 Win=16710 Len=0 TSval=31975317 TSecr=701066"

37,"22.838652","10.1.20.100","10.1.20.22","SIP","784","Status: 486 Busy Here | "

38,"22.838679","10.1.20.22","10.1.20.100","TCP","66","49178 > 5060 [ACK] Seq=1773 Ack=2634 Win=20608 Len=0 TSval=702450 TSecr=31993914"

39,"22.840200","10.1.20.100","10.1.20.22","Syslog","134","KERN.NOTICE: Dec 11 12:45:32 snom870-44D134 00041344D134 [NOTICE] PHN: RTP: set_destination RP33 adr=\\n"

40,"22.841206","10.1.20.22","10.1.20.100","SIP","526","Request: ACK sip:2...@10.1.20.100:5060;transport=tcp;line=jxf9g3j7;x-sipX-nonat | "

41,"22.876115","10.1.20.100","10.1.20.22","TCP","66","5060 > 49178 [ACK] Seq=2634 Ack=2233 Win=11552 Len=0 TSval=31993918 TSecr=702452"

42,"22.894568","10.1.20.100","10.1.20.22","Syslog","173","KERN.CRIT: Dec 11 12:45:33 snom870-44D134 00041344D134 [CRITIC] PHN: GUI: touch_container::checkTouchkeyMap detected uninitialized element\\n"

43,"22.895026","10.1.20.100","10.1.20.22","Syslog","173","KERN.CRIT: Dec 11 12:45:33 snom870-44D134 00041344D134 [CRITIC] PHN: GUI: touch_container::checkTouchkeyMap detected uninitialized element\\n"

44,"22.895483","10.1.20.100","10.1.20.22","Syslog","173","KERN.CRIT: Dec 11 12:45:33 snom870-44D134 00041344D134 [CRITIC] PHN: GUI: touch_container::checkTouchkeyMap detected uninitialized element\\n"

45,"22.895955","10.1.20.100","10.1.20.22","Syslog","173","KERN.CRIT: Dec 11 12:45:33 snom870-44D134 00041344D134 [CRITIC] PHN: GUI: touch_container::checkTouchkeyMap detected uninitialized element\\n"

46,"22.896495","10.1.20.100","10.1.20.22","Syslog","173","KERN.CRIT: Dec 11 12:45:33 snom870-44D134 00041344D134 [CRITIC] PHN: GUI: touch_container::checkTouchkeyMap detected uninitialized element\\n"

47,"22.896957","10.1.20.100","10.1.20.22","Syslog","173","KERN.CRIT: Dec 11 12:45:33 snom870-44D134 00041344D134 [CRITIC] PHN: GUI: touch_container::checkTouchkeyMap detected uninitialized element\\n"

48,"22.897646","10.1.20.100","10.1.20.22","Syslog","173","KERN.CRIT: Dec 11 12:45:33 snom870-44D134 00041344D134 [CRITIC] PHN: GUI: touch_container::checkTouchkeyMap detected uninitialized element\\n"

49,"22.898107","10.1.20.100","10.1.20.22","Syslog","173","KERN.CRIT: Dec 11 12:45:33 snom870-44D134 00041344D134 [CRITIC] PHN: GUI: touch_container::checkTouchkeyMap detected uninitialized element\\n"

50,"22.898585","10.1.20.100","10.1.20.22","Syslog","173","KERN.CRIT: Dec 11 12:45:33 snom870-44D134 00041344D134 [CRITIC] PHN: GUI: touch_container::checkTouchkeyMap detected uninitialized element\\n"

51,"22.899054","10.1.20.100","10.1.20.22","Syslog","173","KERN.CRIT: Dec 11 12:45:33 snom870-44D134 00041344D134 [CRITIC] PHN: GUI: touch_container::checkTouchkeyMap detected uninitialized element\\n"

52,"22.899515","10.1.20.100","10.1.20.22","Syslog","173","KERN.CRIT: Dec 11 12:45:33 snom870-44D134 00041344D134 [CRITIC] PHN: GUI: touch_container::checkTouchkeyMap detected uninitialized element\\n"

53,"22.933439","10.1.20.22","voip.ms.server","SIP/SDP","1254","Request: INVITE sip:14123...@voip.ms.server;callgroup=201;sipx-noroute=Voicemail;user=phone | "

54,"22.951490","voip.ms.server","10.1.20.22","SIP","636","Request: OPTIONS sip:MyAc...@50.50.50.50:5080;transport=udp | "

55,"22.951567","voip.ms.server","10.1.20.22","SIP","648","Status: 401 Unauthorized | "

56,"22.955901","10.1.20.22","voip.ms.server","SIP","591","Request: ACK sip:14123...@voip.ms.server;callgroup=201;sipx-noroute=Voicemail;user=phone | "

57,"22.957599","10.1.20.22","voip.ms.server","SIP","445","Status: 406 Not acceptable | "

58,"22.962442","10.1.20.22","voip.ms.server","SIP/SDP","1493","Request: INVITE sip:14123...@voip.ms.server;callgroup=201;sipx-noroute=Voicemail;user=phone | "

59,"22.981500","voip.ms.server","10.1.20.22","SIP","636","Request: OPTIONS sip:MyAc...@50.50.50.50:5080;transport=udp | "

60,"22.981944","voip.ms.server","10.1.20.22","SIP","626","Status: 100 Trying | "

61,"22.988544","10.1.20.22","voip.ms.server","SIP","445","Status: 406 Not acceptable | "

62,"23.106206","10.1.20.102","10.1.20.22","SIP","640","Request: SUBSCRIBE sip:~~rl~C~2...@sip.mydomain.local | "

63,"23.125249","10.1.20.22","10.1.20.102","SIP","858","Status: 401 Unauthorized | "

64,"23.125764","10.1.20.102","10.1.20.22","TCP","66","11891 > 5060 [ACK] Seq=579 Ack=795 Win=16710 Len=0 TSval=31975484 TSecr=702736"

65,"23.131879","10.1.20.102","10.1.20.22","SIP","928","Request: SUBSCRIBE sip:~~rl~C~2...@sip.mydomain.local | "

66,"23.152459","10.1.20.22","10.1.20.102","SIP","747","Status: 404 Not Found | "

67,"23.183211","10.1.20.102","10.1.20.22","TCP","66","11891 > 5060 [ACK] Seq=1441 Ack=1476 Win=16710 Len=0 TSval=31975490 TSecr=702763"

68,"24.218729","voip.ms.server","10.1.20.22","SIP/SDP","974","Status: 183 Session Progress | "

69,"24.241833","10.1.20.22","voip.ms.server","SIP","497","Status: 180 Ringing | "

70,"26.543778","10.1.20.102","10.1.20.22","Syslog","145","LOCAL0.NOTICE: Dec 11 17:45:36 ipvp[618]: IPVP<5+notice> 936.855.750:Message=0x00000001(0x00000000+0x00000000+0)\\n"

71,"27.735632","10.1.1.178","10.1.20.22","TCP","66","58100 > 443 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1"

72,"27.735658","10.1.20.22","10.1.1.178","TCP","66","443 > 58100 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460 SACK_PERM=1 WS=128"

73,"27.738225","10.1.1.178","10.1.20.22","TCP","60","58100 > 443 [ACK] Seq=1 Ack=1 Win=65700 Len=0"

74,"27.769020","10.1.1.178","10.1.20.22","TLSv1.2","571","Client Hello"

75,"27.769045","10.1.20.22","10.1.1.178","TCP","54","443 > 58100 [ACK] Seq=1 Ack=518 Win=15744 Len=0"

76,"27.769407","10.1.20.22","10.1.1.178","TLSv1.2","191","Server Hello, Change Cipher Spec, Encrypted Handshake Message"

77,"27.966701","10.1.1.178","10.1.20.22","TCP","60","58100 > 443 [ACK] Seq=518 Ack=138 Win=65560 Len=0"

78,"28.278532","10.1.1.178","10.1.20.22","TLSv1.2","105","Change Cipher Spec, Hello Request, Hello Request"

79,"28.279198","10.1.1.178","10.1.20.22","TCP","1514","[TCP segment of a reassembled PDU]"

80,"28.279218","10.1.20.22","10.1.1.178","TCP","54","443 > 58100 [ACK] Seq=138 Ack=2029 Win=18688 Len=0"

81,"28.279226","10.1.1.178","10.1.20.22","TLSv1.2","1161","Application Data"

82,"28.318566","10.1.20.22","10.1.1.178","TCP","54","443 > 58100 [ACK] Seq=138 Ack=3136 Win=21632 Len=0"

83,"28.650456","10.1.20.22","10.1.1.178","TLSv1.2","2974","Application Data, Application Data"

84,"28.650478","10.1.20.22","10.1.1.178","TCP","1514","[TCP segment of a reassembled PDU]"

85,"28.650482","10.1.20.22","10.1.1.178","TLSv1.2","444","Application Data"

86,"28.650755","10.1.20.22","10.1.1.178","TLSv1.2","88","Application Data"

87,"28.650837","10.1.20.22","10.1.1.178","TLSv1.2","85","Encrypted Alert"

88,"28.650882","10.1.20.22","10.1.1.178","TCP","54","443 > 58100 [FIN, ACK] Seq=4973 Ack=3136 Win=21632 Len=0"

89,"28.654032","10.1.1.178","10.1.20.22","TCP","60","58100 > 443 [ACK] Seq=3136 Ack=3058 Win=65700 Len=0"

90,"28.654508","10.1.1.178","10.1.20.22","TCP","60","58100 > 443 [ACK] Seq=3136 Ack=4908 Win=65700 Len=0"

91,"28.654927","10.1.1.178","10.1.20.22","TCP","60","58100 > 443 [ACK] Seq=3136 Ack=4973 Win=65632 Len=0"

92,"28.655707","10.1.1.178","10.1.20.22","TCP","60","58100 > 443 [ACK] Seq=3136 Ack=4974 Win=65632 Len=0"

93,"28.657748","10.1.1.178","10.1.20.22","TCP","60","58100 > 443 [RST, ACK] Seq=3136 Ack=4974 Win=0 Len=0"

94,"29.186259","10.1.20.102","10.1.20.22","SIP","578","Request: SUBSCRIBE sip:2...@sip.mydomain.local | "

95,"29.205126","10.1.20.22","10.1.20.102","SIP","965","Request: SUBSCRIBE sip:2...@10.1.20.102:5060;transport=TCP;x-sipX-nonat;sipXecs-CallDest=INT | "

96,"29.205797","10.1.20.102","10.1.20.22","TCP","66","11891 > 5060 [ACK] Seq=1953 Ack=2375 Win=16710 Len=0 TSval=31976092 TSecr=708816"

97,"29.212477","10.1.20.102","10.1.20.22","SIP","605","Status: 489 Bad Event | "

98,"29.233662","10.1.20.22","10.1.20.102","SIP","471","Status: 489 Bad Event | "

99,"29.273229","10.1.20.102","10.1.20.22","TCP","66","11891 > 5060 [ACK] Seq=2492 Ack=2780 Win=16710 Len=0 TSval=31976099 TSecr=708844"

100,"30.158200","voip.ms.server","10.1.20.22","SIP/SDP","960","Status: 200 OK | "

101,"30.184028","10.1.20.22","voip.ms.server","SIP","736","Request: ACK sip:14123...@voip.ms.server:5060 | "

102,"30.197361","10.1.20.22","voip.ms.server","SIP/SDP","801","Status: 200 OK | "

103,"30.213209","voip.ms.server","10.1.20.22","SIP","477","Request: ACK sip:~~id~bri...@50.50.50.50:5080;transport=udp | "

104,"39.999872","10.1.20.22","voip.ms.server","UDP","46","Source port: 5080  Destination port: 5060"

105,"40.680074","voip.ms.server","10.1.20.22","SIP","714","Request: BYE sip:26742...@50.50.50.50:5080;transport=udp | "

106,"40.688163","10.1.20.22","voip.ms.server","SIP","496","Status: 100 Trying | "

107,"40.692601","10.1.20.22","voip.ms.server","SIP","592","Request: BYE sip:26742...@voip.ms.server:5060 | "

108,"40.710919","voip.ms.server","10.1.20.22","SIP","527","Status: 200 OK | "

109,"40.716497","10.1.20.22","voip.ms.server","SIP","516","Status: 200 OK | "

[pmkr...@gmail.com]

It's hard to say from this packet capture, but packets 58, 60, 69, and 100 appear to be the SIP signaling for the second leg of the call. The call gets established but suspect the RTP packets are not being sent to the right endpoints. Trace the IP addresses in the SIP packets with SDP information - you may find some answers there on what is going on. Also, do your packet capture from the WAN interface to ascertain packets are not being dropped.

Peter

53,"22.933439","10.1.20.22","voip.ms.server","SIP/SDP","1254","Request: INVITE sip:14123335555@voip.ms.server;callgroup=201;sipx-noroute=Voicemail;user=phone | "

54,"22.951490","voip.ms.server","10.1.20.22","SIP","636","Request: OPTIONS sip:MyAc...@50.50.50.50:5080;transport=udp | "

55,"22.951567","voip.ms.server","10.1.20.22","SIP","648","Status: 401 Unauthorized | "

56,"22.955901","10.1.20.22","voip.ms.server","SIP","591","Request: ACK sip:14123335555@voip.ms.server;callgroup=201;sipx-noroute=Voicemail;user=phone | "

57,"22.957599","10.1.20.22","voip.ms.server","SIP","445","Status: 406 Not acceptable | "

58,"22.962442","10.1.20.22","voip.ms.server","SIP/SDP","1493","Request: INVITE sip:14123335555@voip.ms.server;callgroup=201;sipx-noroute=Voicemail;user=phone | "

101,"30.184028","10.1.20.22","voip.ms.server","SIP","736","Request: ACK sip:14123335555@voip.ms.server:5060 | "

102,"30.197361","10.1.20.22","voip.ms.server","SIP/SDP","801","Status: 200 OK | "

103,"30.213209","voip.ms.server","10.1.20.22","SIP","477","Request: ACK sip:~~id~bri...@50.50.50.50:5080;transport=udp | "

104,"39.999872","10.1.20.22","voip.ms.server","UDP","46","Source port: 5080  Destination port: 5060"

105,"40.680074","voip.ms.server","10.1.20.22","SIP","714","Request: BYE sip:26742...@50.50.50.50:5080;transport=udp | "

106,"40.688163","10.1.20.22","voip.ms.server","SIP","496","Status: 100 Trying | "

107,"40.692601","10.1.20.22","voip.ms.server","SIP","592","Request: BYE sip:2674225555@voip.ms.server:5060 | "

[jkjk...@gmail.com]

Okay, so I think I just found a workaround.

Under the voip.ms gateway settings within sipXcom, I changed "Method to use for RTP keepalive" from none to use empty packet and it started working!
Will this have a negative effect on other calls in the office?  Is this an acceptable workaround?  Is this considered a fix or workaround?

Much appreciated,
John

[Michael Picher]

Fix or workaround is always a matter of perspective...  I'd say it's a workaround that fixes the problems you were experiencing with your environment.

There's some wordsmithing there for you...  ;-)

--
You received this message because you are subscribed to the Google Groups "sipxcom-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-user...@googlegroups.com.
To post to this group, send email to sipxco...@googlegroups.com.

Visit this group at https://groups.google.com/group/sipxcom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/97c7731a-1552-48c2-9d17-56e725138c05%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[jkjk...@gmail.com]

Nice!  I guess I was just wondering if I made a software change for something that should be addressed on the firewall/router.  I guess as long as it works....

Thanks guys.  Merry Christmas!

-John

[jkjk...@gmail.com]

So I guess I did not resolve this issue.

To recap, here's the problem:
External caller dials coming in to a DID (Desk Phone).  If that person has forwarding out to a cell phone (or any external number) configured in sipX, when they pick up the call on the cell phone, there is no audio either way.  The desk phone can be a Snom or Polycom and the same issue happens.

I can fix the problem temporarily (4-24 hours) by playing around with the Method to use for RTP keepalive gateway setting.  Prior to installing the Fortinet router, I had this setting turned off and things worked.  I've tried all three other RTP keepalive options (Use Empty Packet, Replay Last Sent Packet, and Use Dummy RTP Payload).  If I select any of these three other options, then the call forwarding audio works both ways for about a day then stops working again. Is anyone aware of other settings I can try out to resolve this issue permanently?

Any assistance you can provide would be greatly appreciated.

Thanks,
John

[Tony Graziano]

Are you using an ITSP? To me it sounds like they use an aggregator and some do not support forked calls. (IMHO)

[Jim Canfield]

Hi John,

I use Fortinet and Pfsense almost exclusively.  I don't use voip.ms much anymore, but I'm curious what method you used to disable ALG.  I use the following steps and never have a problem. Kernel-helper mode being the key.

Step #1 – Removing the session helper.

A. Run the following commands:

config system session-helper
  show

Amongst the displayed setting will be one similar to the following example:

    edit 13
        set name sip
        set protocol 17
        set port 5060
 
B.  in this example the next commands would be:

delete 13
end

Step #2 - change the default –voip –alg-mode.

Run the following commands:

config system settings
set default-voip-alg-mode kernel-helper based
end

Step #3 – Either reboot or clear sessions to make sure changes take effect

[jkjk...@gmail.com]

Hi Tony,

Our ITSP is voip.ms.  They are pretty well known I think, do you know if they support forked calls?  This used to work prior to me putting the Fortigate in, but I remember having similar issues with the last router (Netgear UTM25) too.

Jim,

You may just be my hero.  I had step one configured just as you mentioned, but for step two, I had default-voip-alg-mode set to proxy-based.  You have no idea how much I'm hoping this resolves the problem.  I'll reset the router this weekend and see what happens next week.  Thank you to everyone for adding input on this.  As you can tell, I'm neither a VoIP expert or Fortigate expert.

I really appreciate your help and I'll report back next week either way with results just to make sure it's all documented for the next guy...

Thanks again,
John

[jkjk...@gmail.com]

Okay so I just made the change and rebooted the Fortigate.  I could only hear audio on an externally forwarded call after unchecking the "Always Relay Media" setting in the sipXcom Gateway settings.  It is a good sign that I have the "Method to use for RTP keepalive" set to none and it still works.  I should know for sure by early next week.

Thanks again guys.

Much appreciated,
John

[jkjk...@gmail.com]

I guess I got too excited...  So, the call forwarding part was fixed.  I could hear audio both ways.  Unfortunately, all calls placed from the desk phones have no audio now... I had to go back to proxy-based for the time being since people are sitting in the conference room trying to make calls and not getting any audio.
Any ideas why that would be?

[Michael Picher]

Added this to the wiki

http://wiki.sipxcom.org/display/sipXcom/Fortinet+Fortigate+Firewall

Michael Picher, VP of Product Innovation
eZuce, Inc.

300 Brickstone Square

Suite 104

Andover, MA. 01810

O.978-296-1005 X2015 
M.207-956-0262
@mpicher <http://twitter.com/mpicher> 

linkedin
www.ezuce.com

Notice: This transmittal and/or attachments may be privileged or confidential. It is intended solely for the addressee(s) named above. Any dissemination, or copying is strictly prohibited. If you received this transmittal in error, please notify us immediately by reply and immediately delete this message and all its attachments. Thank you. FMS

--

You received this message because you are subscribed to the Google Groups "sipxcom-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-user...@googlegroups.com.
To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at https://groups.google.com/group/sipxcom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/22626d7e-1aff-40d5-b489-18610e630ae4%40googlegroups.com.

[Jim Canfield]

John,

Do you still have a NAT policy?  If so, what does it look like?  You using an IP pool?

[jkjk...@gmail.com]

Yes, Jim.  Thanks for trying to come to my rescue here.

Here's what I got:
- A virtual IP configured and mapped to the sipXcom server internal address
- An IP Pool (one-to-one type) for the external virtual IP address
- Firewall Policies are as follows:
Incoming: LAN
Source Address: SipXcom Server Internal Address
Outgoing Interface: wan1
Destination Address: voip.ms server
Schedule: Always
Service: ALL (Until I get this working I didn't want to limit ports to make sure they aren't part of the problem)
Action: ACCEPT
NAT: On, Fixed Port, Use Dynamic Pool - Virtual IP that is mapped to the sipXcom server

I also have another policy I should mention but I don't think it is doing anything:(Traffic count is not changing for it)
Incoming Interface: wan1
Source Address: voip.ms server
Outgoing Interface: lan
Destination Address: Virtual IP that is mapped to the sipXcom server
Schedule: Always
Service: ALL
Action: Accept
NAT: Off  (I tried it on as well and didn't resolve the issue I had this morning after making the kernel-helper-based change)

Much appreciated,
John

[Jim Canfield]

Have you tried disabling the policy?  You shouldn't need one if you are registering directly from SipX to Voip.MS and your LAN->WAN Policy is allowing the traffic already.  Might be a dumb question, but all your intranet subnets are defined in Internet calling too right?  Also, is UTM "on" on those policies?  

[jkjk...@gmail.com]

Jim,

I have not tried disabling the policy.  I will try that off regular business hours when i re-enable the kernel-helper-based setting to try and get it working properly..  I'm just wondering if it would affect the Virtual IP functionality if I do that (disable the policy).  Either way, I'll give it a shot.  I'm willing to try just about anything at this point.
The intranet subnets are defined in Internet Calling on sipXcom.
UTM is not enabled on any policy at this point.  All profiles (VoIP, Antivirus, IPS, etc) are turned off until I can get this thing working properly.
Anything else you can think of for me to try would be greatly appreciated.

Thanks,
John

[jkjk...@gmail.com]

I'm trying to get this working again.  It seems to be better when I turn off the policy, except two things happen:
1.) It registers on the main external IP address of our WAN, instead of the Virtual IP
2.) It registers on a crazy port (like 64520) instead of the 5080 I usually see on the voip.ms main portal.

Thoughts?
I'm really hoping to keep the Virtual IP if at all possible.
Should NAT be set to yes or no on the voip.ms side?

Thanks,
John

[Jim Canfield]

John, 

It has to be the NAT policy, especially if you are registering on a port like that. The Virtual IP is easily solved with an outbound policy.  I messaged you directly if you want to work on this off-line.

[jkjk...@gmail.com]

It may be good now.

I re-enabled my outbound policy which caused the sipX server to register with the Virtual IP address again (on port 5080).
I also had an inbound policy I was trying, but never saw much traffic on it.  Once I switched over to kernel-helper-based and also turned NAT off the inbound policy, things started working as they should.  My tests calls are working fine, but the true test will be tomorrow when the employees are relying on this system.

Thanks again,
John

[deepakseh...@gmail.com]

Really??