183 Duplicate in Leg A

[edualopes]

Hi guys,

I have an Asterisk 16.9.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 = e1sp7

[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
asymmetric_rtp_codec = no
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
asymmetric_rtp_codec = no
tos_audio = ef
cos_audio = 5
language = pt_BR
aors = LegA

[jcolp]

Is it actually causing a problem?

[edualopes]

No, but I understand that it is not normal behavior. When running with Chan_SIP I don’t have this scenario.

I had to change from Chan_SIP to PJSIP because of q850 reason that did not behave well with Chan_SIP.

[jcolp]

There’s nothing inherently within SIP that prevents such a thing, but to really look deeper you’d need to provide the actual SIP trace.