[asterisk-bugs] [JIRA] (ASTERISK-25589) Incorrect transport used for PJSIP/contact

[Anatoli (JIRA)]

Anatoli created ASTERISK-25589:
----------------------------------

             Summary: Incorrect transport used for PJSIP/contact
                 Key: ASTERISK-25589
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25589
             Project: Asterisk
          Issue Type: Bug
      Security Level: None
          Components: pjproject/pjsip
    Affects Versions: 13.6.0
         Environment: Ubuntu 14.04, PJProject 2.4.5
            Reporter: Anatoli


Hi,

I've found the following issue: on a multi-homed server the transport used by Asterisk to connect to a SIP endpoint is incorrect (not only the IP, but also the protocol).

So, the server has a transport with IP1.UDP to communicate with a SIP trunk provider:

{noformat}
[transport-trunk]
type = transport
protocol = udp
bind = 192.168.215.83
{noformat}

Then it has another transport with IP2.TCP to communicate with local SIP phones:

{noformat}
[transport-tcp]
type = transport
protocol = tcp
bind = 10.101.10.1
{noformat}

When the phones are configured to use the transport-tcp to communicate with Asterisk, everything works OK:


{noformat}
[def_ep](!)
type = endpoint
direct_media = no
context = internal
disallow = all
allow = g722,ilbc
device_state_busy_at = 2
allow_subscribe = yes
sub_min_expiry = 30

[def_auth](!)
type = auth
auth_type = userpass

[def_aor](!)
type = aor
max_contacts = 2147483647
remove_existing = no


[108](def_ep)
callerid = John Doe <108>
auth = 108
aors = 108

[108](def_auth)
username = JDoe
password = xxx

[108](def_aor)
{noformat}
\\

Now, if in addition to the configuration above, Asterisk is instructed to communicate with a SIP phone using {{Contact}}:

{noformat}
[777](def_ep)
callerid = Jane Doe <777>
transport = transport-tcp
auth = 777
aors = 777

[777](def_auth)
username = JnDoe
password = xxx

[777]
type = aor
contact = sip:10.101.10.11
qualify_frequency = 15
{noformat}

It starts showing the following warnings:

{{pjsip:0 <?>:  tsx0x7feeb8013 .Failed to send Request msg OPTIONS/cseq=42068 (tdta0x7feeb80122f0)! err=120001 (Operation not permitted)}}


And in the firewall log I see blocked packets with the following details:

{{SRC=192.168.215.83 DST=10.101.10.11 LEN=436 TOS=0x00 PREC=0x00 TTL=64 ID=21338 DF PROTO=UDP SPT=5060 DPT=5060 LEN=416 UID=0 GID=0}}


So, not only it sends the {{OPTIONS}} request from an incorrect IP using an incorrect transport, but as a result it also uses an incorrect protocol (UDP instead of TCP).

At the same time calls to the SIP trunk somehow hang up with:

{noformat}
[Nov 23 14:11:23] NOTICE[25084]: pbx_impl/ast/ast.c:424 sccp_wrapper_asterisk_carefullHangup: SCCP/105-00000007: (sccp_wrapper_asterisk_carefullHangup) processing hangup request, using carefull version. Standby.
[Nov 23 14:11:23] NOTICE[25084]: pbx_impl/ast/ast.c:426 sccp_wrapper_asterisk_carefullHangup: SCCP/105-00000007: (sccp_wrapper_asterisk_carefullHangup) Already Hungup. Forcing SCCP Remove Call. {noformat}

And then there are a lot of calls from the same extensions in RING state:

{noformat}
CLI> core show channels
Channel              Location             State   Application(Data)
SCCP/105-00000007    (None)               Ring    Dial(PJSIP/45530998 at trunk1,,
SCCP/105-00000008    (None)               Ring    Dial(PJSIP/45530998 at trunk1,,
SCCP/105-0000000b    (None)               Ring    Dial(PJSIP/43109910 at trunk1,,
SCCP/105-0000000c    (None)               Ring    Dial(PJSIP/43109910 at trunk1,,
SCCP/105-0000000d    (None)               Ring    Dial(PJSIP/1544090598 at trunk1
SCCP/102-0000001b    (None)               Ring    Dial(PJSIP/48055132 at trunk1,,
SCCP/102-0000001a    (None)               Ring    Dial(PJSIP/43936500 at trunk1,,
SCCP/102-0000000e    (None)               Ring    Dial(PJSIP/1520282030 at trunk1
{noformat}
\\

If I completely remove the SIP trunk (UDP) transport & related info and only leave the TCP transport, Asterisk complains that there is no transport for the protocol when trying to Contact the SIP phone. So I guess it somehow thinks that the 777 endpoint/aor should be contacted using UDP no matter what.
\\
\\

In the attached file there is a PJSIP log & pjsip show endpoints/aors output.

Regards,
Anatoli



--
This message was sent by Atlassian JIRA
(v6.2#6252)