183 without SDP

Asterisk Asterisk SIP
1

Hello,

I’m facing a problem when my Asterisk receives from carrier a 183 without SDP. The Asterisk is not fowarding the 183 to the phone.

This is the carrier endpoint config:
[trunk_carrier]
type = endpoint
context = CARRIER_NP
dtmf_mode = auto
disallow = all
allow = alaw,ulaw,g729
direct_media = no
aors = trunk_carrier

This is the extension endpoint config:
[ext]
type = endpoint
context = ext_NP
dtmf_mode = auto
disallow = all
allow = ulaw,alaw,g729
direct_media = no
aors = trunk_ext

In this capture the phone started a call

image
image704×441 9.36 KB

The CANCEL I hang up.

Version: Asterisk 16.19.0

Thanks for helping me !

2

16.30.1 is only supported for security issues. 16.19.0 is a lot older than that.

As a back to back user agent, there is no fundamental reason for Asterisk to send 183 with no information.

Also Asterisk doesn’t forward 183; in the general case, it actually sends AST_CONTROL_PROGRESS from the B side to the core, the DIal application forwards that to the B side, which the generates any appropriate signalling (e.g. SIP 183) on the A side.

You need to reproduce on 20.3.1 or 18.18.1 for anyone to really take an interest, and even then the answer may be that it is intended behaviour.

3

and I know there are fixes for this in 18 as I have made them last year
so please upgrade to 18 or 20

4

and when upgraded, i can recommend

allow_sending_180_after_183=yes

too

5

Hello !!!

I upgraded to version 18.18.1. Now Asterisk is forwarding the 183, but it receives from carrier 183 without SDP and sends to the phone 183 with SDP, then the phone opens RTP in its leg and gets without audio, because the carrier does not open 183, since they didn’t send SDP. I did some resources and found that in the some cases carriers use 183 without SDP to ring phones. Is there a way to convert this 183 without SDP to 180 when sending to the phone ?

I added allow_sending_180_after_183=yes in both endpoints configuration phone and carrier.

image

Thanks !

6

nope that is one of the realy anoing limites with asterisk
as long at the core is based on ISUP this will always be a problem
as ISUP have no consept of 183

your only option is to use this option

ignore_183_without_sdp = yes
                           ; Do not forward 183 when it doesn't contain SDP.
                           ; Certain SS7 internetworking scenarios can result in
                           ; a 183 to be generated for reasons other than early
                           ; media.  Forwarding this 183 can cause loss of
                           ; ringback tone.  This flag emulates the behavior of
                           ; chan_sip and prevents these 183 responses from
                           ; being forwarded.
                           ; (default: no)
7

the 183 without SDP is in essence an 100 Trying Harder except that you can add SDP
183 Session Progress just mean somthing is happening we are still working on your call
witch is nice as it normaly indicate that your INVITE is moving from server to server

8

I added this options (ignore_183_without_sdp = yes) but didn’t change anything for the end user. Still without ring tone.

9

yes a 183 without SDP should not generate ringing

so you have 2 options

  1. contact your provider and get them to send 180
  2. create a patch that will change 183 to 180 (fix broken provider)
10

insert this on line 3184
as else to if (sdp && sdp->body.ptr) {
untested as it is just copy paste from the code of 180

		} else { # 183 without SDP change to 180 Ringing to fix broken provider
			ast_trace(-1, "%s: Queueing RINGING\n", ast_sip_session_get_name(session));
			ast_queue_control(session->channel, AST_CONTROL_RINGING);
			ast_channel_lock(session->channel);
			if (ast_channel_state(session->channel) != AST_STATE_UP) {
				ast_setstate(session->channel, AST_STATE_RINGING);
			}
			ast_channel_unlock(session->channel);}
		}
11

I will rebuild to test and let you know !

My code should be like that right:

case 183:
		if (session->endpoint->ignore_183_without_sdp) {
			pjsip_rdata_sdp_info *sdp = pjsip_rdata_get_sdp_info(rdata);
			if (sdp && sdp->body.ptr) {
				ast_trace(-1, "%s: Queueing PROGRESS\n", ast_sip_session_get_name(session));
				ast_trace(1, "%s Method: %.*s Status: %d  Queueing PROGRESS with SDP\n", ast_sip_session_get_name(session),
					(int)rdata->msg_info.cseq->method.name.slen, rdata->msg_info.cseq->method.name.ptr, status.code);
				session->early_confirmed = pjsip_100rel_is_reliable(rdata) == PJ_TRUE;
				ast_queue_control(session->channel, AST_CONTROL_PROGRESS);
			} else { # 183 without SDP change to 180 Ringing to fix broken provider
				ast_trace(-1, "%s: Queueing RINGING\n", ast_sip_session_get_name(session));
				ast_queue_control(session->channel, AST_CONTROL_RINGING);
				ast_channel_lock(session->channel);
				if (ast_channel_state(session->channel) != AST_STATE_UP) {
					ast_setstate(session->channel, AST_STATE_RINGING);
				}
				ast_channel_unlock(session->channel);}
			}
		} else {
			ast_trace(-1, "%s: Queueing PROGRESS\n", ast_sip_session_get_name(session));
			ast_trace(1, "%s Method: %.*s Status: %d  Queueing PROGRESS without SDP\n", ast_sip_session_get_name(session),
				(int)rdata->msg_info.cseq->method.name.slen, rdata->msg_info.cseq->method.name.ptr, status.code);
			ast_queue_control(session->channel, AST_CONTROL_PROGRESS);
		}
		break;

Thanks !

12

I’m using this patch long ago. It’s for asterisk 18.19.0. It handles, too, a special PEM use case.

To use it, you have to set
ignore_183_without_sdp=yes

Regards
Dirk

13

Worked well ! This should be an option in the next version.

14

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