Send SIP 181 when forwarding a call

sergani · March 18, 2023, 9:39am

Hi everyone,

I have a simple Asterisk setup that does the following:
1- caller dials a DID
2- DID is forwarded to my Asterisk box
3- dial plan is configured to forward the call to another external B number

This is a fairly simple DID call flow.

However, I have a requirement in which I need to send a SIP 181 informational response to the inbound leg indicating the B number that the calls I being forwarded to.

I need help here because I don’t know where to start.

Thanks.

david551 · March 18, 2023, 11:47am

Does this help?

https://wiki.asterisk.org/wiki/display/AST/Manipulating+Party+ID+Information#ManipulatingPartyIDInformation-CONNECTEDLINEdialplanfunction

If not you will need to tell us which channel driver you are using as if and how this is possible may be driver dependent. One way or another, though , there will be no direct way of generating 181; it will be case of providing Asterisk with the settings and information needed for it to do this for itself.

The document does say that SIP should update with a provisional response, which probably means 181.

PS I hate the misuse of direct in dialling, by the VoIP industry, to refer any PSTN number that you rent from them.

sergani · March 18, 2023, 5:09pm

Hi David,

Thank you for the feedback. I stumbled upon this page but for some reason I couldn’t get the “simple redirection” example to work. In other words, I wasn’t able to manipulate the calling number on the egress side, and even when asterisk box was forwarding the call there was no SIP 181 being generated to the initial caller.

I’m sure it’s a very simple case but I’m honestly still unable to get it to work and it’s frustrating.

According to the RFC:

21.1.3 181 Call Is Being Forwarded
A server MAY use this status code to indicate that the call is being forwarded to a different set of destinations.

And I don’t find any configuration options that would enforce the generation and sending of the SIP 181 message.

I’m assuming by channel driver you mean which SIP driver, I’m using PJSIP along with Asterisk 20.2.

Any and all help will be greatly appreciated.

david551 · March 18, 2023, 6:15pm

Note that it is a MAY in the RFC, so less than a 50% requirement. However, I believe, if connected line is used correctly it should work.

Unfortunately, I don’t know my way around chan_pjsip as well as chan_sip, and some of the logic may be in PJProject, rather than Asterisk.

However, it would help if you showed the dialplan that tried to set the connected line, in case there is an obvious error.

sergani · March 18, 2023, 6:32pm

Of course. Let me do this as soon as I access the server.

david551 · March 18, 2023, 6:52pm

chan_pjsip should send 181 if it gets AST_CONTROL_REDIRECTING:

github.com

