Dialing - dead line until answer

Hi,

I’ve just gone from Asterisk 13 to Asterisk 18, dropping SIP and picking up PJSIP along the way.

The process was mostly straightforward (if a bit painful) and at this point the only thing I know isn’t working is this: When I use the Dial command (the way I am set up) in my dial plan I get no audio.

I am going through another asterisk box that has a PRI card (that box has not been upgraded yet, so it still uses Asterisk 13 and SIP - and the exact same config for the past year or so) so basically it goes like this:

IP Phone dials a number, resulting in the Asterisk box calling Dial(PJSIP/5556667777@pbx2) - > PBX2 just calls Dial(DAHDI/5556667777)

The IP phone is not getting any ringing until I answer my test call at the other end. Dead silence until then. But perfectly good call once answered.

I’m pretty sure this is an endpoint thing, but I tried many settings (and module reload res_pjsip) and nothing’s changed.

When that first PBX was Asterisk 13 and SIP things were fine. but I realize 13 SIP to 18 PJSIP is a big step.

Anyone has an idea for me?

Here is the very basic PJSIP config for the PBX I am dialing through
[pbx2]
type=endpoint
trust_id_inbound=yes
trust_id_outbound=yes
send_pai=yes
transport=transport-udp
context=inbound
allow=all
aors=pbx2
from_domain=192.168.10.5
direct_media=no

[pbx2]
type=aor
contact=sip:192.168.10.5
qualify_frequency=60

[pbx2]
type=identify
endpoint=pbx2
match=192.168.10.5

Is the old system sending early media? If so, do you have Progress() in the dialplan in the new system?

No - I looked and I see no indication of any related settings being needed before.

I looked quickly at the docs, but my first attempts at fixing this failed.

The “old” system (the one making the DAHDI call) hasn’t changed forever. Was it providing early media before? Or did I somehow make this work in a non-standard fashion?

I am not sure how to set up these two things. I tried playing with inbandprogress=yes (and equivalent on PJSIP) and that didn’t work.

I now have added Progress - I tried on the “new server” just before the dial command, then I tried on the other one. No go.

I definitely do not quite know how to use these functions. Maybe it is the early media part that got my stumped…

You’ll need to provide pjsip set logger on logs to understand what is happening. You may also need to use tcpdump/wireshark to listen to any early media that is present, and we may need the verbose level 5 logs from the old system to see what is happening there.

This is slightly obfuscated logger of the originating call (call from the originating system)

Does this clarify anything?

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.10.5:5060;branch=z9hG4bKPj51eaa402-68da-4a32-a87d-75829a3fe681;received=192.168.10.5;rport=5060
From: “Whatever.ca” sip:5145551234@192.168.10.66;tag=d3deca61-9a62-45fe-bd51-b6197320eb49
To: sip:5559873344@192.168.10.66
Call-ID: 3a214cc2-865c-458e-8459-a9bb93352b12
CSeq: 32584 INVITE
Server: Whatever PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: sip:5559873344@192.168.10.66:5060
Content-Length: 0

[2021-11-18 09:50:16] VERBOSE[6336] res_pjsip_logger.c: <— Received SIP response (884 bytes) from UDP:192.168.10.66:5060 —>
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 192.168.10.5:5060;branch=z9hG4bKPj51eaa402-68da-4a32-a87d-75829a3fe681;received=192.168.10.5;rport=5060
From: “Whatever.ca” sip:5145551234@192.168.10.66;tag=d3deca61-9a62-45fe-bd51-b6197320eb49
To: sip:5559873344@192.168.10.66;tag=as0aa431cb
Call-ID: 3a214cc2-865c-458e-8459-a9bb93352b12
CSeq: 32584 INVITE
Server: Whatever PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: sip:5559873344@192.168.10.66:5060
Content-Type: application/sdp
Require: timer
Content-Length: 244

Not really, but Whatever PBX has set up for early media, although you have cut off the INVITE, so one cannot see if the media is set correctly towards the caller, and you have cut off the SDP, so one cannot see if media has been set up correctly towards the callee.

There is no Ringing in in the extract, so progress will only be signalled using early media, if at all.

I think I fixed it - can you sanity-check my logic here?

I was passing dynamic parameters to the Dial command for both the extension to call, the timeout and the options. But in this case the option string was empty. Could this have deactivated the R option (which is default)?

Maybe it didn’t work like that back with Asterisk 13.

Option characters have to be present to change the behaviour.

Not sure what you mean.
R is default (according to the documentation) in the Dial app.

Dial(DAHDI\123456,20) ; presumably includes R as default option, as stated in documentation?

I think I need to do some deep reading of the code, but I don’t think default makes sense as a default when no options parameter is provided. I think for “r”, it means what happens when no parameter is specified. For “R” it may be that there is an undocumented parameter, the same as “r”, or there is a cut and paste error in the header comments.