PRACK is not stopping retransmission 183 session progress

Asterisk Asterisk SIP
1

Good morning, we have a strange problem. We are using Asterisk 20.6.0.

We receive calls from an operator who requests prack support (so we have set the parameter 100rel=peer_supported).

Asterisk receives the call and simply forwards it to a destination, however when we receive the OK message from the destination operator (leg B) this is not propagated to leg A, instead a 183 session progress is sent.

The code in extension is simple:

exten = _+x.,1,NoOp()

same = n,Set(__myCALLED=${CALLERID(dnid)}) ; B NUMBER
same = n,Set(__myCALLING=${CALLERID(num)}) ; A NUMBER

same = n,Progress()
same = n,Ringing()

same = n,Dial(PJSIP/${myCALLED}@DESTINATION_IP,b(handler^addheader_standard^1))

same = n,Hangup()

noOK
noOK800×604 35.7 KB

Naturally, the source operator, not seeing OK arriving after a certain period, drops the call. Has anyone had a similar problem and knows how to fix it?

By the way… if I set 100rel=yes (instead of 100rel=peer_supported) everything running fine but the source operaror require 100rel.

Thanks in advance.

2

Asterisk is a back to back user agent. It doesn’t forward SIP requests. It terminates them, and generates internal events, which may, after additional processing, result in a similar SIP request, on the other side, if both sides use SIP.

Generally, for something like this, we would need the Asterisk full log, with, assuming the current channel driver, “pjsip set logger on” in effect. Your message sequence chart doesn’t distinguish between OK’s for the PRACK and OK’s for INVITE.

For some reason, the source is failing to PRACK the 183. Without the full log I can’t tell if Asterisk is expecting a PRACK for that.

3

image

The A side has been closed down because it failed to respond with PRACK.

4

Hello David, the 200 OK what you see after the PRACK is related to the PRACK itself, in fact then at the next 183 there is no PRACK and therefore Asterisk sends the call down.

In your opinion, is it possible to eliminate the subsequent 183 and have only one sent? This is because it appears that the originating operator ignores the 183s following the first causing the anomaly in question. They argue that it is an RFC specification and therefore the only solution is to remove the 183 following the first.

5

It is the first 183 that is causing the problem. The PRACK is for the 100. The subsequent 183s are retransmissions of the first one, and, if you insist on PRACK, the only way of stopping those is to receive a PRACK, or to reject 100rel at the first step.

You seem to be suggesting that rejecting 100rel is not acceptable to the provider, in which case it is up to the provider to implement 100rel correctly.

6

Hi David, what you wrote could be valid however in the 100 response there is no “Require: 100rel” header and therefore the PRACK is not generated from the source.

I report here the complete sip dialogue between source and Asterisk.

SOURCE => ASTERISK

INVITE sip:+39021234567@xxxx.it;user=phone SIP/2.0
Via: SIP/2.0/UDP 89.89.89.89:5060;branch=z9hG4bKgv8tab00e8gru8kbpmb0.1
To: sip:+39021234567@xxxx.it;user=phone
From: “+390666666666” sip:+390666666666@yyyy.it;user=phone;tag=20643d77-0017-0001-0000-0000
Call-ID: e5de7520d76fc3c-0017-0001-0000-0000@10.5.46.168
CSeq: 1 INVITE
Max-Forwards: 64
Contact: sip:+390666666666@89.89.89.89:5060;transport=udp
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, MESSAGE, NOTIFY, REGISTER, INFO, REFER, SUBSCRIBE, PUBLISH, PRACK, UPDATE
Supported: 100rel
P-Asserted-Identity: sip:+390666666666@yyyy.it;user=phone;cpc=ordinary
Accept-Contact: *;audio;+g.3gpp.icsi-ref=“urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel”
Accept: application/sdp, application/isup, application/xml
Content-Type: application/sdp
Content-Length: 199
Route: sip:+39021234567@80.65.65.65:5060;user=phone;lr

