Re: [asterisk-dev] Asterisk not responding

[LSV]

On Sat, Feb 6, 2021 at 1:09 AM Joshua C. Colp  wrote:

> On Fri, Feb 5, 2021 at 11:05 AM Silvan Nagl  wrote:
>
>> Hi,
>>
>> on larger webrtc setup we noticed that Asterisk 16.13.0 will start to
>> (deadlock)?
>> Asterisk keeps running without crashing but will not response to any new
>> connections.
>> Full logs attached.
>>
>> It seams like 91 threads are in state "__lll_lock_wait" the mutex of
>> these point to thread 80 which does the webrtc stuff.
>> For some reason thread 80 gets a "get_write_timeout" which now starts to
>> destroy the transports while the other 91 threads still have a lock on
>> thread 80. Thread 80 has no other mutex locks.
>>
>> The strace does not belong to the core dump.
>>
>> We will test against 16.16 soon.
>>
>>
> Are you storing transports in realtime? If so and you switch to using
> .conf file, does the issue resolve itself?
>
> --
> Joshua C. Colp
> Asterisk Technical Lead
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [PJSIP] Controlling RTP Media Source IP?

[LSV]

pin

ср, 6 янв. 2021 г. в 1:02, Mark Murawski :

> Hi!
>
> I have the following situation here:
>
> ;;;
> ; WAN1 and traffic to PBX-A / PBX-B
>
> [transport-udp]
> type   = transport
> symmetric_transport= yes
> protocol   = udp
> bind   = 10.13.13.38:5060
> external_media_address = XX.94.171.40
> external_signaling_address = XX.94.171.40
> external_signaling_port= 5060
> allow_reload   = yes
> tos= cs3
> cos= 3
> local_net  = 192.168.181.0/24
> local_net  = 10.13.13.0/24
>
> [transport-tcp]
> type   = transport
> symmetric_transport= yes
> protocol   = tcp
> bind   = 10.13.13.38:5060
> external_media_address = XX.94.171.40
> external_signaling_address = XX.94.171.40
> external_signaling_port= 5060
> allow_reload   = yes
> tos= cs3
> cos= 3
> local_net  = 192.168.181.0/24
> local_net  = 10.13.13.0/24
>
> [transport-tcp-tls]
> type   = transport
> symmetric_transport= yes
> protocol   = tls
> allow_reload   = yes
> bind   = 10.13.13.38:5061
> external_media_address = XX.94.171.40
> external_signaling_address = XX.94.171.40
> external_signaling_port= 5061
> tos= cs3
> cos= 3
> cert_file  = /etc/asterisk/keys/asterisk.crt
> priv_key_file  = /etc/asterisk/keys/asterisk.key
> method = tlsv1_2
> local_net  = 192.168.181.0/24
> local_net  = 10.13.13.0/24
>
>
> ;;
> ;;; WAN2
> ;
> [transport-udp-wan2]
> type   = transport
> symmetric_transport= yes
> protocol   = udp
> bind   = 10.13.13.39:5060
> external_media_address = YY.9.5.40
> external_signaling_address = YY.9.5.40
> external_signaling_port= 5060
> allow_reload   = yes
> tos= cs3
> cos= 3
> local_net  = 192.168.181.0/24
> local_net  = 10.13.13.0/24
>
> [transport-tcp-wan2]
> type   = transport
> symmetric_transport= yes
> protocol   = tcp
> bind   = 10.13.13.39:5060
> external_media_address = YY.9.5.40
> external_signaling_address = YY.9.5.40
> external_signaling_port= 5060
> allow_reload   = yes
> tos= cs3
> cos= 3
> local_net  = 192.168.181.0/24
> local_net  = 10.13.13.0/24
>
> [transport-tcp-wan2-tls]
> type   = transport
> symmetric_transport= yes
> protocol   = tls
> allow_reload   = yes
> bind   = 10.13.13.39:5061
> external_media_address = YY.9.5.40
> external_signaling_address = YY.9.5.40
> external_signaling_port= 5061
> tos= cs3
> cos= 3
> cert_file  = /etc/asterisk/keys/asterisk.crt
> priv_key_file  = /etc/asterisk/keys/asterisk.key
> method = tlsv1_2
> local_net  = 192.168.181.0/24
> local_net  = 10.13.13.0/24
>
> I then have the following call
>
> INVITE
> (Call is attached)
>
> Packet from: ZZ.75.184.42
> Packet To: -> YY.9.5.40  (Ie: WAN2), Then firewall DNATs to
>10.13.13.39:5061, and asterisk gets the call
>
> Use Case:
> Now... in order for this dual-wan to operate correctly... say WAN1 is
> down.  Asterisk needs to be able to send RTP traffic (not just SIP
> Signalling) using the correct rtp bind, associated to the correct return
> transport and external_media_address
>
> My expectation here is that since Asterisk knows it's using
> transport-tcp-wan2-tls, and it has set the correct media source in the
> SDP to YY.9.5.40, that the RDP engine would then send media from
> 10.13.13.39.  But it does not
>
> During the above call, the outgoing RTP looks like this from tcpdump:
> 08:52:13.234702 IP 10.13.13.38.16384 > ZZ.75.184.42.7078: UDP, length 182
>
> The closest thing I've found so far in digging deeper to resolve this
> is: res_pjsip_sdp_rtp.c
>
> static int create_rtp(struct ast_sip_session *session, struct
> ast_sip_session_media *session_media,
>  const pjmedia_sdp_session *sdp)
> {
> snip
>  transport =
> ast_sorcery_retrieve_by_id(ast_sip_get_sorcery(), "transport",
>  session->endpoint->transport);
>  if (transport) {
>  struct 

Re: [asterisk-dev] Asterisk / pjsip: Bug or feature? TCP/TLS connection is endless after unregistering the last trunk to the destination

[LSV]

What you do?

сб, 16 янв. 2021 г. в 2:55, LSV :

> What you do?
>
> вт, 12 янв. 2021 г. в 0:28, Joshua C. Colp :
>
>> On Mon, Jan 11, 2021 at 10:21 AM Michael Maier 
>> wrote:
>>
>>> Hello!
>>>
>>> I'm analyzing the transports opened by or for a Registration to an ISPs
>>> trunk. Here: transport type flow.
>>>
>>> I can reproducibly see, that on Asterisk start up are always two
>>> connections created to register a trunk. The first one looks like this:
>>>
>>
>> 
>>
>>
>>>
>>> It differs in the log output already at the beginning:
>>> [2021-01-11 13:21:24] DEBUG[8570] pjproject:tlsc0x7fa1d82efae8
>>> TLS client transport created
>>> vs
>>> [2021-01-11 13:21:24] DEBUG[8570] pjproject:tlsc0x7fa1d8324ec8
>>> .TLS client transport created
>>>^
>>> What does this dot mean? Where is it coming from?
>>>
>>
>> This is a message from the PJSIP library itself forwarded up, not sure
>> why there's a period there.
>>
>>
>>>
>>> It is possible to tcpkill the first connection without being restarted:
>>>
>>> # tcpkill -i eth0 tcp port 54761
>>> [2021-01-11 14:42:15] DEBUG[8569] pjproject:tlsc0x7fa1d82efae8
>>> TLS connection closed
>>> [2021-01-11 14:42:15] DEBUG[8569] res_pjsip/pjsip_transport_events.c:
>>> Reliable transport 'tlsc0x7fa1d82efae8' state:DISCONNECTED
>>> [2021-01-11 14:42:15] DEBUG[8569] pjproject:   sip_transport.c
>>> Transport tlsc0x7fa1d82efae8 shutting down, force=0
>>> [2021-01-11 14:42:15] DEBUG[8569] res_pjsip/pjsip_transport_events.c:
>>> Reliable transport 'tlsc0x7fa1d82efae8' state:SHUTDOWN
>>> [2021-01-11 14:42:15] DEBUG[8569] res_pjsip/pjsip_transport_events.c:
>>> Reliable transport 'tlsc0x7fa1d82efae8' state:DESTROY
>>> [2021-01-11 14:42:15] DEBUG[8569] pjproject:tlsc0x7fa1d82efae8
>>> TLS transport destroyed with reason 120104: Connection reset by peer
>>>
>>> If you're doing the same against Telekom, they drop the first connect
>>> after 10 s (therefore no tcpkill is necessary)
>>>
>>> Any idea why there are 2 connections started though only one is
>>> necessary? This is really odd.
>>>
>>
>> Nope. The code itself wasn't explicitly designed or written for this
>> usage, so there may be issues with it.
>>
>> 
>>
>>
>>> It seems, that the first register is done through the first connection -
>>> all following registers are done by the second connection (can be seen in
>>> the tcpdump trace).
>>> Things would be much more analyzable btw, if asterisk pcap trace would
>>> contain the local port of the connection, too - or if it would tell, which
>>> connection it is using.
>>>
>>
>> Knowing what the source IP address and port that is in use at the point
>> of logging is difficult. Noone is actively working on changing that, but
>> nothing to say it couldn't change in the future.
>>
>> --
>> Joshua C. Colp
>> Asterisk Technical Lead
>> Sangoma Technologies
>> Check us out at www.sangoma.com and www.asterisk.org
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Strange seg fault

[LSV]

пн, 18 янв. 2021 г. в 21:19, Killian Matter :

> the function that is executed and get a seg fault is one that reset the
> struct, but none of the calls of this function in the module is used, it's
> really like the audiohook update it's state ( so i suppose from the hang
> up) and then it launch the function i don't know why...
> Maybe on hang up it doesn't have much time to detach audiohook and the
> dialplan goes on so some data are freed before the detach of audiohook and
> datastore do their job and so seg fault.
>
> Killian MATTER
>
>
> Le lun. 18 janv. 2021 à 12:08, Joshua C. Colp  a écrit :
>
>> On Mon, Jan 18, 2021 at 7:00 AM Killian Matter 
>> wrote:
>>
>>> Hello, i'm working on a module, it has struct that is malloc and free (
>>> a function used in the dialplan to clean everything up). The problem is
>>> that after the clean up a "wild" audiohook update occurs and after that a
>>> custom function from my module is executed and get an seg fault.
>>>
>>
nnn

