[SOLVED] DPMA is not working as expected

I have Asterisk certified/11.6-cert16 and DPMA 11.0_3.4.1 (64bit version in /usr/lib64).
All connections are without NAT and all devices can communicate with each other.
Network scheme is as follows:
Asterisk Server <-> Linux Gateway <-> Cisco ASA <-> Cisco ASA <-> branch gateway (Zyxel ZyWall) <-> Digium D40
I don’t use multicating and use option66.

When I register phone manually everything works ok.
When I wait for a phone to retrieve the configuration from an Asterisk server nothing happens.
When I update phone firmware manually via the WebGUI (to the 2_2_2_3_D40_firmware.eff) and then hit Reload button in the WebGUI I can see an output in below commands:

  1. digium_phones show sessions
  2. digium_phones show tokens

But can’t see anything in “sip show peers”.

I’ve this lines in sip.conf:
accept_outofcall_message = yes
outofcall_message_context = dpma_message_context
auth_message_requests = no

Can you locate a phone on the same network as the Asterisk server and retry? Then compare the output of the command digium_phones show sessions to a phone that is at the branch. What I’m curious about is if it shows a session for both phones, or just the one where the configuration download works.

sgriepentrog, thank you for your reply, I’ll write back after testing your suggestion.

sgriepentrog, tested your suggestion with both DPMA 1.6 & DPMA 3.4.1
sip show peers
5212 (Unspecified) D a 0 UNKNOWN
5777/5777 D a 5060 OK (3 ms)

digium_phones show sessions
---- Digium Phone Module Active Sessions ----
SessionID:238350042953788025 SecondsAlive:572 SecondsLastActivity:554 Contact:sip:;ob Auth:Yes Inactive:No MAC:000FD3056EEE
SessionID:18950309621206061959 SecondsAlive:858 SecondsLastActivity:850 Contact:sip: Auth:Yes Inactive:No MAC:000FD306E01A
— Total active sessions:2 —

digium_phones show tokens
---- Valid Tokens ----
phone_5777 MAC:000FD3056EEE URI:sip: SessionID:238350042953788025
phone_5212 MAC:000FD306E01A URI:sip: SessionID:18950309621206061959
---- 2 Tokens Found ----

Please, mark this as [SOLVED]
Found out that this behavior was due to the Cisco ASA “fragment” command. So I’ve configured ASA with “fragment chain 1 NeededInterface” which prevented fragmented packets flow. Resolved via excluding this command from the config (to be frankly “show run all fragment” shows that “fragment” command on any interface allows 24 elements to be in a fragment set (which as it turns out is sufficient for DPMA to work)).