How UAC should handle SIP 183 Session Progress

asterisksip

I have the following scenario:

2 UAC are trying to talk, via a remote SIP server (openSER/Kamailio 3.1.3) = client infrastructure.
The UAC software was developed over a local test infrastructure using Asterisk, where it was possible to establish a normal call.

The problem is that testing on the client infrastructure there's no audio.

I have no knowledge of the complete client infrastructure, but from the logs/responses from the server (Routing Header fields) can be concluded that
there's a Proxy Authorization server, and a CiscoSystem SIP GW, as well as PSTN.
And not least we're behind NAT and the client is also behind NAT. AFAIK there's no STUN sever used.

The main difference in the call flow is that in the testing infrastructure we always have received 180 Messages (Ringing), while in the client infrastructure we receive 183 Session in Progress. In the logs it's seen that both devices start to send rtp streams, but still there's no audio.

I also have a commercial software, with which we tested the client infrastructure and it works. We have compared the messages send from the commercial software, and our client
and there's almost no difference.

The only difference I was able to find is that in the messages after the inv/407/ack loop:

commercial soft:

start fresh new branch number x

  • sends inv + auth string – branch/trans num x

  • gets response – branch/trans num x

  • send ack message – branch/trans num x

our client:

start fresh new branch number y

  • sends inv + auth string – branch/trans num y

  • gets response – branch/trans num y

  • send ack message – A FRESH new branch/transaction – z

Could this be a reason to result in lost audio problem? This same scenario works OK in Asterisk.

Best Answer

(I've assumed the entities involved are RFC 3261 SIP devices, and have ignored interop with RFC 2543 devices.)

If NATs are involved the very first thing you should check are

  • the IPs in your c= headers in the SDP payloads
  • the IPs in your Contact headers

In particular, these IPs should all be reachable by the other party.

In your "after inv/407/ack" scenarios, the ACK to a non-2xx response should have the same branch id. However, a 2xx response terminates the INVITE transaction, so an ACK to a 2xx response will have a different branch to that of the INVITE.

(While of course RFC 3261 is the definitive resource for SIP basics, I find RFC 3665 extremely helpful for seeing how things work.)

Related Topic