Acme Packet 4500
 
Net-Net OS
 

PLA-Support>Sun Systems>CommsGBU>Session Delivery Network>SN-SND: Acme Service Provider
 

In this Document

Symptoms

Cause

Solution

Created from <SR 3-14440840171>

Applies to:

Symptoms

Some of the messages from a specific end customer/session agent are randomly not responded by the SBC
The example below is with INVITE but this can also occur with ACK or other messages

Cause

A potential issue for this issue is the customer reusing the same branch parameter in the Via in subsequent INVITEs.
 
It is possible to reproduce this in the lab, here is a sample sipmsg.log:

FIRST INVITE: branch=z9hG4bK-ABC33123456789 and Call-ID: 1-28070@10.165.125.68

> Mar 17 12:04:55.312 On [0:0]10.174.85.180:5060 received from 10.165.125.68:5060
> INVITE sip:+12345103@10.174.85.180:5060 SIP/2.0
> Via: SIP/2.0/UDP 10.165.125.68:5060;branch=z9hG4bK-ABC33123456789
> From: 0013022030700 <sip:0013022030700@10.174.85.180>;tag=1
> To: sut <sip:+12345103@10.174.85.180>
> Call-ID: 1-28070@10.165.125.68
> CSeq: 1 INVITE
> Contact: sipp <sip:sipp@10.165.125.68>
> Max-Forwards: 70
> Subject: Performance Test
> Content-Type: application/sdp
> Content-Length: 137
>
> v=0
> o=user1 53655765 2353687637 IN IP4 10.165.125.68
> s=-
> c=IN IP4 10.165.125.68
> t=0 0
> m=audio 6000 RTP/AVP 8
> a=rtpmap:8 PCMA/8000
>
> ----------------------------------------
> Mar 17 12:04:55.312 On [0:0]10.174.85.180:5060 sent to 10.165.125.68:5060
> SIP/2.0 100 Trying
> Via: SIP/2.0/UDP 10.165.125.68:5060;branch=z9hG4bK-ABC33123456789
> From: 0013022030700 <sip:0013022030700@10.174.85.180>;tag=1
> To: sut <sip:+12345103@10.174.85.180>
> Call-ID: 1-28070@10.165.125.68
> CSeq: 1 INVITE
>
>

SECOND INVITE: branch=z9hG4bK-ABC33123456789 and Call-ID: 2-44444@10.165.125.68
> ----------------------------------------
> Mar 17 12:04:55.413 On [0:0]10.174.85.180:5060 received from 10.165.125.68:5060
> INVITE sip:+12345103@10.174.85.180:5060 SIP/2.0
> Via: SIP/2.0/UDP 10.165.125.68:5060;branch=z9hG4bK-ABC33123456789
> From: 0013022030700 <sip:0013022030700@10.174.85.180>;tag=2
> To: sut <sip:+12345103@10.174.85.180>
> Call-ID: 2-44444@10.165.125.68
> CSeq: 1 INVITE
> Contact: sipp <sip:sipp@10.165.125.68>
> Max-Forwards: 70
> Subject: Performance Test
> Content-Type: application/sdp
> Content-Length: 137
>
> v=0
> o=user1 53655765 2353687637 IN IP4 10.165.125.68
> s=-
> c=IN IP4 10.165.125.68
> t=0 0
> m=audio 6000 RTP/AVP 8
> a=rtpmap:8 PCMA/8000


Then in the "100 Trying" for second INVITE, the Call-ID of the first INVITE is sent:
> ----------------------------------------
> Mar 17 12:04:55.413 On [0:0]10.174.85.180:5060 sent to 10.165.125.68:5060
> SIP/2.0 100 Trying
> Via: SIP/2.0/UDP 10.165.125.68:5060;branch=z9hG4bK-ABC33123456789
> From: 0013022030700 <sip:0013022030700@10.174.85.180>;tag=1
> To: sut <sip:+12345103@10.174.85.180>
> Call-ID: 1-28070@10.165.125.68
> CSeq: 1 INVITE

This occurs because the SBC identifies the transaction of the second INVITE as the transaction of first INVITE. The reason for this is the fact that both INVITEs use the same branch parameter instead of a unique one.

It is possible to find such sample cases by tracing all the traffic from this session-agent for some time until the issue is reproduced,  and look for two INVITE messages with the same branch parameter. For each INVITE message there is a corresponding 100 Trying, but both the 100 Trying replies contain the Call-ID of the first INVITE, meaning the second INVITE message will fail.

Solution

If two different INVITE messages reuse the same branch parameter, then that is incorrect as per SIP RFC 3261, here is a quote from the RFC:

8.1.1.7 Via
(...)
The branch parameter value MUST be unique across space and time for all requests sent by the UA.

The recommended solution is that the end customer corrects the branch parameter
 

This solution has no attachment