[asterisk-bugs] [JIRA] (ASTERISK-25589) Incorrect transport used for PJSIP/contact
Anatoli (JIRA)
noreply at issues.asterisk.org
Tue Nov 24 10:03:33 CST 2015
[ https://issues.asterisk.org/jira/browse/ASTERISK-25589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=228448#comment-228448 ]
Anatoli edited comment on ASTERISK-25589 at 11/24/15 10:02 AM:
---------------------------------------------------------------
The 10.101.10.1 (TCP) is a virtual interface, the 192.168.215.83 (UDP) is a physical one. Does it matter?
was (Author: anatoli):
The 10.101.10.1 (TCP) is a virtual address, the 192.168.215.83 (UDP) is a physical one. Does it matter?
> 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
> Assignee: Unassigned
> Attachments: pjsip.log
>
>
> 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/xxxxxxxx at trunk1,,
> SCCP/105-00000008 (None) Ring Dial(PJSIP/xxxxxxxx at trunk1,,
> SCCP/105-0000000b (None) Ring Dial(PJSIP/xxxxxxxx at trunk1,,
> SCCP/105-0000000c (None) Ring Dial(PJSIP/xxxxxxxx at trunk1,,
> SCCP/105-0000000d (None) Ring Dial(PJSIP/xxxxxxxx at trunk1,,
> SCCP/102-0000001b (None) Ring Dial(PJSIP/xxxxxxxx at trunk1,,
> SCCP/102-0000001a (None) Ring Dial(PJSIP/xxxxxxxx at trunk1,,
> SCCP/102-0000000e (None) Ring Dial(PJSIP/xxxxxxxx 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)
More information about the asterisk-bugs
mailing list