183 SDP Duplicate PJSIP

Asterisk Asterisk SIP
1

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.

183_duplicate
183_duplicate866×551 17.1 KB

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

2

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.

3

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?

4

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

5

@jcolp Thank you for sharing it.

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

6

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.

7

@jcolp Thank for help me.

8

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

The patch fix too these versions or only in 16.10?

9

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

10

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.

11

@jcolp @david551
Thanks guys.

12

@jcolp the patch it’s work correctly. Thanks.

@david551 the question 183 SDP, I see the scenario:

When PSTN return 180 (SDP), Asterisk return to client only one 183 SDP. But, when PSTN return 183 (SDP), Asterisk return to client twice 183 SDP.

image
image706×586 10.9 KB

Do you know if you have any adjustments for that?

13

I think you will find that is is only chan_pjsip that does this.

Why is it a problem? While I suspect it isn’t the intended behaviour, it isn’t invalid behaviour and is something that any compliant UAC should treat as normal.

In fact, because it is UDP, I think it could happen even if it hadn’t been explicitly re transmitted. UDP doesn’t guarantee that packets won’t be lost, won’t be duplicated, and won’t arrive out of sequence.

14

I don’t think it’s retransmission, because I also capture the client and receive both 183 SDP, in addition to receiving both almost at the same time.

@jcolp Do you know what that could be?

15

Not really, but as @david551 said it’s not forbidden in SIP.

16

Agreed, but the point was that the client has to cope with duplication in the network, so it should not cause any problems, if identical ones are transmitted by Asterisk.

17

I understand.

Thank you, guys.

19

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.