Replying 100rel (PRACK)

FreePBX Endpoints
1

Hi to all,

In a scenario with FPBX, users send 183 with the required 100rel so parties expect to receive the PRACK and then respond OK, but Asterisk just responds OK to caller PRACK and does not forward PRACK to the callee then callee resends 183. So is there any specific config in pjsip for that? any idea?

Current call flow is:

A–INVITE—> FPBX —INVITE—> B
A <–183— FPBX <—183—B
A --PRACK—> FPBX B
A <–OK— FPBX B
A FPBX <–183—B

So B keeps sending 183 as it doesn’t receive any PRACK

PS: versions => FPBX-15.0.17.55 and Asterisk 18.6.0

2

Asterisk is a back to back user agent. Each leg will be handled independently for 100Rel. There is no support for end to end operation.

3

Thanks @david55 David. you are right it is B2BUA, but we shouldn’t expect that Asterisk sends PRACK to B party? when it responds OK to A party after receiving PRACK.

PS: B party sends 183 with 'Require: 100rel' and pjsip 100rel=required is set, then FPBX sends 183 with the same header to A party.

4

I checked pjsip settings more and seems just we have 100rel option. so any idea?

5

The best you could hope for is:

A–INVITE—> FPBX —INVITE—> B
A FPBX <—183—B
A FPBX—PRACK —> B
A FPBX <—OK—B
A <–183— FPBX B
A --PRACK—> FPBX B
A <–OK— FPBX B

That’s if I understand your notation and noting that there is only a partial ordering, so this is only one possible valid sequence - the key point is 100Rel is hop by hop, and the PRACK to B is not dependent on successful transmission of 183 to A, and can come before, or after, the first transmission to A.

B has to offer 100Rel for this to work.

6

Internally there will be an unacknowledged:

A_side_channel—AST_CONTROL_PROGRESS—>Dialplan_application

consequent on the

A FPBX <—183—B

and an unacknowledged

Dialplan_application —AST_CONTROL_PROGRESS—>B_side_channel

prior to

A <–183— FPBX B

7

eee thanks for your reply. But as I see the Asterisk is not responding to the B party 183, so you think it might be a dialplan mistake?
sorry I didn’t get the last part of your answers :frowning:

8

I think the B party doesn’t claim to support 100Rel.

9 
<--- Received SIP response (1369 bytes) from TCP:10.0.0.1:5060 --->
SIP/2.0 183 Session Progress
.
.
Call-ID: b51bfb6b-75ac-4bda-b009-8c37e659bd7f
Content-Type: application/sdp
Supported: timer, 100rel, precondition, gruu
RSeq: 5949
Require: precondition, 100rel
CSeq: 5949 INVITE
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, UPDATE, INFO, REFER, NOTIFY, MESSAGE, PRACK
Content-Length: 293

but I can see the Require in 183 from B party.

10

I was actually thinking one stage back, which is the Allow: PRACK, but you have that.

Can you provide the Asterisk INVITE, to confirm that it is sending Supports: 100rel? If it is, there does seem to be a problem with Asterisk as UAC. You will have to provide a full protocol trace before you can follow it up as a bug with Asterisk

The 100rel UAS transaction with party A is not related to the 100rel settings on the party B side except in as much as the the 183 triggers the sending of 183.

11 
Allow: INVITE, ACK, CANCEL, BYE, UPDATE, MESSAGE, OPTIONS, REFER, INFO, NOTIFY, PRACK
Supported: timer,100rel,precondition,gruu
User-Agent: SM-G975W-G975WVLU4FUA2 SIPs
Content-Length: 367

This is part of the first INVITE and below is INVITE that goes out from Asterisk to callee:

Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub, histinfo
Require: 100rel
12

Is the contact header correct on the 183? It looks to me as though PRACK is sent to the contact address, not the original address, as the RFC says a session has to be established. I’m not completely sure of my interpretation, here.

Why are you trying to use 100rel on a reliable transport? Whilst there doesn’t seem to be anything about it in the RFC, even final responses are not re-sent on reliable transports. Asterisk may well be confused by the conflict between 100rel requiring retransmission and the reliable transport making it unnecessary.

I certainly cannot see anything you gain by using 100rel over a reliable transport.

Again, I will point out that, if this ever ends up with a bug report, selected fragments of the INVITE dialogue are not going to be acceptable, and even here it is giving a feeling of being drip fed.

1 Like
13

Thanks @david55, I did not post at the beginning because I thought might there be a miss-configuration. So you can take a look to logs here: <--- Received SIP request (1777 bytes) from TCP:10.0.0.67:34906 --->INVITE sip - Pastebin.com

14

Wow, you have a complex network, with at least one proxy, possibly a separate router/firewall and media server. Please explain the topology:

What is the device (make/model) at 10.0.0.50? Is that the original source of the call? What transport is it using?

What is at 10.0.0.67? What are its intended functions?
What is at 10.0.1.247? Is it physically separate from the device at 10.0.0.67?

I assume that FreePBX/Asterisk is at 10.0.0.193. If not, please explain.

Are all these addresses on the same subnet, or at least directly routed? If not, please provide details (VPN, etc.)

Some stuff looks fishy: For example, line 107 is a User-Agent header, but this is a response, which should have a Server header instead. Although this does not directly cause any trouble, I suspect that a device with a faulty SIP stack may also be inappropriately dealing with 100rel.

Since 100rel offers no benefit when TCP transport is used, can you just turn it off on your endpoints?

I’m curious about the 8-digit numbers, which seem too long to be extensions. Are they PSTN numbers in your country? What is the function of FreePBX (CO switch, etc.)?

15

Yes you are right @Stewart1. device is a mobile app that needs 100rel and we can not change.
but I am trying to remove other things in network and get a new log to share with you.

193 is Asterisk, 67 and 247 are proxy servers.

16

I could not much remove those elements from the network.
Just I have a doubt, is it correct that Asterisk put the ‘Require’ header in INVITE and then forwards it?

As I see in the RFC, it should not do this, and the ‘Supported’ header is enough in INVITE, and just we need the ‘Require’ header in 100x messages (like 183).
So, this behavior mixes up the call flow!

17

Asterisk doesn’t forward SIP requests. As previously mentioned each side is completely independent with its own configuration, what happens on one side for PRACK has no influence or bearing on the other side for PRACK.

It is perfectly fine within the spec to have a Require header in an INVITE with 100rel.

18

Thanks, @jcolp for your reply. Yes, you are right, but usually, we see ‘Require’ in 100x messages.
I hope you check the logs that I shared, Asterisk as a B2BUA when receiving a 183 with "Required: 100rel’, it should respond PRACK??

PS: It seems my endpoints just support provisional 183 and they have an issue with Rseq that put in RAck header.

19

Should this discussion be better moved to an Asterisk forum?

1 Like
20

I would expect it to. That being said, I haven’t looked at 100rel in a number of years including the PJSIP implementation of it.

1 Like