[asterisk-bugs] [JIRA] (ASTERISK-25589) Improve documentation on transport configuration

[Richard Mudgett (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-25589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=229266#comment-229266 ] 

Richard Mudgett edited comment on ASTERISK-25589 at 2/3/16 5:01 PM:
--------------------------------------------------------------------

It's not documentation issue.
It's ASTERISK-25316 bug.



was (Author: alexei gradinari):
It's not documentation issue.
It's ASTERISK-25316 bug.
https://issues.asterisk.org/jira/browse/ASTERISK-25316

> Improve documentation on transport configuration
> ------------------------------------------------
>
>                 Key: ASTERISK-25589
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25589
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Documentation, pjproject/pjsip
>    Affects Versions: 13.6.0
>         Environment: Ubuntu 14.04, PJProject 2.4.5
>            Reporter: Anatoli
>            Assignee: Unassigned
>         Attachments: pjsip.log
>
>
> [Edit by Rusty - This issue is now a documentation improvement issue. See last comments for the specific issue. In short the documentation can be confusing in regards to when you should edit the contact in an endpoint's aor to specify the transport.]
> 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)