No calls between UDP/TCP clients using pjsip.conf

I’m struggling with something very simple I suppose.

I’ve setup a PBX and calls over UDP work just fine. However, when I try to setup a call from an UDP-client (endpoint which has transport=udp), it can’t call the TCP-client (transport=tcp).
Both clients are connected to the same server. Call from the TCP-client to UDP-client works but when the call has ended, TCP-client is unaware of hangup.

I’ve tried to add multiple transports to the same endpoint since the following syntax (valid in sip.conf) doesn’t appear to be working anymore in pjsip.conf:

config_options.c:733 aco_process_var: Error parsing protocol=tls,tcp at line 15

However, it looks like this method also doesn’t work since only the last transport is active.

[242680]
type=endpoint
transport=transport-tcp
transport=transport-udp
direct_media=no

What’s working:
Can someone help me out here?

The transport option in PJSIP is used to explicitly control what transport is used for an endpoint, it doesn’t control what transports are allowed. That’s not currently configurable.

The way that a transport is chosen is based on the underlying SIP URI. This is described on the wiki[1].

For TCP clients you’ll likely want to enable “rewrite_contact” so that the TCP connection which has been established by the client is used for calling it. You will also want to remove the transport option unless you are using the bundled PJSIP, as normal PJSIP has a bug currently where it will not reuse the TCP connection if transport is set.

[1] https://wiki.asterisk.org/wiki/display/AST/PJSIP+Transport+Selection

1 Like

Thanks for the fast reply.

I’ve modified the endpoints as follows:
[227532] (uses UDP)
type=endpoint
direct_media=no

[242680] (uses TCP)
type=endpoint
rewrite_contact=yes
direct_media=no

The UDP-client can call the TCP-client now, which works fine.

<— Transmitting SIP request (1338 bytes) to TCP:172.17.107.185:58442 —>
INVITE sip:242680@172.17.107.185:58442;transport=TCP;rinstance=e248ccf3e33446d8 SIP/2.0
Via: SIP/2.0/TCP 192.168.89.1:5060;rport;branch=z9hG4bKPj3de924a9-5480-4320-8924-7921086429ef;alias
From: “X” sip:22753@192.168.89.1;tag=bd72aa00-b86a-4c39-b8b1-9c3f483eb0a0
To: sip:242680@172.17.107.185;rinstance=e248ccf3e33446d8
Contact: sip:asterisk@192.168.89.1:5060;transport=TCP
Call-ID: 01fa9c01-fbd7-43b6-b9b1-eb87143c8525
CSeq: 29399 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER, MESSAGE, REGISTER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
P-Asserted-Identity: “X” sip:22753@192.168.89.1
Remote-Party-ID: “X” sip:22753@192.168.89.1;privacy=off;screen=no
Max-Forwards: 70
User-Agent: UZPBX
Content-Type: application/sdp
Content-Length: 432

However, when the TCP-client (242680) calls the UDP-client (227532), the UDP-client just keeps ringing. I’ve tried adding/removing rewrite_contact for the UDP-client . It seems that it is using a the IP of the trunk instead of the device itself (wrong FROM-tag).

<— Transmitting SIP request (1093 bytes) to UDP:172.20.121.91:5060 —>
INVITE sip:227532@172.20.121.91:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.89.1:5060;rport;branch=z9hG4bKPjb6a8f5fa-a45e-4882-ade0-e4d8f374cd57
From: “Y” sip:24268@195.162.X.X;tag=38bb4e47-da5c-4456-bf72-3da7e151a862
To: sip:227532@172.20.121.91
Contact: sip:asterisk@192.168.89.1:5060
Call-ID: 0e6bc101-1647-4577-bc51-81c8379017f7
CSeq: 3550 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER, MESSAGE, REGISTER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
P-Asserted-Identity: “Y” sip:24268@195.162.X.X
Remote-Party-ID: “Y” sip:24268@195.162.X.X;privacy=off;screen=no
Max-Forwards: 70
User-Agent: UZPBX
Content-Type: application/sdp
Content-Length: 279

I’m using a normal PJSIP.

Any idea how this occurs?