v=0
o=- 1762684937 1 IN IP4 89.89.89.89
s=-
c=IN IP4 89.89.89.89
t=0 0
m=audio 17178 RTP/AVP 18 8 101
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=maxptime:240

SOURCE <= ASTERISK

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 89.89.89.89:5060;rport=5060;received=89.89.89.89;branch=z9hG4bKgv8tab00e8gru8kbpmb0.1
Call-ID: e5de7520d76fc3c-0017-0001-0000-0000@10.5.46.168
From: “+390666666666” sip:+390666666666@yyyy.it;user=phone;tag=20643d77-0017-0001-0000-0000
To: sip:+39021234567@xxxx.it;user=phone
CSeq: 1 INVITE
Server: GrSBC
Content-Length: 0

SOURCE <= ASTERISK

SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 89.89.89.89:5060;rport=5060;received=89.89.89.89;branch=z9hG4bKgv8tab00e8gru8kbpmb0.1
Call-ID: e5de7520d76fc3c-0017-0001-0000-0000@10.5.46.168
From: “+390666666666” sip:+390666666666@yyyy.it;user=phone;tag=20643d77-0017-0001-0000-0000
To: sip:+39021234567@xxxx.it;user=phone;tag=c4ef50c1-fae1-4510-83fe-2967f6a74f91
CSeq: 1 INVITE
Server: GrSBC
Contact: sip:80.65.65.65:5060
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, INFO, MESSAGE, REFER
Require: 100rel
RSeq: 19166
Content-Type: application/sdp
Content-Length: 225

v=0
o=- 1762684937 3 IN IP4 80.65.65.65
s=GrSBC
c=IN IP4 80.65.65.65
t=0 0
m=audio 27956 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:140
a=sendrecv

SOURCE => ASTERISK

PRACK sip:80.65.65.65:5060 SIP/2.0
Via: SIP/2.0/UDP 89.89.89.89:5060;branch=z9hG4bKhffusk0000qc8ur75gk0.1
To: sip:+39021234567@xxxx.it;user=phone;tag=c4ef50c1-fae1-4510-83fe-2967f6a74f91
From: “+390666666666” sip:+390666666666@yyyy.it;user=phone;tag=20643d77-0017-0001-0000-0000
Call-ID: e5de7520d76fc3c-0017-0001-0000-0000@10.5.46.168
CSeq: 2 PRACK
Max-Forwards: 64
RAck: 19166 1 INVITE
Content-Length: 0

SOURCE <= ASTERISK

SIP/2.0 200 OK
Via: SIP/2.0/UDP 89.89.89.89:5060;rport=5060;received=89.89.89.89;branch=z9hG4bKhffusk0000qc8ur75gk0.1
Call-ID: e5de7520d76fc3c-0017-0001-0000-0000@10.5.46.168
From: “+390666666666” sip:+390666666666@yyyy.it;user=phone;tag=20643d77-0017-0001-0000-0000
To: sip:+39021234567@xxxx.it;user=phone;tag=c4ef50c1-fae1-4510-83fe-2967f6a74f91
CSeq: 2 PRACK
Server: GrSBC
Content-Length: 0

SOURCE <= ASTERISK

SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 89.89.89.89:5060;rport=5060;received=89.89.89.89;branch=z9hG4bKgv8tab00e8gru8kbpmb0.1
Call-ID: e5de7520d76fc3c-0017-0001-0000-0000@10.5.46.168
From: “+390666666666” sip:+390666666666@yyyy.it;user=phone;tag=20643d77-0017-0001-0000-0000
To: sip:+39021234567@xxxx.it;user=phone;tag=c4ef50c1-fae1-4510-83fe-2967f6a74f91
CSeq: 1 INVITE
Server: GrSBC
Contact: sip:80.65.65.65:5060
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, INFO, MESSAGE, REFER
Require: 100rel
RSeq: 19166
Content-Type: application/sdp
Content-Length: 225

