The pSIP protocol packets dropped by the SRX ALG module but other SIP traffic can pass through the SRX normally

May 14 11:01:52 11:01:51.902661:CID-1:THREAD_ID-16:RT:<x.x.x.x/5060->x.x.x.x/5060;17,0x0> matched filter 1:

May 14 11:01:52 11:01:51.902663:CID-1:THREAD_ID-16:RT:packet [189] ipid = 47587, @0xfc05dcd2

May 14 11:01:52 11:01:51.902677:CID-1:THREAD_ID-16:RT: plugin name junos-alg. action JSF_SESSION_ACTION_NONE, stbuf 0x0

May 14 11:01:52 11:01:51.902709:CID-1:THREAD_ID-16:RT: jsf drop pak pid 27, jbuf 0xe2569280, release hold 0, sess_id 10294237

May 14 11:01:52 11:01:51.902711:CID-1:THREAD_ID-16:RT:PKT-PROC for plugin junos-alg jbuf 0xe2305c00, sess jsf flags 0x0, rc 7

May 14 11:01:52 11:01:51.902712:CID-1:THREAD_ID-16:RT:flow_proc_rc: -1.

Line 183: May 14 11:01:49 11:01:49.518137:CID-1:THREAD_ID-01:RT: jsf drop pak pid 27, jbuf 0xf692d3c0, release hold 0, sess_id 10294237

Line 255: May 14 11:01:52 11:01:51.902709:CID-1:THREAD_ID-16:RT: jsf drop pak pid 27, jbuf 0xe2569280, release hold 0, sess_id 10294237

Line 327: May 14 11:01:53 11:01:53.519068:CID-1:THREAD_ID-01:RT: jsf drop pak pid 27, jbuf 0xf5026200, release hold 0, sess_id 10294237

Line 399: May 14 11:01:57 11:01:57.522084:CID-1:THREAD_ID-01:RT: jsf drop pak pid 27, jbuf 0xf5026200, release hold 0, sess_id 10294237

Line 471: May 14 11:02:00 11:02:00.013217:CID-1:THREAD_ID-01:RT: jsf drop pak pid 27, jbuf 0xf4da9900, release hold 0, sess_id 10294237

To resolve this issue, we first need to determine why the SRX SIP ALG dropped these packets.

Upon checking these packets with Wireshark, we found that these packets have the following characteristics:

1. Transport layer protocol is UDP;
2. Source and destination port are both 5060;
3. Can't see the SIP header in the application layer instead of a string of meaningless characters.

Therefore, we can now confirm that this is not a standard RFC SIP implementation, so the SRX SIP ALG module cannot process these packets properly and discards them as a result.

Next, we right-click on a packet and select “Follow UDP Stream” to examine the entire interaction in Wireshark. At this point, we discover some useful information.

The PDT here means police digital trunking and it use a Non-RFC standard signaling protocol called pSIP.

PDT (Police Digital Trunking), also known as Professional Digital Trunking, is a digital trunked radio communication standard with independent Chinese intellectual property rights, primarily developed for and mandated within China's public safety sector (police, fire, emergency services) . It was formulated under the leadership of the Ministry of Public Security of China to address the specific needs of China's emergency communication networks.

pSIP (PDT Session Initiation Protocol) is a specialized, text-based signaling protocol optimized from the standard IETF SIP (Session Initiation Protocol, RFC 3261) for PDT system interconnection.

Ultimately, the following configuration allowed the pSIP protocol and the corresponding RTP traffic to traverse the SRX successfully:

1. Create a custom application with application-protocol ignore to selectively bypass SIP ALG processing for pSIP:

user@device# show applications
application sip-AppIgnore {
     application-protocol ignore;
     protocol udp;
     destination-port 5060;
}

2.Create a policy by using the custom application.

user@device# show security policies from-zone untrust to-zone trust
policy test {
    match {
        source-address any;
        destination-address any;
        application sip-AppIgnore;
    }
    then {
        permit;
        log {
            session-init;
            session-close;
        }
    }
} 

3.Create another security policy to permit the calling media traffic(data channel).