Are you still using Brekeke SIP Server version 3.5.2.8?
If so, let you upgrade it to the latest version because there are new logging function which may help your analysis.

http://www.brekeke.com/downloads/sip-server.php

> Should I place each gateway with its capacity (using route.underlimit) plus $continue=true in its own dial plan entry to make it use sequentially all gateways or can I put al gateways in a single dial plan entry? You don't need "$continue=true" in the DeployPattern because if $route.underlimit ...

SRTP is defined in SDP so it is negotiable. It means the gateway simply ignores SDP attributes about SRTP and sends back non-SRTP SDP with 200 OK response. For TLS, it is not negotiable generally. Since Brekeke SIP Server can convert TLS to another transport protocol such as UDP, let you consider to ...

Matching Patterns
$request = ^INVITE
$getHost(Contact) = ^1\.1\.1\.1$|^2\.2\.2\.2$
To = sip:(1212.+)@
$route.underlimit("gateway1","30") = true

Try this.

Matching Patterns
$request = ^INVITE
$addr = ^1\.1\.1\.1$|^2\.2\.2\.2$
To = sip:(1212.+)@
$route.underlimit("gateway1","30") = true

Deploy Patterns
To = sip:%1@172.16.1.101
$routename = gateway1
$continue = true

Which SIP client product are you using?

Generally an order of these SIP headers are not important.

Is it the same sipphone 2 at both server1 and server 2 testings?

If so, is it the same IP address from server 1 and server 2?

Which firewall product are you using for SIP Server 1? Can you go to [Dial Plan]->[History] page after you make a test call over the Server 1? And then click the latest field number which indicates "INVITE". If so, the both Incoming and Outgoing packets are shown. At the Outgoing packet, check ...

Go to [Status]->[SIP Server] status page and find the [interface] filed. Does it show the SIP Server's public IP address? If not, set the public IP address at [Configuration]->[System] page -> [Interface address 1] field, and then restart the SIP Server. Refer the following wiki topic. http://wiki ...

You can ignore "407" in the error log. It will happen if you use SIP authentication in the SIP Server. SIP client will retry REGISTER with the credential after 407. That's why you found the account record in the [Registered Clients] page. For 408, it seems REGISTER packet or its response was lost in ...

Use Linux's "route" command.

Which SIP client products are you using?

Can you find "404" in the SIP Server's [Logs]->[Error Logs] or [Session Logs]?

If you found "404" in the [Error Logs], you have a problem in DialPlan.
If you found "404" in the [Session Logs], you have a problem in PBX's ARS.

Have you edited DialPlan rules?
If you use ARS, you don't have to edit DialPlan.

Also let me know the name of ITSP if possible..

Ha,

Have you read this?
http://wiki.brekeke.com/wiki/Setup-for-Connecting-ITSP

Can you capture INVITE packet if you make a incoming call?
If not, the ISP didn't send calls to the Brekeke PBX.

If there are no records which indicate incoming calls, it seems ISP didn't send calls to the Brekeke PBX.

Which ISP is it?
Does the issue happen always?

Are there any records in [SIP Server]->[Logs]->[Session Logs] and [Error Logs] which indicate incoming calls?

Have you looked at this API doc? It will meet the requirement.
http://www.brekeke.com/doc/sip/sip_acco ... plugin.txt

Are INVITE and UPDATE using a same Call-ID?

Are you sure the above DialPlan rule is executed?
It seems $rtp=false is not called.

Check it at the DialPlan History page.


> c=117.22.xx.xx

Is it the caller side's global IP address?
Or is it the SIP Server's IP address?

You don't have to worry about 407 because it happens every time if the SIP Server authenticates SIP requests.

For 481, can you find it in the Error logs page?
Which SIP request method was it? INVITE?

Since re-INVITE is not initial request, "100 Trying" will not be sent. "any requests" means "any initial request". Refer the Brekeke SIP Server's document about "100 Trying" http://www.brekeke.com/doc/sip/sip_admin_v3.pdf#page=33 > So my question is, how could I cancel the previous re-INVITE? Are ...

As I said, Call-ID of NOTIFY should be unique if you want to catch it with DialPlan. It means DialPlan doesn't catch a SIP packet if it is sent within an existing dialog. Are you sure NOTIFY doesn't share a dialog with other SIP requests such as INVITE or SUBSCRIBE? Add this line in the [Config ...

What does "passes through" mean?
Do you mean that the SIP Server forwards NOTIFY without an issue but can not catch it with DialPlan?