asterisk/asterisk/blob/master/channels/chan_pjsip.c#L1805


      
          				ast_log(LOG_WARNING, "Could not queue task to remotely take session '%s' off hold with endpoint '%s'\n",
          					ast_sorcery_object_get_id(channel->session), ast_sorcery_object_get_id(channel->session->endpoint));
          				ao2_ref(channel->session, -1);
          			}
          		}
          		break;
          	case AST_CONTROL_SRCUPDATE:
          		break;
          	case AST_CONTROL_SRCCHANGE:
          		break;
          	case AST_CONTROL_REDIRECTING:
          		if (ast_channel_state(ast) != AST_STATE_UP) {
          			response_code = 181;
          		} else {
          			res = -1;
          		}
          		break;
          	case AST_CONTROL_T38_PARAMETERS:
          		res = 0;
          
          
		if (channel->session->t38state == T38_PEER_REINVITE) {

I’ve got lost trying to find somewhere that could send that, in your case.

sergani · March 18, 2023, 7:50pm

Hi David,

Thank you for sharing this.

Allow me to share the configs on my end too.

Here’s the pjsip.conf file:

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0

[6001]
type=endpoint
;context=from-internal
context=call-redirect
disallow=all
allow=ulaw
auth=6001
aors=6001

[6001]
type=auth
auth_type=userpass
password=xxxxxx
username=6001

[6001]
type=aor
max_contacts=1

[mytrunk]
type=endpoint
context=from-external
disallow=all
allow=ulaw
outbound_auth=mytrunk
aors=mytrunk

[mytrunk]
type=aor
contact=sip:xxx.xxx.xxx.xxx:5060

Here’s the extensions.conf file. You’ll find the middle section of the last context commented out, but I’ve found it to behave the same whether it’s commented out or not.

[from-internal]
exten = 100,1,Answer()
same = n,Wait(1)
same = n,SayNumber(${EXTEN})
same = n,Playback(hello-world)
same = n,Hangup()

[some-context]
;same = n,Dial(PJSIP/trunk/sip:1234567890@185.231.78.14:5060)
;same = n,REDIRECTING(to-123123123)

[call-redirect]
exten => 1000,1,NoOp
; For Q.SIG or ISDN point-to-point we should determine the COLR for this
; extension and send it if the call was redirected here.
;exten => 1000,n,GotoIf($[${REDIRECTING(count)}>0]?redirected:notredirected)
;exten => 1000,n(redirected),Set(REDIRECTING(to-num,i)=${CALLERID(dnid)})
;exten => 1000,n,Set(REDIRECTING(to-num-pres)=allowed)
;exten => 1000,n(notredirected),NoOp
; Determine that the destination has forwarded the call.
; …
exten => 1000,n,Set(REDIRECTING(from-num,i)=10000001)
exten => 1000,n,Set(REDIRECTING(from-num-pres,i)=allowed)
exten => 1000,n,Set(REDIRECTING(to-num,i)=1234567890)
; The DivertingLegInformation3 message is needed because at this point
; we do not know the presentation (COLR) setting of the redirecting-to
; party.
exten => 1000,n,Set(REDIRECTING(count,i)=$[${REDIRECTING(count)} + 1])
exten => 1000,n,Set(REDIRECTING(reason,i)=cfu)
; The call will update the redirecting-to presentation (COLR) when it
; becomes available with a redirecting update.
exten => 1000,n,Dial(PJSIP/1234567890@mytrunk,20)
exten => 1000,n,Hangup

And here’s a screenshot from the Asterisk server where you can see there is no SIP 181 sent to the caller. As you can see also, the caller ID is not manipulated on the egress call leg, but I’m sure that will be a dial plan mistake (any help there too will be appreciated)

Thank you!

david551 · March 18, 2023, 9:21pm

The last call to REDIRECTING must not have the inhibit option set.

The lack of a 100 response on the outside should not be related to the lack of `181, even if they are using the 181 to permit you to pass through caller ID. 100 should be generated in a timely fashion, and before the request has been fully analyzed.

sergani · March 18, 2023, 9:32pm

Ok, I basically copied and pasted the configuration from the docs. I’ll play around with it tomorrow morning and let you know.

sergani · March 19, 2023, 4:47pm

Hi David, so I’ve spent some time on the box today, basically to clear the link between Asterisk and our SBC. This has been covered and now calls are reaching the SBC. I’ve configured the SBC to kill the calls, so that’s why you’ll see the calls failing with SIP 503.

I ran a few test calls and I can see now that the “new CLI” is showing up under a Diversion header:

I don’t need a Diversion header, so I’ll probably remove the REDIRECTING config lines.

Any idea where to look for how to change the FROM header at least? Do I need to add a predial handler like Set(PJSIP_HEADER(update,From))? If yes, I only need to update the USER part, and not the whole FROM header.

Furthermore, as you can see from the SIP trace screenshot, Asterisk didn’t send the SIP 181 message that I originally opened this topic about

Any thoughts/help on this? It’s a crucial step in my project.

Thanks in advance.

david551 · March 19, 2023, 5:02pm

From is set to the caller ID user part, and a fixed domain name, unless you override it with from_user, in which case it is set to a fixed value for the endpoint.

It is managed by the system, so cannot be manipulated using PJSIP_HEADER.

sergani · March 19, 2023, 5:05pm

Got it, I’ll play around with it a bit.
Any thoughts on the SIP 181 issue?

david551 · March 19, 2023, 5:11pm

I would assume the documentation was wrong, and remove the inhibit option from the last call to REDIRECTING.

sergani · March 19, 2023, 5:47pm

You’re right, removing the inhibit option from the last call to REDIRECTING caused Asterisk to send the SIP 181 to the caller, and I can see the forwarded-to number in the Diversion header. Not bad.

Thank you for all your help David! Appreciated.

sergani · March 21, 2023, 7:45pm

Hi all,

I’m trying to get my Asterisk 20.2 to send reliable SIP 181 messages back to the caller side. I’m using the packaged PJSIP, and so far I’m able to generate SIP 181 but not reliably.

Here’s my extensions.conf file:

[from-internal]
exten => _1XXX,1,NoOp(=== CLD ${CALLERID(dnid) ===)
same => n,GotoIf($[${CALLERID(dnid)} = 1000]?call-redirect,${CALLERID(dnid)},1)

[call1000]
exten => _1XXX,1,NoOp(=== Entered call1000 ===)
same => n,Dial(PJSIP/1234567890@mytrunk,2)
same => n,Hangup

[handler]
;exten => addheader,1,Set(PJSIP_HEADER(update,Via)=“SIP/2.0/UDP 34.79.222.207:5060;rport;branch=z9hG4bKPjbcfde7be-aafa-4401-9bae-11b5835ee13a”)

[call-redirect]
exten => 1000,1,NoOp(=== Entering call-direct ===)
; For Q.SIG or ISDN point-to-point we should determine the COLR for this
; extension and send it if the call was redirected here.
exten => 1000,n,GotoIf($[${REDIRECTING(count)}>0]?redirected:notredirected)
exten => 1000,n(redirected),Set(REDIRECTING(to-num,i)=${CALLERID(dnid)})
exten => 1000,n,Set(REDIRECTING(to-num-pres)=allowed)
exten => 1000,n(notredirected),NoOp(=== Call was not redirected before ===)

exten => 1000,n,Set(REDIRECTING(from-num,i)=10000001)
exten => 1000,n,Set(REDIRECTING(from-num-pres,i)=allowed)
exten => 1000,n,Set(REDIRECTING(to-num,i)=1234567890)
; The DivertingLegInformation3 message is needed because at this point
; we do not know the presentation (COLR) setting of the redirecting-to
; party.
exten => 1000,n,Set(REDIRECTING(count,i)=$[${REDIRECTING(count)} + 1])
exten => 1000,n,Set(REDIRECTING(reason)=follow_me)
; The call will update the redirecting-to presentation (COLR) when it
; becomes available with a redirecting update.
exten => 1000,n,Dial(PJSIP/1234567890@mytrunk,2)
exten => 1000,n,Hangup

Excuse me I’m still trying things so the configurations may not make sense fully.

Thanks in advance.

david551 · March 21, 2023, 8:18pm

Please provide the Supports header, from the provider’s INVITE. If that doesn’t include 100rel, they do not support reliable provisional responses. If they do have this, you must have overridden the 100rel endpoint option.

Alternatively, use TCP, rather than UDP.

sergani · March 21, 2023, 8:23pm

Hi David,

Call comes from a registered account on Asterisk at the moment, and gets diverted to a different B number while a SIP 181 is sent back to it.

Here’s a screenshot of the inbound INVITE message from the SIP client to Asterisk:

david551 · March 21, 2023, 8:42pm

I’d expect 181 to be sent reliably, as long as you have 100rel enabled for the endpoint, which should be the default.

If the provide cannot work without them, they should have a Require: 100rel header, as well.

You haven’t shown the contents of the 181, so I don’t think we can be sure it wasn’t sent reliably, and was lost, or for some reason the PRACK was delayed until after the 503.

The UAS MAY send a final response to the initial request before
having received PRACKs for all unacknowledged reliable provisional
responses,

If the UAS does send a
final response when reliable responses are still unacknowledged, it
SHOULD NOT continue to retransmit the unacknowledged reliable
provisional responses

https://www.ietf.org/rfc/rfc3262.txt

sergani · March 21, 2023, 8:48pm

Apologies, I forgot to include the SIP181:

I’m attaching here as well the section from pjsip.conf that relates to the 6001 account sending the call:

[transport-udp-nat]
type=transport
protocol=udp
bind=0.0.0.0
external_signaling_address=XXXXXXX
external_media_address=XXXXXXX

[6001]
type=endpoint
context=from-internal
disallow=all
allow=ulaw
auth=6001
aors=6001

[6001]
type=auth
auth_type=userpass
password=XXXXXXX
username=6001

[6001]
type=aor
max_contacts=1

david551 · March 21, 2023, 9:07pm

It may be that it doesn’t consider 181 important enough. The RFC only imposes a MAY requirement.