183 SDP Duplicate PJSIP

Hi guys,

I have an Asterisk 16.8.0 with PJSIP that I use as a gateway. The problem occurs as follows:

Leg A sends INVITE to Asterisk and Asterisk passes to Leg B.
Leg B responds to 100 trying and then to 183 SDP.
Asterisk sends to Leg A, 100 trying and twice the 183 SDP.

The picture shows what I summarized.

Can you help me?

PJSIP.conf:

[general]
port = 5060

[LegB]
qualify = yes

[LegA]
qualify = yes

[system]
type=system
follow_early_media_fork = yes

[global]
type = global
user_agent = gw07

[transportudp]
type = transport
protocol = udp
bind = 0.0.0.0

[LegB]
type = aor
contact = sip:my-ip:5060

[LegB]
type = identify
endpoint = LegB
match = my-ip

[LegB]
type = endpoint
context = plataforma
transport=transportudp
ignore_183_without_sdp = yes
force_rport = no
dtmf_mode = rfc4733
disallow = all
allow = g729
allow = alaw
preferred_codec_only=yes
tos_audio = ef
cos_audio = 5
language = pt_BR
aors = LegB

[LegA]
type = aor
contact = sip:my-other-ip:5060

[LegA]
type = identify
endpoint = LegA
match = my-other-ip

[LegA]
type = endpoint
transport = transportudp
context = plataforma
dtmf_mode = rfc4733
disallow = all
allow = g729
allow = alaw
preferred_codec_only=yes
ignore_183_without_sdp = yes
tos_audio = ef
cos_audio = 5
language = pt_BR
aors = LegA

Your trace shows valid SIP protocol; there is no restriction on the number of 183s.

Note that Asterisk is a back to back user agent, not a proxy, so the 183s on the A side don’t have to correspond with one on the B side.

However, someone else recently had problems with this behaviour, so you should have a look through recent postings.

Also, where there is a real problem, it is almost always essential to have the full text of the SIP dialogue, and it is generally best to get that from Asterisk, as people are used to reading it that way.

I researched and haven’t found it in recent. If you know the topic and can pass it on to me, help me.

Example call trace:
Example trace

Another question, do you know why Asterisk sends INVITE during the call, when there is no such thing in the dialplan?

It’s a re-INVITE, without seeing the full SIP trace it could be a media update or it could be a connected line update. It could also be the result of a change that was recently fixed[1].

[1] https://issues.asterisk.org/jira/browse/ASTERISK-28871

@jcolp Thank you for sharing it.

A SIP trace, I don’t know if you can help with anything.
example.txt (51.7 KB)

It is trying to upgrade the session to alaw audio, as you have allowed alaw on the configured endpoint. The remote side is sending a 481 for some reason when they should send a 488. You can either disable alaw as a codec on the endpoint, or apply the patch from the issue I linked.

@jcolp Thank for help me.

@jcolp in version 16.9 and 16.8 occur the same problem.

The patch fix too these versions or only in 16.10?

The fix is applicable there, but I do not know if it will apply to them cleanly.

Patches aren’t normally evaluated for compatibility against earlier sub-versions, as one is expected to use the latest sub-version when trying to resolve a problem.

If the patch is simple, one would expect it to successfully apply against an older sub-version, but no-one is going to spend time checking that.

@jcolp @david551
Thanks guys.