> it look like a sync problem but is it even possible ? (e didn't ever see a
>>> sync prob in C language)
>>>
>>
>> It is entirely possible for something to be used after it is freed, if
>> care is not taken to ensure it remains valid. Unfortunately there's not
>> really enough information to be able to answer further with any certainty
>> as to what is going on.
>>
>> --
>> Joshua C. Colp
>> Asterisk Technical Lead
>> Sangoma Technologies
>> Check us out at www.sangoma.com and www.asterisk.org
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>http://lists.digium.com/mailman/listinfo/asterisk-dev
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Looking for guidance on what I'm missing to be able to build

[LSV]

ср, 20 янв. 2021 г. в 7:50, Dan Cropp :

> Last year, I had no issue working on a feature I submitted for a different
> issue.
>
>
>
> I am running Ubuntu 16.
>
> I made a branch from master for a feature I am working on.
>
> When I run make menuselect, I am seeing the following output.
>
>
>
> Any suggestions?
>
Dodo?!
Readme?!
Whait?!
How?!
Ping?!

> ***
>
>   The existing menuselect.makeopts file did not specify
>
>   that 'test_mwi' should not be included.  However, either some
>
>   dependencies for this module were not found or a
>
>   conflict exists.
>
>
>
>   Either run 'make menuselect' or remove the existing
>
>   menuselect.makeopts file to resolve this issue.
>
> ***
>
>
>
>
>
> ***
>
>   The existing menuselect.makeopts file did not specify
>
>   that 'test_res_pjsip_session_caps' should not be included.  However,
> either some
>
>   dependencies for this module were not found or a
>
>   conflict exists.
>
>
>
>   Either run 'make menuselect' or remove the existing
>
>   menuselect.makeopts file to resolve this issue.
>
> ***
>
>
>
>
>
> ***
>
>   The existing menuselect.makeopts file did not specify
>
>   that 'test_stasis_state' should not be included.  However, either some
>
>   dependencies for this module were not found or a
>
>   conflict exists.
>
>
>
>   Either run 'make menuselect' or remove the existing
>
>   menuselect.makeopts file to resolve this issue.
>
> ***
>
>
>
>
>
> ***
>
>   The existing menuselect.makeopts file did not specify
>
>   that 'test_res_prometheus' should not be included.  However, either some
>
>   dependencies for this module were not found or a
>
>   conflict exists.
>
>
>
>   Either run 'make menuselect' or remove the existing
>
>   menuselect.makeopts file to resolve this issue.
>
> ***
>
>
>
> Dan
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Call and seg fault

