Send SIP 181 when forwarding a call

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.

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.

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.

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.

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

chan_pjsip should send 181 if it gets AST_CONTROL_REDIRECTING:

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

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!

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.

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

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 :rofl:

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

Thanks in advance.

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.

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

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

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.

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.

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.

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:

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

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

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