PJSIP shows wrong DIALSTATUS for outgoing call

Asterisk Asterisk SIP
1

Asterisk 16.13.0

pjsip.conf

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

[trunk]
type = aor
contact = sip:XX.XX.XX.XX
qualify_frequency = 30

[trunk]
type = identify
endpoint = trunk
match = XX.XX.XX.XX

[trunk]
type = endpoint
context = from-trunk
dtmf_mode = rfc4733
disallow = all
allow = ulaw
allow = alaw
direct_media = no
aors = trunk

Hi,

Incoming and outgoing calls are working fine. But for outgoing calls PJSIP gives “CHANUNAVAIL” status for those calls which callers are rejecting(BUSY).

PJSIP debug

No. Timestamp (Dir) Address SIP Message
===== ========== ============================== ===================================
00000 1600434532 * ==> XX.XX.XX.XX:5060 INVITE sip:9XXXXXXXXX@XX.XX.XX.XX SIP/2.0
00001 1600434532 * <== XX.XX.XX.XX:5060 SIP/2.0 100 Trying
00002 1600434533 * <== XX.XX.XX.XX:5060 SIP/2.0 183 Session Progress
00003 1600434533 * ==> XX.XX.XX.XX:5060 PRACK sip:XX.XX.XX.XX:5060;transport=udp SIP/2.0
00004 1600434533 * <== XX.XX.XX.XX:5060 SIP/2.0 200 OK
00005 1600434534 * <== XX.XX.XX.XX:5060 SIP/2.0 183 Session Progress
00006 1600434534 * ==> XX.XX.XX.XX:5060 PRACK sip:XX.XX.XX.XX:5060;transport=udp SIP/2.0
00007 1600434534 * <== XX.XX.XX.XX:5060 SIP/2.0 200 OK
00008 1600434534 * <== XX.XX.XX.XX:5060 SIP/2.0 180 Ringing
00009 1600434534 * ==> XX.XX.XX.XX:5060 PRACK sip:XX.XX.XX.XX:5060;transport=udp SIP/2.0
00010 1600434534 * <== XX.XX.XX.XX:5060 SIP/2.0 200 OK
00011 1600434556 * <== XX.XX.XX.XX:5060 SIP/2.0 480 Temporarily Unavailable
00012 1600434556 * ==> XX.XX.XX.XX:5060 ACK sip:9XXXXXXXXX@XX.XX.XX.XX SIP/2.0
00013 1600434559 * ==> XX.XX.XX.XX:5060 OPTIONS sip:XX.XX.XX.XX SIP/2.0
00014 1600434559 * <== XX.XX.XX.XX:5060 SIP/2.0 200 OK

chan_sip gives BUSY status for same calls which i think is correct behavior.
Please help me to solve this issue.

Thanks,
Jay

2

Not a direct answer, but the channel drivers actually return a simulated ISDN cause code (unless they are real ISDN ones), so it is likely to be useful to know what HANGUPCAUSE was actually returned, as the issue with translation could be either incoming or outgoing.

Ideally, one would think that the translations should conform to https://tools.ietf.org/html/rfc3398#page-45 for the outgoing side, and https://tools.ietf.org/html/rfc3398#page-24 for the incoming side.

Because of its back to back user agent nature, you cannot expect Asterisk to losslessly forward anything other that real ISDN cause codes.

3

Thanks for your prompt reply.

with chan_sip => hangup status is BUSY and cause is 19
with chan_pjsip => hangup status is CHANUNAVAIL and cause is 31

4

DIALSTATUS is a function of HANGUPCAUSE.

19 is no answer, not busy,

31 is normal clearing.

480 is the correct status for 19,

You haven’t provided the outgoing leg signalling, so I can’t tell whether 19 is the correct code based on the received status, or are you saying the call wasn’t attempted at all, which would normally indicate a more serious problem than subscriber busy.

app_dial will not set a DIALSTATUS of BUSY unless it has seen at least one cause 17, so I don’t see how you can get 19 and busy, unless another destination was called in parallel and returned busy.

5

I have made two calls. First by using chan_sip and second one by using chan_pjsip.

Yes, I have received 480 response with SIP and PJSIP both. But SIP is translating it as BUSY and PJSIP translating it as CHANUNAVAIL

I am dialing on my own mobile number and hanging call withing first ring.

Hope it is clearer now.

6

Are you saying the 480 is on the outgoing leg?

In that case the RFC says it should be translated to 18 (no user responding).

The channel drivers do not set DIALSTATUS. That is done by the Dial application, and the expected DIALSTATUS for all but a few specific case is CHANUNAVAIL, as that is the fallback.

It does appear that chan_sip translate 480 to no answer, but I think that should cause a NOANSWER DIALSTATUS, not a BUSY one, according to my reading of the code.

Incidentally, DIALSTATUS is only a crude categorisation. In most serious use cases you need to look at HANGUPCAUSE.

It looks to me that both drivers have chosen to diverge from the RFC.

I am dialing on my own mobile number and hanging call withing first ring.

In that case, I’d say the mobile network or your ITSP have already mistranslated the code, as I would reckon the mobile network should have sent cause 21, with a user originate indication, which the ITSP should have translated to 603. That probably comes back as CHANUNAVAIL, as app_dial doesn’t specifically recognize it, so it would fall back to CHANUNAVAIL.

Incidentally 31, appears to be a catch all code, rather than true normal clearing.

7

I appreciate your support and detailed analysis.

I will check with my sip trunk provider if they can send correct hangup cause/status.

8

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