[asterisk-bugs] [JIRA] (ASTERISK-29242) pjsip: Documentation for transport handling is short / partly wrong
Michael Maier (JIRA)
noreply at issues.asterisk.org
Thu Aug 26 14:04:34 CDT 2021
[ https://issues.asterisk.org/jira/browse/ASTERISK-29242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=256085#comment-256085 ]
Michael Maier commented on ASTERISK-29242:
------------------------------------------
Well, they are both about transport - but the goals seem to be completely different to me. If I got you correctly, your final goal is to automatically find an existing transport for a trunk register (based on NAPTR e.g.). This means, there is no given / configured dependency between register and transport.
My goal is the complete opposite: each Register gets its own and individual transport.
What's the use case?
- Asterisk resides on a machine with many different interfaces and networks
- Providing security / availability by network design - no fail2ban necessary at all
- One of the interfaces is a dynamic interface providing a dynamic global IP (via pppoe e.g.)
- Asterisk gets connected by internal phones and connects itself via Register to several trunks to SIP providers using RFC 5626.
- Asterisk Registers several numbers to the same SIP provider (-> same destination for several trunks)
- The trunks have to use TLS
If you would let Asterisk decide which device / transport to use, it most probably would use the pppoe interface for Registration to the trunk. But this would be pretty bad, because it would open a completely unnecessary listener to the internet and Asterisk must be restarted to handle the changed interface after pppoe restart.
Therefore it's better to use an internal interface and configure NAT (see [here|https://www.ip-phone-forum.de/threads/asterisk-pjsip-und-nat-nicht-so-einfach-wie-man-glaubt.310575/post-2434183]).
Another problem is: You would route all trunks to the same SIP provider through the same connection, which is bad, too, because if one of the trunks is unregistered, the SIP provider (at least Deutsche Telekom) will drop the complete connection, which breaks all other trunks using the same connection, too.
To solve all the requirements, you have to define several transports (which can reside on the same interface). Each trunk now is getting its own transport. This ensures, that each trunk gets its own RFC 5626 flow and each trunk acts completely independent of all other trunks - even if they are using the same destination server.
I hope I was able to explain the goal how the transport can be used, too and that this should be part of the documentation.
> pjsip: Documentation for transport handling is short / partly wrong
> -------------------------------------------------------------------
>
> Key: ASTERISK-29242
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-29242
> Project: Asterisk
> Issue Type: Improvement
> Security Level: None
> Components: Documentation
> Affects Versions: 18.0.1, 18.1.0
> Environment: CentOS 7 x86_64, pjsip
> Reporter: Michael Maier
> Assignee: Unassigned
>
> I did some research on the meaning of transports and what they are used for. I used this documentation [here|https://wiki.asterisk.org/wiki/display/AST/Asterisk+18+Configuration_res_pjsip#Asterisk18Configuration_res_pjsip-endpoint_transport] and [here|https://github.com/asterisk/asterisk/blob/master/configs/samples/pjsip.conf.sample] - the latter list some example transports and states:
> "; You can have more than one of any type of transport, as long as it doesn't
> ; use the same resources (bind address, port, etc) as the others."
> The statement, that there can't be different transports using same bind address and port seems to be wrong as I can define (and use) pretty much transports using the same bindaddr like 0.0.0.0 (you even can omit the port completely if you define a method(?) - I think the port is derived by the standard port of the given method). If you use the port "0", no bind seems to be done (at the beginning) at all (at least you can't see it in netstat).
> You should write something about the usage of a transport when used for a trunk, i.e. an endpoint, which registers itself to an ISP e.g.
> If you do not specify any transport for this trunk, the first appropriate transport would be used automatically according documentation (in FreePBX, it's impossible to not define any transport for a trunk - you always have to define one).
> You should write, that all trunks e.g. are using the same connection to the ISP, if you register more than one number (yes, that's not seldom), if they are using the same transport. If you want asterisk to use another local port for the n-th trunk configuration to the same ISP (and therefore an own connection per registered number), you have to define n equal transports, which only differ in their name (there are ISPs which can't handle correctly n registered numbers using the same connection and I doubt asterisk can - because I faced strange timeout problems under certain conditions e.g.).
> Could you please adjust the existing documentation to clarify those points? Especially, what exactly happens if you use port 0.
> (The asterisk versions I mentioned above are just examples because I must set some version)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list