Call Transfer Issue — Asterisk Not Reaching SIP User on call center

Hello everyone,

I’m having a hard time trying to transfer a call to another user through Asterisk.
Here’s my current setup:

  1. Two SIP users: 601 and 602, both with usernames and passwords.
  2. If I register both users locally (on my own machine) using different SIP clients, calls between 601 and 602 work perfectly — audio is fine both ways.
  3. When I call 100 (the bot/orchestrator) from 601, the bot answers correctly. However, when it tries to connect the call to 602, nothing happens — 602 never receives the call.

Background:
JAT is a call center that manages multiple SIP extensions (like 601, 602, etc.) and handles registration, media, and routing.

pjsip.conf

[JAT]
type=endpoint
transport=transport-udp-nat
context=public
disallow=all
allow=g722
allow=ulaw
allow=alaw
direct_media=no
rtp_symmetric=yes
aors=JAT
set_var=PROJECT_ID=Dev
set_var=ORIGIN=phone-sip

[JAT]
type=identify
endpoint=JAT
match=83.240.xxx.xxx

[JAT]
type=aor
contact=sip:83.240.xxx.xxx:5060

extensions.conf

same => n,Dial(PJSIP/602@JAT,60)

SIP INVITE from user 601 when dialing 100 (incoming to Asterisk):

Invite from 601 when dials 100:
INVITE sip:100@135.236.xxx.xxxSIP/2.0
Via: SIP/2.0/UDP 83.240.xxx.xxx;rport;branch=z9hG4bKy1Nae853t8mQg
Max-Forwards: 69
From: “601” sip:FreeSWITCH@135.236.xxx.xxx;tag=U4KcaFvS57rZr
To: sip:100@135.236.xxx.xxx
Call-ID: 4cb4ed43-3b1c-123f-6bba-0050569094df
CSeq: 106960625 INVITE
Contact: sip:gw+07143571-a044-4cb3-9650-d52267267b09@83.240.xxx.xxx:5060;transport=udp;gw=07143571-a044-4cb3-9650-d52267267b09
User-Agent: FreeSWITCH
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: path, replaces
Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 299
X-FS-Support: update_display,send_info
Remote-Party-ID: “601” sip:601@135.236.xxx.xxx;party=calling;screen=yes;privacy=off
v=0
o=FreeSWITCH 1763008824 1763008825 IN IP4 83.240.xxx.xxx
s=FreeSWITCH
c=IN IP4 83.240.xxx.xxx
t=0 0
m=audio 20010 RTP/AVP 9 0 8 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=silenceSupp:off - - - -
a=ptime:20

Asterisk INVITE attempting to call 602 (outgoing)

INVITE sip:602@83.240.xxx.xxx:5060 SIP/2.0
Via: SIP/2.0/UDP 135.236.xxx.xxx:5060;rport;branch=z9hG4bKPj66009da7-e711-4f65-912c-5ef261f6be25
From: “601” sip:FreeSWITCH@172.18.0.4;tag=3c57ef40-1119-48b2-b248-cb62382fbf51
To: sip:602@83.240.200.237
Contact: sip:asterisk@135.236.xxx.xxx:5060
Call-ID: 151f0bc0-e5ff-45b1-9ce6-b8237570b93f
CSeq: 31045 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER, INFO
Supported: 100rel, timer, replaces, norefersub, histinfo
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: Asterisk PBX 18.24.3
Content-Type: application/sdp
Content-Length: 289
v=0
o=- 265572700 265572700 IN IP4 135.236.xxx.xxx
s=Asterisk
c=IN IP4 135.236.xxx.xxx
t=0 0
m=audio 10004 RTP/AVP 9 0 8 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:140
a=sendrec

If anyone has dealt with similar routing issues or knows how to make Asterisk correctly send an INVITE to a remote user (602) on the same call center SIP server, I’d really appreciate the help.

Thank you.

According to the brief output you’ve provided this is incorrect, Asterisk sends a SIP INVITE according to you - so something did happen.

You really need to show the complete SIP trace and the Asterisk console output, otherwise we’re guessing a lot.

Sorry for the delay.
At the moment, I’m not receiving any responses, so Asterisk just keeps sending invites to the contact:

Contact: JAT/sip:83.240.xxx.xxx:5060 b3fa2e189c NonQual nan

That’s why I was wondering if the problem might be with the invite being sent by Asterisk.

You should still see a response, unless it is just ignoring for some reason but nothing stands out in the INVITE.

I believe the receiving router is blocking the message and simply dropping it, because from what I’ve been told, it’s not reaching the JAT FreeSWITCH server. I just needed to make sure the issue wasn’t on my end.

MicroSIP user 601 dials 100 → JAT
JAT From “601” forwards 100 → BOT

BOT will then try and call → 602

Here is the SIP INVITE sent to JAT from my MicroSIP client:

INVITE sip:100@83.240.xxx.xxx SIP/2.0
Via: SIP/2.0/UDP 62.28.xxx.xxx:59819;rport;branch=z9hG4bKPj1c7360c9d31044c1b8e8d0712c468b94
Max-Forwards: 70
From: <sip:601@83.240.xxx.xxx>;tag=861d593f7a5546ac898c7e467284fda3
To: <sip:100@83.240.xxx.xxx>
Contact: <sip:601@62.28.xxx.xxx:59819;ob>
Call-ID: 24930da45c0c4efab9f05c79d79a90ae
CSeq: 10496 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800
Min-SE: 90
User-Agent: MicroSIP/3.22.3
Content-Type: application/sdp
Content-Length: 749

v=0
o=- 3972008449 3972008449 IN IP4 62.28.xxx.xxx
s=pjmedia
c=IN IP4 62.28.xxx.xxx
t=0 0
b=AS:84
b=TIAS:64000
a=X-nat:0
m=audio 4000 RTP/AVP 8 0 9 96 97 98 99 100 101 102 103
a=rtcp:4001 IN IP4 62.28.xxx.xxx
a=sendrecv
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:9 G722/8000
a=rtpmap:96 G7221/16000
a=fmtp:96 bitrate=24000
a=rtpmap:97 G7221/16000
a=fmtp:97 bitrate=32000
a=rtpmap:98 G7221/32000
a=fmtp:98 bitrate=48000
a=rtpmap:99 G7221/32000
a=fmtp:99 bitrate=24000
a=rtpmap:100 G7221/32000
a=fmtp:100 bitrate=32000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:102 telephone-event/16000
a=fmtp:102 0-16
a=rtpmap:103 telephone-event/32000
a=fmtp:103 0-16
a=ssrc:2061701726 cname:6caa2f9c020a58a1

I don’t have anything else to add, the rest is on you to isolate.

Thank you nonetheless.

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