[Home]

Summary:ASTERISK-25589: Improve documentation on transport configuration
Reporter:Anatoli (anatoli)Labels:
Date Opened:2015-11-23 11:54:48.000-0600Date Closed:2016-11-10 20:33:51.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Documentation pjproject/pjsip
Versions:13.6.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Ubuntu 14.04, PJProject 2.4.5Attachments:( 0) pjsip.log
Description:[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@trunk1,,
SCCP/105-00000008    (None)               Ring    Dial(PJSIP/xxxxxxxx@trunk1,,
SCCP/105-0000000b    (None)               Ring    Dial(PJSIP/xxxxxxxx@trunk1,,
SCCP/105-0000000c    (None)               Ring    Dial(PJSIP/xxxxxxxx@trunk1,,
SCCP/105-0000000d    (None)               Ring    Dial(PJSIP/xxxxxxxx@trunk1,,
SCCP/102-0000001b    (None)               Ring    Dial(PJSIP/xxxxxxxx@trunk1,,
SCCP/102-0000001a    (None)               Ring    Dial(PJSIP/xxxxxxxx@trunk1,,
SCCP/102-0000000e    (None)               Ring    Dial(PJSIP/xxxxxxxx@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
Comments:By: Asterisk Team (asteriskteam) 2015-11-23 11:54:50.279-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Rusty Newton (rnewton) 2015-11-24 09:46:12.861-0600

Are each of your addresses bound to physical interfaces or is one of them a virtual interface?
By: Anatoli (anatoli) 2015-11-24 10:02:36.697-0600

The 10.101.10.1 (TCP) is a virtual interface, the 192.168.215.83 (UDP) is a physical one. Does it matter?
By: Joshua C. Colp (jcolp) 2015-11-24 10:06:25.772-0600

You will need to inform PJSIP you want the SIP URI to use the TCP transport using the following contact:

contact = sip:10.101.10.11\;transport=tcp

The \ in there is on purpose or else the config parser will treat the ";transport=tcp" as a comment.
By: Anatoli (anatoli) 2015-11-25 20:02:15.649-0600

Joshua, thanks! That's it. I've tried it without the backslash and I understand now it was interpreted as a comment, though it's quite confusing that {{transport = transport-tcp}} was not enough in the endpoint section for the aor to be considered of TCP type. Also quite strange was the general behavior of hanging up calls for the trunk transport.

I think we can close this issue, maybe with a pending ToDo of adding some clarifications to the documentation.
By: Alexei Gradinari (alexei gradinari) 2016-02-03 16:42:07.712-0600

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

By: Rusty Newton (rnewton) 2016-11-10 20:33:51.486-0600

Bug was fixed. Doesn't look like we need any additional documentation in this area at the moment. If someone finds an issue or improvement for the documentation then please file a new issue.