The From is correct. That’s supposed to be us, same for P-Asserted-Identity and Remote-Party-ID. If you add rewrite_contact to the UDP endpoint you will also need to have it register again to be updated. Nothing else looks abnormal. As well if you don’t want the forum to mangle your SIP message you can add it as preformatted text in the editor.

Got a partial solution, I do had to define a transport for the UDP-client because otherwise the wrong UDP-transport (meant for outtrunk) was chosen.

[227532]
type=endpoint
transport=transport-udp
direct_media=no

I left the TCP-client as follows:

[242680]
type=endpoint
rewrite_contact=yes
direct_media=no

However, every time the UDP-client sets up a call to the TCP-client (which has no transport defined), the following error pops up:
UDP-client calls to TCP-client. INVITE shows following error:

[Jul 14 13:52:14] WARNING[131290]: pjproject:0 <?>: tsx0x7f1e183ee …Failed to send Request msg INVITE/cseq=5542 (tdta0x7f1e18006ea0)! err=171064 (Unsuitable transport selected (PJSIP_ETPNOTSUITABLE))

You’re going to need to provide more console output and configuration.

Okay, here’s is some pjsip.conf configuration:

[transport-udp]
type=transport
protocol=udp
bind=192.168.89.1:5060

[transport-tcp]
type=transport
protocol=tcp
bind=192.168.89.1:5060

[transport-udp-out]
type=transport
protocol=udp
bind=195.162.X.X:5060
local_net=195.162.X.X/XX

[242680]
type=aor
max_contacts=5

[242680]
type=endpoint
rewrite_contact=yes (connects using TCP so needs this parameter as you suggested)
direct_media=no
context=DP_BELGIUM
disallow=all
allow=alaw,ulaw,h264,h261,h263,h263p,vp8
auth=auth242680
aors=242680
send_pai=yes
send_rpid=yes
sdp_session=PBXTEST

[auth242680]
type=auth
auth_type=md5
md5_cred=xxxxxxxxxxxxxxxxxxxxxxxxxxxx
username=xxxx
realm=sip

[227532]
type=aor
max_contacts=5

[227532]
type=endpoint
transport=transport-udp (since otherwise transport-udp-out is used!)
direct_media=no
context=DP_BELGIUM
disallow=all
allow=alaw,ulaw,gsm
auth=auth227532
aors=227532
send_pai=yes
send_rpid=yes
sdp_session=PBXTEST

[auth227532]
type=auth
auth_type=md5
md5_cred=xxxxxxxxxxxxxxxxxxxxxxxxxxxx
username=xxxx
realm=sip

Now, following piece in the asterisk log is a call from 227532 to 242680 which gives the error I posted above (pjsip logger for host 227532).

[Jul 14 14:17:35] VERBOSE[85336][C-000009e9] app_dial.c: Called PJSIP/242680
[Jul 14 14:17:35] VERBOSE[85336][C-000009e9] app_dial.c: Called PJSIP/242681
[Jul 14 14:17:35] VERBOSE[85336][C-000009e9] app_dial.c: Connected line update to PJSIP/227532-0000140a prevented.
[Jul 14 14:17:35] WARNING[132097] pjproject: tsx0x7f1e183ee …Failed to send Request msg INVITE/cseq=16434 (tdta0x7f1d4ce28a10)! err=171064 (Unsuitable transport selected (PJSIP_ETPNOTSUITABLE))
[Jul 14 14:17:35] VERBOSE[85336][C-000009e9] app_dial.c: Connected line update to PJSIP/227532-0000140a prevented.
[Jul 14 14:17:35] VERBOSE[85336][C-000009e9] app_dial.c: PJSIP/242680-0000140b is ringing
[Jul 14 14:17:35] VERBOSE[131290] res_pjsip_logger.c: <— Transmitting SIP response (681 bytes) to UDP:172.20.121.91:5060 —>
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 172.20.121.91:5060;rport=5060;received=172.20.121.91;branch=z9hG4bK1304210852
Call-ID: 623339353-5060-58@BHC.CA.BCB.JB

I believe the problem is with endpoint 242681.

1 Like

Looks like 242681 was also a device conencted with TCP and still had transport=transport-udp present.

Thanks a lot jcolp!