v=0
o=- 1762684937 3 IN IP4 80.65.65.65
s=GrSBC
c=IN IP4 80.65.65.65
t=0 0
m=audio 27956 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:140
a=sendrecv

SOURCE <= ASTERISK

SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 89.89.89.89:5060;rport=5060;received=89.89.89.89;branch=z9hG4bKgv8tab00e8gru8kbpmb0.1
Call-ID: e5de7520d76fc3c-0017-0001-0000-0000@10.5.46.168
From: “+390666666666” sip:+390666666666@yyyy.it;user=phone;tag=20643d77-0017-0001-0000-0000
To: sip:+39021234567@xxxx.it;user=phone;tag=c4ef50c1-fae1-4510-83fe-2967f6a74f91
CSeq: 1 INVITE
Server: GrSBC
Contact: sip:80.65.65.65:5060
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, INFO, MESSAGE, REFER
Require: 100rel
RSeq: 19166
Content-Type: application/sdp
Content-Length: 225

v=0
o=- 1762684937 3 IN IP4 80.65.65.65
s=GrSBC
c=IN IP4 80.65.65.65
t=0 0
m=audio 27956 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:140
a=sendrecv

SOURCE <= ASTERISK

SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 89.89.89.89:5060;rport=5060;received=89.89.89.89;branch=z9hG4bKgv8tab00e8gru8kbpmb0.1
Call-ID: e5de7520d76fc3c-0017-0001-0000-0000@10.5.46.168
From: “+390666666666” sip:+390666666666@yyyy.it;user=phone;tag=20643d77-0017-0001-0000-0000
To: sip:+39021234567@xxxx.it;user=phone;tag=c4ef50c1-fae1-4510-83fe-2967f6a74f91
CSeq: 1 INVITE
Server: GrSBC
Contact: sip:80.65.65.65:5060
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, INFO, MESSAGE, REFER
Require: 100rel
RSeq: 19166
Content-Type: application/sdp
Content-Length: 225

v=0
o=- 1762684937 3 IN IP4 80.65.65.65
s=GrSBC
c=IN IP4 80.65.65.65
t=0 0
m=audio 27956 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:140
a=sendrecv

SOURCE <= ASTERISK

SIP/2.0 500 Reliable response timed out
Via: SIP/2.0/UDP 89.89.89.89:5060;rport=5060;received=89.89.89.89;branch=z9hG4bKgv8tab00e8gru8kbpmb0.1
Call-ID: e5de7520d76fc3c-0017-0001-0000-0000@10.5.46.168
From: “+390666666666” sip:+390666666666@yyyy.it;user=phone;tag=20643d77-0017-0001-0000-0000
To: sip:+39021234567@xxxx.it;user=phone;tag=c4ef50c1-fae1-4510-83fe-2967f6a74f91
CSeq: 1 INVITE
Server: GrSBC
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, INFO, MESSAGE, REFER
Supported: 100rel, replaces, norefersub
Content-Length: 0

7

Checked the RFC 3262 : “A UAS MUST NOT attempt to send a 100 (Trying) response reliably.
Only provisional responses numbered 101 to 199 may be sent reliably.
If the request did not include either a Supported or Require header
field indicating this feature, the UAS MUST NOT send the provisional
response reliably.”

It would seem that the issue is that PJSIP fails to detect the response PRACK to the first 183 and continues to send another 183 (with the same RSEQ) as if it had not received a response to the first.

8

I misread the message sequence chart, and I agree the that retransmissions should have stopped.

I would assume this will have to be pushed back to PJPROJECT but I think you need to raise an issue, against Asterisk, on the github issue tracker. Note that the requirement to cease retransmission is a SHOULD, not a MUST, so it isn’t violating the RFC by retransmitting, although it is by blocking the final response.

Meanwhile, maybe change the subject of this thread to reflect the that the real problem is the PRACK is not stopping retransmission.

9

For anyone who stumbles upon this, the Asterisk issue is here: [bug]: PRACK is not stopping retransmission 183 session progress · Issue #794 · asterisk/asterisk · GitHub

10

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