[LSV]

What I should do?

пт, 22 янв. 2021 г. в 21:15, Joshua C. Colp :

> On Fri, Jan 22, 2021 at 7:13 AM Killian Matter 
> wrote:
>
>> Well hello, when the call is up, working,  then asterisk put up a seg
>> fault error. Just Segmentation Fault.
>> What info would you want/do you need to help
>> ?
>>
>
> A backtrace is required for crashes[1]. If this is regarding your custom
> code then you'd likely need to actually show the code or provide deeper
> understanding of what is going on. Personally I don't look at unlicensed
> code, but others may choose to.
>
> [1] https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace
>
>
> --
> Joshua C. Colp
> Asterisk Technical Lead
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 16.16.0 Now Available

[LSV]

23-(,’/!

пт, 22 янв. 2021 г. в 3:24, Asterisk Development Team <
asteriskt...@digium.com>:

> The Asterisk Development Team would like to announce the release of
> Asterisk 16.16.0.
> This release is available for immediate download at
> https://downloads.asterisk.org/pub/telephony/asterisk
>
> The release of Asterisk 16.16.0 resolves several issues reported by the
> community and would have not been possible without your participation.
>
> *Thank you!*
>
> The following issues are resolved in this release:
>
> *Security bugs fixed in this release:*
> ---
>
>- [ASTERISK-29219
>] -
>
> res_pjsip_diversion: Crash if Tel URI contains History-Info
> (Reported by Torrey Searle)
>
> *Bugs fixed in this release:*
> ---
>
>- [ASTERISK-29229
>] -
>
> Stasis/messaging: text messages not dispatched to all subscribers when
> using generic subscription
> (Reported by Jean Aunis - Prescom)
>
>- [ASTERISK-29238
>] -
>
> chan_sip: SDP: Offers without any enabled stream are accepted.
> (Reported by Alexander Traud)
>
>- [ASTERISK-29237
>] -
>
> chan_sip: SDP: m=video is parsed even when disabled.
> (Reported by Alexander Traud)
>
>- [ASTERISK-29222
>] -
>
> chan_sip: Hold/Resume an sRTP call on a video enabled user-agent.
> (Reported by Alexander Traud)
>
>- [ASTERISK-29240
>] -
>
> chan_pjsip: Incoming PJSIP calls set global SIPDOMAIN instead of a channel
> variable
> (Reported by Ivan Poddubny)
>
>- [ASTERISK-27902
>] -
>
> chan_pjsip isn't updating hangupcause on 4XX responses
> (Reported by George Joseph)
>
>- [ASTERISK-28016
>] -
>
> PJSIP sends duplicate 183 Progress responses
> (Reported by Alex Hermann)
>
>- [ASTERISK-28185
>] -
>
> chan_pjsip: Subsequent same responses are not stopped
> (Reported by Julien)
>
>- [ASTERISK-29230
>] -
>
> pjsip: Asterisk goes crazy and massively spams logfile if registration
> can't be send
> (Reported by Michael Maier)
>
>- [ASTERISK-29231
>] -
>
> pjsip: SIGSEGV in CLI if no trunk is registered
> (Reported by Michael Maier)
>
>- [ASTERISK-29217
>] -
>
> LOCK() can grant the same lock to multiple channels spuriously
> (Reported by Jaco Kroon)
>
>- [ASTERISK-29201
>] -
>
> Crash occurs when Transfer and execute Hangup before the Transfer result
> (Reported by Dan Cropp)
>
>- [ASTERISK-28947
>] -
>
> Segmentation fault in mixmonitor_ds_destroy
> (Reported by Robert Sutton)
>
>- [ASTERISK-29191
>] -
>
> tel: URI in Diversion header causes crash
> (Reported by Mikhail Ivanov)
>
>- [ASTERISK-28883
>] -
>
> Spyee information ist missing in ChanSpyStop AMI Event
> (Reported by Hendrik Wedhorn)
>
>- [ASTERISK-29188
>] -
>
> null media causing the Asterisk crash
> (Reported by sungtae kim)
>
>- [ASTERISK-29209
>] -
>
> Debug messages printed by scope trace might be missing newlines
> (Reported by Alexander Traud)
>
>- [ASTERISK-29024
>] -
>
> pjsip: Route Header in Cancel request incorrectly set
> (Reported by Flole Systems)
>
>- [ASTERISK-29211
>] -
>
> res_musiconhold: Segfault on realtime music on hold without entries
> (Reported by Nathan Bruning)
>
>- [ASTERISK-29022
>] -
>
> Crash when manipulating PJSIP invite dlg ref counts
> (Reported by Sean Bright)
>
>- [ASTERISK-29173
>] -
>
> Media cache URL requests allow infinite redirects
> (Reported by Sean Bright)
>
>- [ASTERISK-29175
>] -
>
> res_pjsip_stir_shaken: Fix module description
> (Reported by Stanislav Abramenkov)
>
>- [ASTERISK-29148
>] -
>
> 

Re: [asterisk-dev] Asterisk 18.2.0 Now Available

[LSV]

What next?

пт, 22 янв. 2021 г. в 3:25, Asterisk Development Team <
asteriskt...@digium.com>:

> The Asterisk Development Team would like to announce the release of
> Asterisk 18.2.0.
> This release is available for immediate download at
> https://downloads.asterisk.org/pub/telephony/asterisk
>
> The release of Asterisk 18.2.0 resolves several issues reported by the
> community and would have not been possible without your participation.
>
> *Thank you!*
>
> The following issues are resolved in this release:
>
> *Security bugs fixed in this release:*
> ---
>
>- [ASTERISK-29219
>] -
>
> res_pjsip_diversion: Crash if Tel URI contains History-Info
> (Reported by Torrey Searle)
>
> *Bugs fixed in this release:*
> ---
>
>- [ASTERISK-29229
>] -
>
> Stasis/messaging: text messages not dispatched to all subscribers when
> using generic subscription
> (Reported by Jean Aunis - Prescom)
>
>- [ASTERISK-29240
>] -
>
> chan_pjsip: Incoming PJSIP calls set global SIPDOMAIN instead of a channel
> variable
> (Reported by Ivan Poddubny)
>
>- [ASTERISK-29238
>] -
>
> chan_sip: SDP: Offers without any enabled stream are accepted.
> (Reported by Alexander Traud)
>
>- [ASTERISK-29237
>] -
>
> chan_sip: SDP: m=video is parsed even when disabled.
> (Reported by Alexander Traud)
>
>- [ASTERISK-29222
>] -
>
> chan_sip: Hold/Resume an sRTP call on a video enabled user-agent.
> (Reported by Alexander Traud)
>
>- [ASTERISK-27902
>] -
>
> chan_pjsip isn't updating hangupcause on 4XX responses
> (Reported by George Joseph)
>
>- [ASTERISK-28016
>] -
>
> PJSIP sends duplicate 183 Progress responses
> (Reported by Alex Hermann)
>
>- [ASTERISK-28185
>] -
>
> chan_pjsip: Subsequent same responses are not stopped
> (Reported by Julien)
>
>- [ASTERISK-29230
>] -
>
> pjsip: Asterisk goes crazy and massively spams logfile if registration
> can't be send
> (Reported by Michael Maier)
>
>- [ASTERISK-29231
>] -
>
> pjsip: SIGSEGV in CLI if no trunk is registered
> (Reported by Michael Maier)
>
>- [ASTERISK-29217
>] -
>
> LOCK() can grant the same lock to multiple channels spuriously
> (Reported by Jaco Kroon)
>
>- [ASTERISK-29201
>] -
>
> Crash occurs when Transfer and execute Hangup before the Transfer result
> (Reported by Dan Cropp)
>
>- [ASTERISK-28947
>] -
>
> Segmentation fault in mixmonitor_ds_destroy
> (Reported by Robert Sutton)
>
>- [ASTERISK-29168
>] -
>
> Asterisk crashes during call transfer
> (Reported by Dalius Mockevicius)
>
>- [ASTERISK-29210
>] -
>
> res_pjsip: Crash when examining transport
> (Reported by N GM )
>
>- [ASTERISK-29191
>] -
>
> tel: URI in Diversion header causes crash
> (Reported by Mikhail Ivanov)
>
>- [ASTERISK-28883
>] -
>
> Spyee information ist missing in ChanSpyStop AMI Event
> (Reported by Hendrik Wedhorn)
>
>- [ASTERISK-29188
>] -
>
> null media causing the Asterisk crash
> (Reported by sungtae kim)
>
>- [ASTERISK-29024
>] -
>
> pjsip: Route Header in Cancel request incorrectly set
> (Reported by Flole Systems)
>
>- [ASTERISK-29209
>] -
>
> Debug messages printed by scope trace might be missing newlines
> (Reported by Alexander Traud)
>
>- [ASTERISK-29211
>] -
>
> res_musiconhold: Segfault on realtime music on hold without entries
> (Reported by Nathan Bruning)
>
>- [ASTERISK-29022
>] -
>
> Crash when manipulating PJSIP invite dlg ref counts
> (Reported by Sean Bright)
>
>- [ASTERISK-29173
>] -
>
> Media cache URL requests allow 

Re: [asterisk-dev] Asterisk / pjsip: Bug or feature? TCP/TLS connection is endless after unregistering the last trunk to the destination

[LSV]

What you do?

вт, 12 янв. 2021 г. в 0:28, Joshua C. Colp :

> On Mon, Jan 11, 2021 at 10:21 AM Michael Maier 
> wrote:
>
>> Hello!
>>
>> I'm analyzing the transports opened by or for a Registration to an ISPs
>> trunk. Here: transport type flow.
>>
>> I can reproducibly see, that on Asterisk start up are always two
>> connections created to register a trunk. The first one looks like this:
>>
>
> 
>
>
>>
>> It differs in the log output already at the beginning:
>> [2021-01-11 13:21:24] DEBUG[8570] pjproject:tlsc0x7fa1d82efae8
>> TLS client transport created
>> vs
>> [2021-01-11 13:21:24] DEBUG[8570] pjproject:tlsc0x7fa1d8324ec8
>> .TLS client transport created
>>^
>> What does this dot mean? Where is it coming from?
>>
>
> This is a message from the PJSIP library itself forwarded up, not sure why
> there's a period there.
>
>
>>
>> It is possible to tcpkill the first connection without being restarted:
>>
>> # tcpkill -i eth0 tcp port 54761
>> [2021-01-11 14:42:15] DEBUG[8569] pjproject:tlsc0x7fa1d82efae8
>> TLS connection closed
>> [2021-01-11 14:42:15] DEBUG[8569] res_pjsip/pjsip_transport_events.c:
>> Reliable transport 'tlsc0x7fa1d82efae8' state:DISCONNECTED
>> [2021-01-11 14:42:15] DEBUG[8569] pjproject:   sip_transport.c
>> Transport tlsc0x7fa1d82efae8 shutting down, force=0
>> [2021-01-11 14:42:15] DEBUG[8569] res_pjsip/pjsip_transport_events.c:
>> Reliable transport 'tlsc0x7fa1d82efae8' state:SHUTDOWN
>> [2021-01-11 14:42:15] DEBUG[8569] res_pjsip/pjsip_transport_events.c:
>> Reliable transport 'tlsc0x7fa1d82efae8' state:DESTROY
>> [2021-01-11 14:42:15] DEBUG[8569] pjproject:tlsc0x7fa1d82efae8
>> TLS transport destroyed with reason 120104: Connection reset by peer
>>
>> If you're doing the same against Telekom, they drop the first connect
>> after 10 s (therefore no tcpkill is necessary)
>>
>> Any idea why there are 2 connections started though only one is
>> necessary? This is really odd.
>>
>
> Nope. The code itself wasn't explicitly designed or written for this
> usage, so there may be issues with it.
>
> 
>
>
>> It seems, that the first register is done through the first connection -
>> all following registers are done by the second connection (can be seen in
>> the tcpdump trace).
>> Things would be much more analyzable btw, if asterisk pcap trace would
>> contain the local port of the connection, too - or if it would tell, which
>> connection it is using.
>>
>
> Knowing what the source IP address and port that is in use at the point of
> logging is difficult. Noone is actively working on changing that, but
> nothing to say it couldn't change in the future.
>
> --
> Joshua C. Colp
> Asterisk Technical Lead
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [BOUNTY] $2000 USD to patch for this chan_sip crash

[LSV]

You great it.

чт, 10 сент. 2020 г. в 12:15, :

> Hello,
>
>
>
> https://issues.asterisk.org/jira/browse/ASTERISK-29069
>
>
>
> I am offering a USD $2000 bounty to patch for this chan_sip crash.
>
> Details in issue, and I can provide additional full asterisk log (verbose
> 3) if required.
>
>
>
>
>
> Contact me with questions.
>
>
>
>
>
>
>
> Regards,
>
>
>
> *Don Hunter*
>
> VoIP Much Phone Company Inc.
>
>
>
> email:  don.hun...@voipmuch.com
>
> CA/US Toll-Free: +1-855-711-VOIP (8647), ext 8200
>
> UK Toll-Free:+ 44-800-048-8252
>
> Worldwide:   +1-416-613-VOIP (8647)
>
> Our Office:2 Bloor Street West, Suite 700, Toronto, ON,
> M4W 3E2
> 
>
>
>
> CONFIDENTIALITY NOTICE: This email message, including any attachments, is
> for the sole use of the intended recipient (s) and may contain confidential
> and privileged information. Any unauthorized review; use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply email and destroy all copies of the original
> message.
>
>
>
> P  Please consider the environment before printing this e-mail
>
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev