Re: [asterisk-users] Asterisk Release 20.3.1

[Michael Maier]

At the moment, I can't see any differences here. sha512sum is identical.

Regards
Michael

On 08.07.23 at 01:50 Jean-Denis Girard wrote:

Le 07/07/2023 à 12:49, Joshua C. Colp a écrit :
On Fri, Jul 7, 2023 at 6:40 PM Jean-Denis Girard > wrote:


    There seems to be a problem with the tar.gz archive on github. It's
    correct on downloads.asterisk.org .

Can you be more specific? They are identical and the same tarball. I just 
downloaded both from each place and confirmed that, and confirmed they both 
extract fine.


Downloading from github (I tried 5 times), I get:
10353870  7 juil. 13:44 'asterisk-20.3.1(1).tar.gz'
10353870  7 juil. 13:46 'asterisk-20.3.1(2).tar.gz'
sha256sum is:
aec7271fda5eb1e185bb94f3f52977c636783bd456e9c361dd853cd0eba10203
Extracting is fine.

Downloading from asterisk.org, I get:
28176262  7 juil. 11:34  asterisk-20.3.1.tar.gz
5d7dea82b11ce97eec294ba0234c3a68fe2f05065c04a4279baa4a4442f4f628


Bien cordialement,



--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Setting codec on originating (calling) channel with chan_pjsip (SIP_CODEC_INBOUND equivalent)

[Michael Maier]

Hello Michael,

you are referring to the following behavior - did I get it correctly?:

outbound broken: asterisk offers g722 / g711 to provider (callee), 
callee answers g711. Asterisk now transcodes between caller and callee 
(g722 <-> g711).


inbound works: call from provider: g711 -> asterisk drops g722 and 
passes g711 to internal callee -> no transcoding.



As far as I know, there is no working solution as of now. I discussed 
this problem years ago already here but unfortunately nothing usable 
happened so far (which I would know off). The priority is not high 
enough. I need a solution, too. I understand that this behavior is a 
nogo if you have a lot of calls because transcoding is expensive.



Thanks
Michael



On 05.07.23 at 17:58 Michael Ulitskiy wrote:

Hello,

Anyone? I have hard time to believe this is not possible with chan_pjsip.

Anyway, may I ask how people handle the following scenario which I 
imagine should be quite common:


- I have internal extensions talk to each other using g722. so their 
codec setting (with chan_sip now) is "allow=g722,ulaw"

- I have carriers trunks that handle ulaw only (allow=ulaw)
- calls between internal extensions naturally happen over g722 as its 
their preferred codec
- for external calls I now set SIP_CODEC_INBOUND=ulaw to influence codec 
selection on calling channel and the calls set up using ulaw end-to-end


Can somebody please advise how to achieve the same with chan_pjsip?

Thanks,

Michael



--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] TLS and NAT

[Michael Maier]

On 09.04.23 at 19:55 Steve Matzura wrote:

Thanks, Michael. A few questions:


Is [transport_name] a reserved word, or am I supposed to replace it with a name of 
my own, like '[did-transport]'?


Yes. You are free.

Some of the keywords I haven't seen before. Is ca_list_file supposed to be an 
aggregate of the public and private key?


ca_list_file is the list of all CAs the server should accept as valid (these are 
public keys - no private keys) like Let's encrypt e.g..


And what are the 'method,' 'tos' and 
'cos' keywords, which are commented out in your instructions?


Take a look here: 
https://github.com/asterisk/asterisk/blob/master/configs/samples/pjsip.conf.sample


Search for "tos=0"


Regards,
Michael


Otherwise, the rest is quite clear.


On 4/8/2023 12:35 PM, Michael Maier wrote:

Hello Steve,

use the following configuration for the transport and bind this transport to the 
trunk:


[transport_name]
type=transport
protocol=tls
bind=192.168.13.24 ; your bind IP
ca_list_file=/etc/pki/tls/certs/ca-bundle.crt
; method=tlsv1_2
verify_server=yes
allow_reload=no
;tos=0xb8
;cos=3
external_media_address=your.ext.host.name ; hostname pointing to your ext. IP
external_signaling_address=your.ext.host.name ; hostname pointing to your ext. 
IP
local_net=192.168.0.0/24 # your local net


Regards
Michael

On 07.04.23 at 17:25 Steve Matzura wrote:
I want to configure communication with my phone provider using TLS for all the 
obvious reasons. Since I'm behind a firewall, I'll be needing to do it with 
NAT. There are examples of UDP plus NAT in pjsip.conf, but none for TLS plus 
NAT. Would it be correct to set up the TLS transport stanza to look like the 
[transport-udp-nat] stanza example, replacing UDP with TLS in lines like 
'transport=tls' and 'protocol=tls', and including the lines for local_net, 
external_media_address and external_signaling_address?









--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] TLS and NAT

[Michael Maier]

Hello Steve,

use the following configuration for the transport and bind this 
transport to the trunk:


[transport_name]
type=transport
protocol=tls
bind=192.168.13.24 ; your bind IP
ca_list_file=/etc/pki/tls/certs/ca-bundle.crt
; method=tlsv1_2
verify_server=yes
allow_reload=no
;tos=0xb8
;cos=3
external_media_address=your.ext.host.name ; hostname pointing to your 
ext. IP
external_signaling_address=your.ext.host.name ; hostname pointing to 
your ext. IP

local_net=192.168.0.0/24 # your local net


Regards
Michael

On 07.04.23 at 17:25 Steve Matzura wrote:
I want to configure communication with my phone provider using TLS for 
all the obvious reasons. Since I'm behind a firewall, I'll be needing to 
do it with NAT. There are examples of UDP plus NAT in pjsip.conf, but 
none for TLS plus NAT. Would it be correct to set up the TLS transport 
stanza to look like the [transport-udp-nat] stanza example, replacing 
UDP with TLS in lines like 'transport=tls' and 'protocol=tls', and 
including the lines for local_net, external_media_address and 
external_signaling_address?




--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Asterisk / pjsip: RTP - alaw - a=silenceSupp:off

[Michael Maier]

On 30.06.21 at 23:17 Joshua C. Colp wrote:
> On Wed, Jun 30, 2021 at 1:36 PM Michael Maier  wrote:
> 
>>
>> Hello!
>>
>> Short question: Is it possible to set
>>
>> a=silenceSupp:off
>>
>> in the SDP for alaw / ulaw for fax calls?
>>
> 
> No.

Thanks for your kindly support!

Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] Asterisk / pjsip: RTP - alaw - a=silenceSupp:off

[Michael Maier]

Hello!

Short question: Is it possible to set

a=silenceSupp:off

in the SDP for alaw / ulaw for fax calls?


Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Asterisk pjsip and NAT just doesn't work

[Michael Maier]

On 02.05.21 at 17:24 Michael Maier wrote:


On 02.05.21 at 10:08 Michael Maier wrote:


Hello!

I've just playing around some time to get NAT and pjsip running with asterisk 
18.3 and 18.4 (w/o any patches added). NAT should be used for connection to the 
trunk.


I wasn't able to get it working, because SDP address rewriting just doesn't work 
as it should.


The situation is like this (CentOS 7):

- Multihomed
- One small net for the trunk 10.15.13.17/32 as alias on one of the existing 
devices.

- TLS for SIP
- Added complete masquerading for this IP address
- added dnsmanager which provides the global IP address
- used direct media no
- used rewrite contact yes or no
- force rport: yes
- transport:
 external_media_address=external.mydom.org
 external_signaling_address=external.mydom.org
 bind to 10.15.13.17 (may I bind to a interface name?)


What are the problems?

Outbound calls:
- Biggest problem: even if the WAN IP is set everywhere correctly in the 
*initial* INVITE, it's *always* missing in the INVITE *after* the 407 Proxy auth 
request in the SDP. In the first Invite, the SDP was ok, in the second Invite, 
the SDP is broken (rewriting doesn't seem to happen). Such calls naturally are 
dropped by the ISP (ok, one of my providers seems to ignore the entry completely).


This problem disappeared as I tested on a simple system holding just one local IP 
address. Do you have any idea where it could be fixed in the code?


- Another problem is, that the given external IP just isn't used consistently, 
some times it's there - mostly not (always the same easy call setup). I suspect 
/ fear different behavior between reload and restart with same configuration.

>>

- I expect all IP addresses of mine in all sip headers have to be the WAN IP.


- Next finding: The via header in a simple Ack isn't rewritten, too. Seems all 
packages sent by pjsip itself don't know anything about NAT.


This problem persists even on the simple system. Where could it be fixed in the 
code?


- How can I check if NAT is involved at all?

- Maybe asterisk gets confused if it can see the WAN IP (it's on the system, too), 
but is bound to a local IP? But why are some headers written correctly and some 
wrong?


Inbound calls:
- Playing announcements doesn't work at all (no sound though rtp packages are 
flowing in both directions according tcpdump at the WAN interface).

- Calls given to local devices are working.



Could somebody maybe give me a reference configuration for a working NAT 
configuration?



Thanks
Michael



--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Asterisk pjsip and NAT just doesn't work

[Michael Maier]

On 02.05.21 at 10:08 Michael Maier wrote:


Hello!

I've just playing around some time to get NAT and pjsip running with asterisk 18.3 
and 18.4 (w/o any patches added). NAT should be used for connection to the trunk.


I wasn't able to get it working, because SDP address rewriting just doesn't work 
as it should.


The situation is like this (CentOS 7):

- Multihomed
- One small net for the trunk 10.15.13.17/32 as alias on one of the existing 
devices.
- TLS for SIP
- Added complete masquerading for this IP address
- added dnsmanager which provides the global IP address
- used direct media no
- used rewrite contact yes or no
- force rport: yes
- transport:
 external_media_address=external.mydom.org
 external_signaling_address=external.mydom.org
 bind to 10.15.13.17 (may I bind to a interface name?)


What are the problems?

Outbound calls:
- Biggest problem: even if the WAN IP is set everywhere correctly in the *initial* 
INVITE, it's *always* missing in the INVITE *after* the 407 Proxy auth request in 
the SDP. In the first Invite, the SDP was ok, in the second Invite, the SDP is 
broken (rewriting doesn't seem to happen). Such calls naturally are dropped by the 
ISP (ok, one of my providers seems to ignore the entry completely).


- Another problem is, that the given external IP just isn't used consistently, 
some times it's there - mostly not (always the same easy call setup). I suspect / 
fear different behavior between reload and restart with same configuration.


- I expect all IP addresses of mine in all sip headers have to be the WAN IP.


- Next finding: The via header in a simple Ack isn't rewritten, too. Seems all 
packages sent by pjsip itself don't know anything about NAT.


- How can I check if NAT is involved at all?

- Maybe asterisk gets confused if it can see the WAN IP (it's on the system, too), 
but is bound to a local IP? But why are some headers written correctly and some wrong?




Inbound calls:
- Playing announcements doesn't work at all (no sound though rtp packages are 
flowing in both directions according tcpdump at the WAN interface).

- Calls given to local devices are working.



Could somebody maybe give me a reference configuration for a working NAT 
configuration?



Thanks
Michael



--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] Asterisk pjsip and NAT just doesn't work

[Michael Maier]

Hello!

I've just playing around some time to get NAT and pjsip running with asterisk 18.3 
and 18.4 (w/o any patches added). NAT should be used for connection to the trunk.


I wasn't able to get it working, because SDP address rewriting just doesn't work 
as it should.


The situation is like this (CentOS 7):

- Multihomed
- One small net for the trunk 10.15.13.17/32 as alias on one of the existing 
devices.
- TLS for SIP
- Added complete masquerading for this IP address
- added dnsmanager which provides the global IP address
- used direct media no
- used rewrite contact yes or no
- force rport: yes
- transport:
external_media_address=external.mydom.org
external_signaling_address=external.mydom.org
bind to 10.15.13.17 (may I bind to a interface name?)


What are the problems?

Outbound calls:
- Biggest problem: even if the WAN IP is set everywhere correctly in the *initial* 
INVITE, it's *always* missing in the INVITE *after* the 407 Proxy auth request in 
the SDP. In the first Invite, the SDP was ok, in the second Invite, the SDP is 
broken (rewriting doesn't seem to happen). Such calls naturally are dropped by the 
ISP (ok, one of my providers seems to ignore the entry completely).


- Another problem is, that the given external IP just isn't used consistently, 
some times it's there - mostly not (always the same easy call setup). I suspect / 
fear different behavior between reload and restart with same configuration.


- I expect all IP addresses of mine in all sip headers have to be the WAN IP.



Inbound calls:
- Playing announcements doesn't work at all (no sound though rtp packages are 
flowing in both directions according tcpdump at the WAN interface).

- Calls given to local devices are working.



Could somebody maybe give me a reference configuration for a working NAT 
configuration?



Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] pjsip transport and dynamic WAN IP address (not: NAT)

[Michael Maier]

On 01.05.21 at 07:13 Michael Maier wrote:


Hello all!

I'm actually wondering about how to achieve fast fail handling for the pjsip 
transport if underlying WAN IP address changes.


Forgot to mention:

- I'm using TLS!
- pjsip tries every 92s to send the Registration until the timeout comes up. I 
don't know where the 92s are coming from. The tls_keep_alive_interval is 90s - but 
that's not a keep alive package. The "normal" configured retry time if a 
Registration is not answered, is 60s (which is working fine).





Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] pjsip transport and dynamic WAN IP address (not: NAT)

[Michael Maier]

Hello all!

I'm actually wondering about how to achieve fast fail handling for the pjsip 
transport if underlying WAN IP address changes.



Following scenario:
Asterisk runs on a device holding ppp0, which provides the interface for outbound 
registration to ISP trunks (transport acts as client) and therefore the WAN IP.


If WAN IP changes after restarting ppp0 (and ppp0 device completely disappeared 
for some time), it takes pretty long until the transport realizes, that the WAN IP 
changed.


I tried dnsmanager to always provide correct external IP address in SIP requests 
like this


external_media_address : external.mydom.org
external_signaling_address : external.mydom.org
local_net  : 192.168.0.0/255.255.0.0

and I can see, that after IP address change, the SIP requests (Register e.g.) 
provide the correct WAN IP - but transport didn't realize the change on low level.


NOTICE[4061] dnsmgr.c: dnssrv: host 'external.mydom.org' changed from 46.r.x.y:0 
to 79.t.a.b:0


It takes quite some long time (~13 minutes), until pjsip / asterisk detects a 
timeout or a network unreachable.


tlsc0x7ffa800203a8 TLS transport destroyed with reason 120110: Connection timed 
out

After this point has been reached, the transport is destroyed and a new transport 
is generated - from now on, things are working fine again.


I added a global logging rule in iptables at first place in OUTPUT to see any 
packages which are handled - but I couldn't see any - therefore I think things are 
breaking even earlier.



My question: is there any possibility to programmatically force the restart of a 
given transport (I don't want to restart all transports)? This could be easily 
done in ppp up scripts. Or is there a configuration option to reduce the timeout 
until restart of the individual transport? Maybe in pjsip (connection timeout 
detection)?


Another idea would be to restart the relevant transports based on dnsmgr detecting 
new external IP.




Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Change by Deutsche Telekom end of februar. Can someone help me?

[Michael Maier]

On 18.02.21 at 20:01 Luca Bertoncello wrote:

Am 18.02.2021 um 18:59 schrieb Michael Maier:

On 17.02.21 at 21:46 Luca Bertoncello wrote:

Am 16.02.2021 um 22:32 schrieb Michael Maier:

Hi Michael


Maybe could you send me an abstract of your configuration?


Take a look here [1]


So, maybe I got it...
I tested the configuration with my Fax number and it seems to work (= I
can call the fax and can call my mobile phone from the fax with
"originate...").


Congrats!


So, it seems it does NOT work as expected...
I tried to activate the FAX and it works, then I activated my number and
it works, too.
Finally I activated the number of my wife and it does not work anymore...
If I call the number I can only see (verbose 42):

[Feb 18 19:57:12] NOTICE[19379] res_pjsip/pjsip_distributor.c: Request
'INVITE' from ''
failed for '217.0.21.64:5060' (callid: p65550t1613674632m753568c93349s2)
- No matching endpoint found


You have to do all of the configuration mentioned here[1] for *each* number. 
Afterwards, you have to route the incoming call to an internal device. As I'm 
using FreePBX, I don't know how to do it *correctly*.



and no phone rings...
After that, even if I restore the single number to SIP I only get the
error and nothing work, until I restored _ALL_ numbers to SIP.

Do someone has an explanation and (better!) a solution to the problem?


Solution:
You have the choice between: programming your PBX yourself (and have the struggle 
and pain) or let this pretty difficile job do others for you - they provide 
extremely good solutions for a lot of telephony features - it makes no sense to 
reinvent those features without having the required knowledge - so, use FreePBX. 
But it's of course your decision.



[1] 
https://www.ip-phone-forum.de/threads/hilfe-f%C3%BCr-grundeinstellung-asterisk-telekom-ben%C3%B6tigt.307115/post-2374234


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Change by Deutsche Telekom end of februar. Can someone help me?

[Michael Maier]

On 17.02.21 at 21:46 Luca Bertoncello wrote:
> Am 16.02.2021 um 22:32 schrieb Michael Maier:
> 
> Hi Michael
> 
>>> Maybe could you send me an abstract of your configuration?
>>
>> Take a look here [1]
> 
> So, maybe I got it...
> I tested the configuration with my Fax number and it seems to work (= I
> can call the fax and can call my mobile phone from the fax with
> "originate...").

Congrats!

> On the registration I have:
> 
> [pbxfax]
> type = registration
> retry_interval = 20
> max_retries = 10
> contact_user = 00493514977291
> expiration = 120
> transport = transport-udp
> outbound_auth = pbxfax
> client_uri = sip:03514977...@tel.t-online.de
> server_uri = sip:tel.t-online.de
> 
> First: can I use tel.t-online.de or _MUST_ I change it?

No, you mustn't change it. You must use tel.t-online.de.

> If I understand
> your previous E-Mail, I'd say that I can leave tel.t-online.de...

Correctly!

> Then I have a question by the Dialplan... Currently I have:
> 
> [fax-out]
> exten => _X.,1,NoOp()
> exten => _X.,n,Verbose(2,Call from FAX)
> exten => _X.,n,Dial(SIP/pbxfax/${EXTEN},,R)
> 
> And I'll replace it with:
> 
> [fax-out]
> exten => _X.,1,NoOp()
> exten => _X.,n,Verbose(2,Call from FAX)
> exten => _X.,n,Dial(PJSIP/pbxfax/sip:${EXTEN}@tel.t-online.de,,R)
> 
> Is it correct? I tried with
> "PJSIP/pbxfax/pjsip:${EXTEN}@tel.t-online.de,,R" and it does NOT work...
> Is it correct, that I have to leave "sip:..."?

Don't know - I don't care about dialplan - I'm using FreePBX :-)


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Change by Deutsche Telekom end of februar. Can someone help me?

[Michael Maier]

On 16.02.21 at 20:33 Luca Bertoncello wrote:

Am 16.02.2021 um 19:56 schrieb Michael Maier:

Hi Michael,


Do I use pjsip?


pjsip show registrations


gw*CLI> pjsip show registrations
No objects found.

So I don't use pjsip... :(


Yes.


Maybe could you send me an abstract of your configuration?


Take a look here [1]


You mean, I have to create a "fake" Zone tel.t-online.de in my Bind with
these settings? Looks like dangerous, if they changes something...


If you do that statically -> yes, you're right. You have to do it
dynamically. I attached a script, which can be used to dynamically build
a rpz each 15 minutes e.g. It directly asks the telekom nameserver for
naptr and srv entries. It looks like this:

server 192.168.62.13
zone rpz-tonline
update delete tel.t-online.de.rpz-tonline.
update delete _sips._tcp.tel.t-online.de.rpz-tonline.
update delete _sip._tcp.tel.t-online.de.rpz-tonline.
update add tel.t-online.de.rpz-tonline. 60  NAPTR   10 0 "s"
"SIPS+D2T" "" _sips._tcp.tel.t-online.de.
update add tel.t-online.de.rpz-tonline. 60  NAPTR   30 0 "s"
"SIP+D2T" "" _sip._tcp.tel.t-online.de.
update add _sips._tcp.tel.t-online.de.rpz-tonline.  60 SRV  10 0
5061 s-eps-110.edns.t-ipnet.de.
update add _sip._tcp.tel.t-online.de.rpz-tonline.   60 SRV  10 0
5060 s-epp-110.edns.t-ipnet.de.
send


So if I undestand what you mean, you check the NAPTR and SRV für
_sips._tcp.tel.t-online.de and save the record in a "virtual domain"
rpz-tonline, is it correct?
Then I suppose you use this domain instead of tel.t-online.de in the SIP
configuratione as "host", "outboundproxy" and "fromdomain", is it correct?


No - you have to use the correct domain name in asterisk.  Only bind knows about 
the fake domain. You have to configure bind correctly.


You have to create the fake domain in the bind config like this:
options {
...
response-policy {
zone "rpz-tonline";
};
};

...

zone "rpz-tonline" {
type master;
file "/var/named/rpz-tonline-override";
allow-query { any; };
allow-transfer { any; };
allow-update { any; };
};

All other things: take a look at the script! It's not that complicated.




The script unregisters and registers the telekom trunks, if a change is
detected. This is done as long as there is no call active. This works
for me - but may not wort for others - feel free to change the code.


OK, I'll check it...


Independently you have to add your own trunk names to get it working
(telekomPJSIP-a, ...).


Could you explain me that? I'm not an expert of Asterisk... :(


Well, if you want to use it, you really should engage yourself a bit more to get 
it solved. It's not that easy. Or you may forget about the DNS fake and live with 
the problem, that asterisk could partly switch sometimes to another server - 
breaking the telephony. I don't think it would happen that often, because Telekom 
usually is extremely stable. Try at first to get a running pjsip configuration. 
The DNS theme could be done later on.



Regards
Michael

[1] 
https://www.ip-phone-forum.de/threads/hilfe-f%C3%BCr-grundeinstellung-asterisk-telekom-ben%C3%B6tigt.307115/post-2374234


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Change by Deutsche Telekom end of februar. Can someone help me?

[Michael Maier]

Hi Luca,

On 15.02.21 at 21:48 Luca Bertoncello wrote:
> Am 15.02.2021 um 21:40 schrieb Michael Maier:
> 
> Hi Michael,
> 
>> They're switching to DNS NAPTR / SRV[1]. If you are using Asterisk /
>> pjsip and hostnames (tel.t-online.de e.g. for the AllIP service), you
> 
> Mmm... I'm using tel.t-online.de, but I'm not sure I'm using pjsip...
> 
> module show say me:
> 
> res_pjsip.so   Basic SIP resource
> 46 Running  core
> 
> Do I use pjsip?

pjsip show registrations

> You mean, I have to create a "fake" Zone tel.t-online.de in my Bind with
> these settings? Looks like dangerous, if they changes something...

If you do that statically -> yes, you're right. You have to do it
dynamically. I attached a script, which can be used to dynamically build
a rpz each 15 minutes e.g. It directly asks the telekom nameserver for
naptr and srv entries. It looks like this:

server 192.168.62.13
zone rpz-tonline
update delete tel.t-online.de.rpz-tonline.
update delete _sips._tcp.tel.t-online.de.rpz-tonline.
update delete _sip._tcp.tel.t-online.de.rpz-tonline.
update add tel.t-online.de.rpz-tonline. 60  NAPTR   10 0 "s"
"SIPS+D2T" "" _sips._tcp.tel.t-online.de.
update add tel.t-online.de.rpz-tonline. 60  NAPTR   30 0 "s"
"SIP+D2T" "" _sip._tcp.tel.t-online.de.
update add _sips._tcp.tel.t-online.de.rpz-tonline.  60 SRV  10 0
5061 s-eps-110.edns.t-ipnet.de.
update add _sip._tcp.tel.t-online.de.rpz-tonline.   60 SRV  10 0
5060 s-epp-110.edns.t-ipnet.de.
send

You have to configure bind to use the rpz for all lookup calls resolving
*.tel.t-online.de. I assume that the individual t-ipnet.de entries are
"statically" and therefore resolved directly (w/o rpz). But this could
be added to the script, too (would be a new rpz).

At the moment, I'm using only one DNS server for digging the NAPTR and
SRV entries - this could be enhanced to use 2 servers if the first
fails. If the first fails, the script currently stops and does nothing.
I assume, that the DNS server is stable.

The script unregisters and registers the telekom trunks, if a change is
detected. This is done as long as there is no call active. This works
for me - but may not wort for others - feel free to change the code.
Independently you have to add your own trunk names to get it working
(telekomPJSIP-a, ...).

You can verify if it's working by checking for entries like this in
journalctl:
Feb 16 19:35:46 myfw named[1516]: client @0x7ff574027bd0
192.168.62.13#25869 (tel.t-online.de): rpz QNAME NODATA rewrite
tel.t-online.de via tel.t-online.de.rpz-tonline
They are appearing at the moment asterisk starts a lookup.


Hope this helps!


Thanks
Michael


check-t-online.pl
Description: Perl program
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Change by Deutsche Telekom end of februar. Can someone help me?

[Michael Maier]

Hi!

On 15.02.21 at 08:43 Luca Bertoncello wrote:
> Hi list!
> 
> I received a letter from Deutsche Telekom where they say me, that I need
> to change "something" on my router until 28.02.2021, otherwise I cannot
> phone anymore.
> Since I use Asterisk and I don't have a router, I'm not sure what I need
> to do...
> In the letter there is an URL to "explain" how to change the
> configuration if I use a VoIP-phone, but they only say, that I don't
> have to use Port 5060, but Port 0...
> 
> Surely there are in this list someone other using Deutsche Telekom...
> Does someone of them understand what I should change in the Asterisk
> configuration?

They're switching to DNS NAPTR / SRV[1]. If you are using Asterisk /
pjsip and hostnames (tel.t-online.de e.g. for the AllIP service), you
won't have any problem (using asterisk 14 or higher), because it's
default. But you may have problems with the handling of the calls,
because Telekom needs the client always to use the same server for all
activities after the register has been done (the SRV entries contain 3
servers and asterisk will use them "randomly" if it detects a problem -
regardless which server of the list has been used for registration -
this won't work with Telekom and will lead to not working outbound calls
/ interrupted calls e.g.). This won't happen very often (because they
have been extremely stable in the past), but I could see it nevertheless
already. If you want to be really sure to not face this problem, you
have to create a workaround by adding a rpz zone e.g. with an own bind,
which is fed by an own job and presents asterisk just one server when
looking up the SRV entries after the NAPTR call. NAPTR / SRV works like
this (example for tel.t-online.de):

1. Search for the service names
dig noall +answer tel.t-online.de NAPTR
tel.t-online.de.5   IN  NAPTR   10 0 "s" "SIPS+D2T" ""
_sips._tcp.tel.t-online.de.
tel.t-online.de.5   IN  NAPTR   30 0 "s" "SIP+D2T" ""
_sip._tcp.tel.t-online.de.

2. Take the answer of the NAPTR output (TCP/TLS, TCP)
dig +noall +answer _sips._tcp.tel.t-online.de SRV
_sips._tcp.tel.t-online.de. 2234 IN SRV 10 0 5061
s-eps-110.edns.t-ipnet.de.
_sips._tcp.tel.t-online.de. 2234 IN SRV 20 0 5061
h2-eps-100.edns.t-ipnet.de.
_sips._tcp.tel.t-online.de. 2234 IN SRV 30 0 5061
d-eps-100.edns.t-ipnet.de.

dig +noall +answer _sip._tcp.tel.t-online.de SRV
_sip._tcp.tel.t-online.de. 3600 IN  SRV 30 0 5060
d-epp-100.edns.t-ipnet.de.
_sip._tcp.tel.t-online.de. 3600 IN  SRV 10 0 5060
s-epp-110.edns.t-ipnet.de.
_sip._tcp.tel.t-online.de. 3600 IN  SRV 20 0 5060
h2-epp-100.edns.t-ipnet.de.

Asterisk now must use always the same server for all activities to
Telekom - like register, invite, options - but that's not yet supported
by Asterisk - therefore you have to ensure, that asterisk always uses
the same server. Easiest way is to provide just one in the DNS answer ... .


Regards
Michael

[1]
https://geschaeftskunden.telekom.de/hilfe-und-service/online-services/hilfe-internetanschluss/telefonieanpassung#telekom

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Asterisk 16.14.0 pjsip transport-tls cert parsing error

[Michael Maier]

On 29.01.21 at 22:33 Ruisheng Peng wrote:

Thanks for the detailed explanation Michael.

I stop the current asterisk process (started by systemd), and restart it as
asterisk:

[asterisk@voip1 ~]$ strace -f -o /home/asterisk/strace.log asterisk -fmq
-vvv -C /etc/asterisk/asterisk.conf


from the log there was no attempt to even open the cert file.  I edited
/etc/asterisk/pjsip.conf to add a "method = tlsv1" line to the
transport-tls section. Rerun the strace command, and here the part re cert
files:

8189  stat("/home/asterisk/certs/asterisk.crt", {st_mode=S_IFREG|0640,
st_size=1

212, ...}) = 0

8189  geteuid() = 1002

8189  getegid() = 1002

8189  getuid()  = 1002

8189  getgid()  = 1002

8189  access("/home/asterisk/certs/asterisk.crt", R_OK) = 0

8189  stat("/home/asterisk/certs/asterisk.key", {st_mode=S_IFREG|0640,
st_size=8

91, ...}) = 0

8189  geteuid() = 1002

8189  getegid() = 1002

8189  getuid()  = 1002

8189  getgid()  = 1002

8189  access("/home/asterisk/certs/asterisk.key", R_OK) = 0

8189  socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 16

8189  setsockopt(16, SOL_SOCKET, 0x /* SO_??? */, [1], 4) = -1
ENOPROTOOPT (


I'm missing the "open" (or "openat") and the following "read" call - weren't there 
any or didn't you post them? These are the important calls! They will show, if the 
file is used at all or not (and possibly the reason, why it is not used - EACCESS 
e.g.).



Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Asterisk 16.14.0 pjsip transport-tls cert parsing error

[Michael Maier]

On 29.01.21 at 06:41 Michael Maier wrote:


On 27.01.21 at 22:57 Ruisheng Peng wrote:

Thanks Michael for the suggestion!  I've installed strace and assigned one
of the endpoints (SOFTPHONE_B) to use transport-tls. Then run strace (as
user asterisk):

[asterisk@voip1 ~]$ strace asterisk -rx "module reload res_pjsip.so"


You should use strace like this as root and from the very beginning of the start 
of asterisk:


Sorry - my wrong - not necessarily as root - it should be started the same way and 
in the same context as it runs normally.




strace -f -o /tmp/strace.log asterisk -vvv -mqf -C /etc/asterisk/asterisk.conf

-f means, to follow even forked processes, ... (see man page)
-o writes all the output to a file. You can search afterwards pretty easily for 
the file (or the open call).


You shouldn't do this in production but in the test environment!

You have to run it as long as the error has happened.


Thanks
Michael




--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Asterisk 16.14.0 pjsip transport-tls cert parsing error

[Michael Maier]

On 27.01.21 at 22:57 Ruisheng Peng wrote:

Thanks Michael for the suggestion!  I've installed strace and assigned one
of the endpoints (SOFTPHONE_B) to use transport-tls. Then run strace (as
user asterisk):

[asterisk@voip1 ~]$ strace asterisk -rx "module reload res_pjsip.so"


You should use strace like this as root and from the very beginning of the start 
of asterisk:


strace -f -o /tmp/strace.log asterisk -vvv -mqf -C /etc/asterisk/asterisk.conf

-f means, to follow even forked processes, ... (see man page)
-o writes all the output to a file. You can search afterwards pretty easily for 
the file (or the open call).


You shouldn't do this in production but in the test environment!

You have to run it as long as the error has happened.


Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Asterisk 16.14.0 pjsip transport-tls cert parsing error

[Michael Maier]

On 26.01.21 at 21:12 Ruisheng Peng wrote:
> Hi,
> 
>   I'm experimenting with Asterisk-16.14.0 on a CentOS7 box, and run into
> problems loading the SSL certificate to establish transport-tls.  Tried
> self-signed certificate generated with ast_tls_cert under contrib/scripts
> and the one issued by Letsencrypt, both would bomb out with a parsing error:
> 
> [Dec  3 15:47:50] ERROR[11233] res_pjsip/config_transport.c: Transport:
> transport-tls: cert_file /home/asterisk/certs/asterisk.crt is either
> missing or not readable

It's missing or not readable! Take care, that the file access rights of
the file and the complete path are ok. Do a strace to verify, if the
file is really loaded at all.


Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Asterisk 18.0.0 Now Available

[Michael Maier]

On 21.10.20 at 12:49 Joshua C. Colp wrote:
> On Wed, Oct 21, 2020 at 7:46 AM Michael Maier  wrote:
> 
>> Hello!
>>
>> On 20.10.20 at 14:00 Asterisk Development Team wrote:
>>> The Asterisk Development Team would like to announce the release of
>> Asterisk 18.0.0.
>>> This release is available for immediate download at
>>> https://downloads.asterisk.org/pub/telephony/asterisk
>>
>> I just tested the new codec negotiation feature and unfortunately wasn't
>> able to get it working as expected. I tried several configurations - but
>> none has been working - the result
>> has always been the same.
>>
> 
> This is expected right now. Foundational aspects were put in, but there is
> still work to be done for PJSIP which will land in a future release.

Oh - thanks for the information - I missed this :-(. How do I know if this 
feature is finally enabled? Will it be in asterisk 18 - or will it come in some 
later major version?

> The
> complexity of it and the investigation of how things work, interactions,
> etc took considerably longer than expected. If there's specific scenarios
> that you'd like to ensure are met you can reach out on the asterisk-dev
> mailing list and George Joseph will add them to the list if not already
> present.

Well, I think the scenario I have should be a very easy and basic scenario. I 
already discussed it in the past. Therefore I think it's not necessary to add 
it again.


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Asterisk 18.0.0 Now Available

[Michael Maier]

Hello!

On 20.10.20 at 14:00 Asterisk Development Team wrote:
> The Asterisk Development Team would like to announce the release of Asterisk 
> 18.0.0.
> This release is available for immediate download at
> https://downloads.asterisk.org/pub/telephony/asterisk

I just tested the new codec negotiation feature and unfortunately wasn't able 
to get it working as expected. I tried several configurations - but none has 
been working - the result
has always been the same.

Use case:
Alice calls Bob - sends INVITE  G722 / alaw / ulaw

Configured in Asterisk for this device: G722 / alaw / ulaw / gsm
A:
codec_prefs_incoming_offer = prefer: configured, operation: intersect, keep: 
all, transcode: prevent


Bob:
Configured in Asterisk for this device: alaw / ulaw
B:
codec_prefs_outgoing_offer = prefer: configured or pending, operation: 
intersect, keep: first or all, transcode: prevent
Asterisk sends INVITE to Bobalaw / ulaw


Asterisk receives OK from Bob   alaw
B:
codec_prefs_incoming_answer = prefer: configured or pending, operation: 
intersect, keep: first or all, transcode: prevent

Asterisk sends OK to Alice  G722 / alaw / ulaw
A:
codec_prefs_outgoing_answer = prefer: pending, operation: intersect, keep: 
first or all, transcode: prevent

=> I would have expected alaw to be sent to A - but G722 / alaw / ulaw is sent 
and transcoding is active!


What did I do wrong?
Could you please add the correct configuration you expect to get the expected 
result alaw?



Thanks
Kind regards
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] linphone calls not missed due to cause not 487

[Michael Maier]

On 16.10.20 at 11:07 sergio wrote:
> On 16/10/2020 10:11, Michael Maier wrote:
>>> Sometimes, linphone shows missed calls as missed.
>> You could try to reproduce it
> 
> I can't reproduce it, it happens less than once a month.

Then you should enable the tracing as I wrote in the previous post.

Regards
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] linphone calls not missed due to cause not 487

[Michael Maier]

Hi Sergio



On 16.10.20 at 07:54 sergio wrote:

> Sometimes, linphone shows missed calls as missed. Look like asterisk

> replies with cause=487 that time, but I can't understand why.

>

> Grandstream always shows calls as missed ones.

>

> How should I investigate this?

You could try to reproduce it while activating pcap traces and analyze
it afterwards - or you could enable pcap traces on asterisk[1] itself
and just wait for the different issues and compare them.





Regards

Michael



[1] activating pcap traces on asterisk / pjsip

pjsip set logger on

pjsip set logger verbose off

pjsip set logger pcap trace.pcap

You can find the trace.pcap in /var/lib/asterisk/trace.pcap (maybe it's
elsewhere on your installation)

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] func_pjsip_aor.so: undefined symbol: ast_sip_location_retrieve_aor_contacts

[Michael Maier]

On 05.09.20 at 15:22 sean darcy wrote:
> asterisk-16.13.0-rc2. Fedora 32
> 
> pjsip won't load because of undefined symbols:

This means, that your pjsip library doesn't match the asterisk binary. It's 
best to remove the independent pjsip library and compile asterisk[1] with the 
bundled pjsip library. Doing
it this way ensures that pjsip and asterisk match for sure (and some additional 
patches are applied to pjsip on top regarding usage of pjsip in asterisk).


Greetings
Michael

[1] https://downloads.asterisk.org/pub/telephony/asterisk

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Stir Shaken is upon us

[Michael Maier]

On 13.07.20 at 10:54 Joshua C. Colp wrote:
> On Sun, Jul 12, 2020 at 11:37 PM Michael Maier  wrote:
>> One more question,
>> what about the pjsip pcap support? Will it be backported to Asterisk 16,
>> too? Would be absolutely cool! Debugging encrypted SIP is really a pain.
>>
> 
> It can't be backported ... because it already is. :D This support is
> actually in the latest releases of 13, 16, and 17.

This is perfectly good news! How often would I have it already needed in the 
past! Thanks!

Just to be sure:

pjsip set logger pcap  (written to /var/lib/asterisk/)
pjsip set logger on (switches on logging to file and console)
pjsip set logger off (switches off logging to file and console)

Is it possible to log only to the file and not to the console?

>>
>> BTW: what about the (encrypted) RTP packets? Will they be dumped, too?
>>
> 
> Not yet supported but certainly something we'd like to see as well as the
> RTCP, ICE, STUN, TURN, and DTLS packets.

Would be absolutely necessary to debug broken encrypted packets.


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Stir Shaken is upon us

[Michael Maier]

On 13.07.20 at 00:17 Joshua C. Colp wrote:
> On Sun, Jul 12, 2020 at 7:12 PM Dan Jenkins  wrote:
> 
>> Asterisk 18 will have support based on this asterisk update Matt F did for
>> CommCon's sponsor slots
>>
>> https://youtu.be/eas1csaX-wc
>>
>>
> As well support will go into Asterisk 16 and 17 as well. It's just been
> under active development so we've been waiting for that to finish before
> bringing it back into those versions.

One more question,
what about the pjsip pcap support? Will it be backported to Asterisk 16, too? 
Would be absolutely cool! Debugging encrypted SIP is really a pain.

BTW: what about the (encrypted) RTP packets? Will they be dumped, too?


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Voice broken during calls (again...)

[Michael Maier]

On 03.07.20 at 19:57 Luca Bertoncello wrote:
[...]
>> On the Gateway (Banana PI), where the Asterisk server also runs, the
>> load is about 0.50 during calls and it has a Gbps LAN.
>> I can't believe, the problem is here...
> 
> So, now I know what was the problem and I solved it...
> 
> The problem was: the Banana PI... :(

Glad you could find and solve the problem.

> I checked it with mtr and I see really bad times to communicate with
> other devices im same networks (~2 - 380 ms!!).
> Many tries with other Switch ports and so on didn't solved the problem.

Yeah, that's what I already thought for myself. VoIP is (based on its realtime 
nature) extremely picky about network interfaces (or even complete hardware of 
the system) and their
drivers and the corresponding configuration. But most of the people can't / 
won't believe it.

Many of them (NICs) are pretty broken (sometimes the nic hardware, sometimes 
both hard- and software). Even APU 1 or 2 devices don't work reliably for VoIP 
with the standard in
kernel drivers or with default configuration here. I always had / have to use 
other drivers / kernels / configurations to get a proper and reliable rtp 
stream - even over hours.


Regards
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Voice broken during calls (again...)

[Michael Maier]

Am 24.06.20 um 08:10 schrieb Luca Bertoncello:

Am 24.06.2020 05:05, schrieb Michael Maier:

Hi


Your basic architecture looks good to me - now you have to start the


Nice to hear it...


analysis of the problem with pcapsipdump and wireshark as I wrote
before to get an idea what actually happens at
all. You most probably won't come any further without doing any
analyzing. You have to learn it. It will take some, or even more,
time. You can't do it in just few hours or maybe
even days or weeks. It is work or even hard work to learn and to do it.


Well, that's the very problem...
I don't know *how* to analyze it... Or, better, how to read the data...
I know, I can use tcpdump, sngrep and many other tools, but I don't know what I have to expect and how to decide, that a 
paket is wrong...

Can someone help me to learn it?

Google is your friend as usual. Try *for example* those search patterns as 
*entry point*:
wireshark rtp stream analysis
wireshark voip mitschneiden

https://support.yeastar.com/hc/en-us/articles/360007606533-How-to-Analyze-SIP-Calls-in-Wireshark
https://www.innosoft.at/news/169/voip-grundlagen-wireshark-analyse-von-sip-telefonie
https://sharkfestus.wireshark.org/sharkfest.12/presentations/BI-7_VoIP_Analysis_Fundamentals.pdf


Regards
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Voice broken during calls (again...)

[Michael Maier]

On 23.06.20 at 21:10 Luca Bertoncello wrote:
> Am 23.06.2020 um 21:08 schrieb Michael Maier:
>> On 23.06.20 at 08:05 Luca Bertoncello wrote:
>>> Am 23.06.2020 07:27, schrieb Luca Bertoncello:
>>>
>>> I again
>>>
>>>>> Do not change MTU. Probably there will be another problem. I expect
>>>>> packet size 1466 would pass and higher will have the same result. It
>>
>> RTP-VoIP-packets never reach this size. Size is about 214 bytes.
> 
> OK, so it must be something other...
> 
> But I really don't have any idea what... :(

Your basic architecture looks good to me - now you have to start the analysis 
of the problem with pcapsipdump and wireshark as I wrote before to get an idea 
what actually happens at
all. You most probably won't come any further without doing any analyzing. You 
have to learn it. It will take some, or even more, time. You can't do it in 
just few hours or maybe
even days or weeks. It is work or even hard work to learn and to do it.

That's my problem: It's impossible for me to assist because I can't see any 
effort on your side to learn. I won't fix your problem. You have to fix it 
yourself. All I can do, is, to
show you a way to *find* your problem (I can't know your problem) and may be to 
give some hints how to fix it (once you've found it). Finding / localizing 
problems and fixing them
are two completely different things. But before you fix a problem, you have to 
know the problem. Therefore: go and find your problem by starting the analysis. 
That's the first thing
to do.


Regards
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Voice broken during calls (again...)

[Michael Maier]

On 23.06.20 at 08:05 Luca Bertoncello wrote:
> Am 23.06.2020 07:27, schrieb Luca Bertoncello:
> 
> I again
> 
>>> Do not change MTU. Probably there will be another problem. I expect
>>> packet size 1466 would pass and higher will have the same result. It

RTP-VoIP-packets never reach this size. Size is about 214 bytes.


Regards
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Voice broken during calls (again...)

[Michael Maier]

Am 22.06.20 um 16:48 schrieb Luca Bertoncello:

Hi list!

So, now I have a business contract and a technician was here to check
the DSL...
Nothing found, except that for 50Mbps I need now vectoring. Really
nice... A couple of years ago I could get 50Mbps without vectoring.
Of course, Deutsche Telekom said nothing about this change...

Well, I got it working, and now I have 48Mbps down and 10Mbps up.
I _REALLY CAN'T_ believe, that this is not enough...


This is enough if you're doing it correctly. But that's your job to do it 
correctly - not Telekom's one.


The problem with many little disruptions during calls is always here.


Not surprising. That's most probably not a problem of the provider. VoIP of Deutsche Telekom mostly is pretty perfect 
regarding voice quality and availability.



I tried changing the codecs and changing some settings in the SIP
configuration of the peers.
No changes...


Not surprising.

Did you check to prevent transcoding?


On the Gateway (Banana PI), where the Asterisk server also runs, the
load is about 0.50 during calls and it has a Gbps LAN.


What's running on this device on parallel? What about other network traffic - 
not necessarily to the internet interface?


I can't believe, the problem is here...


That's irrelevant. You have to ensure, that the driver doesn't have any problems. Reducing the queue sizes of the 
interface may help.



@all german users using Telekom: how did you configured your Asterisk?


- At first, you have to trace down the problem and analyze those traces when the problem occurred. This could be done 
with pcapsipdump[1] on both sides (internal and external).

Example:

pcapsipdump -i ppp0 -p -d /tmp/pcapsipdump &

will trace the connection to Telekom. You have to add another process to 
another device to trace the internal call.
Use Wireshark to analyze the dumps. Wireshark understands VoIP. (I assume you are using SIP / RTP on all legs.) Now you 
can see on which side the problem happens and how it looks like.

- Are you using NAT or is asterisk running on the device which runs the 
ppp-interface?
- What's the modem you are using? What about the wiring between APL and modem? 
Is it done correctly? [2]
- Did you configure prioritization for the up-stream regarding RTP and SIP? 
This is done with the tc tool.
- Did you correctly configure tos? For Deutsche Telekom you may use tos=0xb8 (pjsip). You have to verify it with 
Wireshark with your traces. You have to set it to the same value as the packages which are received from their server.
- You have to use the DNS of Deutsche Telekom which they provide during the ppp-login because they usually provide 
optimal sip servers for you (regarding distance). You're RTT of ping (18 ms) is pretty bad. I'm having here 5 ms to the 
primary server (Telekom provides 3). See


dig +noall +answer _sip._udp.tel.t-online.de SRV

e.g. (don't know the hostname for the business infrastructure)


Regards,
Michael


[1] https://sourceforge.net/projects/pcapsipdump/
[2] 
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Das-richtige-Kabel-zwischen-APL-und-TAE-Dose/ta-p/3499089

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] CLI color prompt

[Michael Maier]

On 31.05.20 at 19:26 Jeff LaCoursiere wrote:
> Hi,
> 
> I had posted this a few hours ago, but got caught in moderation for size.  I 
> trimmed down the pic and attached.
> 
> I am on an Ubuntu 16 workstation, in an Ubuntu terminal window, ssh'ed to the 
> PBX (amazon instance).  You can see my term type matches yours.

Same problem here (asterisk 16.x / CentOS 7).
# echo $TERM
xterm-256color

=> CLI prompt looks the same as described by the OP:
[1;31m[myhostname]:

But to make it even more strange: colored output on the asterisk CLI works 
pretty fine for DEBUG output like
core set debug 5

Maybe some link time functionality not enabled? Don't know ... . Or some other 
additional asterisk switch needed?


Thanks
Regards
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Meaning of RTT in channelstats

[Michael Maier]

On 17.05.20 at 01:28 Joshua C. Colp wrote:
> On Sat, May 16, 2020 at 10:58 AM Michael Maier  wrote:
> 
>> => How are the RTT values exactly calculated? Which values are actually
>> used for?
>>
> 
> The value is calculated according to the logic in the RFC[1]. Specifically
> using embedded timestamps in the RTCP packets and calculated delays. The
> value is presented in seconds I believe in the output.

Thanks Joshua!

>> => What about the processing time between the inbound leg and the outbound
>> leg (transcoding, ...)?
>>
> 
> That has no impact within this, since it's calculated using the RTCP
> traffic which is not used for media. It's really just for round trip time
> of a UDP packet, not for end to end time of a single audio packet/frame
> through the system.

Let's try to sum it up on base of the given easy example how to get the 
complete delay between those two speakers:

A calls B:
 ...Receive. 
.Transmit..

 BridgeId ChannelId  UpTime.. Codec.   CountLost Pct  Jitter   
CountLost Pct  Jitter   RTT
 
===

 c8137221 327-0004   03:22:42 g722  608K  00   0.000
608K  00   0.000   0.000
 c8137221 providePJSIP-xxx-0 03:22:42 alaw  608K  00   0.000
608K  00   0.000   0.023

A says something.

1. quantization:20 ms
2. processing time on the phone base / DECT:?
3. way from phone base to asterisk: 0 ms
4. processing time on asterisk / transcoding:   ?
5. transport to destination:11.5 ms
6. processing time on destination side: ?

Therefore it would take about 35 ms until B can here A. Is this basically a 
correct estimation or did I miss(understand) something?


Thanks
Michael


> [1] https://tools.ietf.org/html/rfc3550

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Meaning of RTT in channelstats

[Michael Maier]

On 15.05.20 at 14:31 Doug Lytle wrote:
> Google says Round Trip Time
> 
> https://www.voip-info.org/asterisk-rtcp/

That doesn't answer my question (I know the abbreviation RTT). Therefore I'm 
trying again:

I'm just wondering what the RTT *exactly* means. Where are the exact measuring 
points located?

=> How are the RTT values exactly calculated? Which values are actually used 
for?

=> What about the processing time between the inbound leg and the outbound leg 
(transcoding, ...)?


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] Meaning of RTT in channelstats

[Michael Maier]

Hello!

I'm just wondering what the RTT exactly means. Where are the exact measuring 
points located?

> pjsip show channelstats

 ...Receive. 
.Transmit..
 BridgeId ChannelId  UpTime.. Codec.   CountLost Pct  Jitter   
CountLost Pct  Jitter   RTT
 
===

 c8137221 327-0004   03:22:42 g722  608K  00   0.000
608K  00   0.000   0.000
 c8137221 providePJSIP-xxx-0 03:22:42 alaw  608K  00   0.000
608K  00   0.000   0.023


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] Own MOH incorrectly kicking in instead of the MOH of the callee

[Michael Maier]

Hello all!

I'm reproducibly getting my *own MOH* if I should get the MOH of the Callee 
instead. I can see this with asterisk 13 and 16 (and probably before, too). The 
reason of the
wrong MOH is an in dialog reInvite received from trunk, which sends a SDP 
containing

a=sendonly

After this reInvite, I can hear own MOH instead of the MOH of the Caller. The 
situation is cleared by another reInvite received from the trunk containing

a=sendrecv


Is this expected behavior? I don't think it should act like this.

BTW: I'm additionally using FreePBX. Maybe it's a problem of FreePBX?


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] FREEPBX Mailinglist

[Michael Maier]

On 11.09.19 at 15:24 Joshua C. Colp wrote:
> On Wed, Sep 11, 2019, at 10:18 AM, basti wrote:
>> Hallo,
>> is there a Freepbx mailinglist? or can this be posted here?
> 
> FreePBX does not have a mailing list. People use the community forum[1] 
> instead.
> 
> [1] https://community.freepbx.org/

This forum of freepbx is quite a PITA (and therefore quite unusable), at least 
from (some (don't know if all) providers of) Germany. It takes 1 minute or more 
to load
(each! site). The IP 199.102.239.92 produces packet loss on a huge scale. Even 
reducing the mss size to 900(!) doesn't have any effect. I can see this since 
years or
better: I never saw it w/o package loss.

# ping 199.102.239.92
PING 199.102.239.92 (199.102.239.92) 56(84) bytes of data.
64 bytes from 199.102.239.92: icmp_seq=1 ttl=56 time=124 ms
64 bytes from 199.102.239.92: icmp_seq=2 ttl=56 time=124 ms


# traceroute -T 199.102.239.92
traceroute to 199.102.239.92 (199.102.239.92), 30 hops max, 52 byte packets
 1  * * *
 2  x.x.x.x (62.155.245.70)  7.841 ms  7.874 ms  7.868 ms
 3  y.y.y.y (217.5.116.234)  10.882 ms  10.916 ms  10.912 ms
 4  z.z.z.z (217.5.116.234)  10.908 ms  10.904 ms  10.909 ms
 5  62.157.249.186 (62.157.249.186)  22.582 ms  22.609 ms  23.037 ms
 6  ae-1.r25.frnkge08.de.bb.gin.ntt.net (129.250.4.16)  25.279 ms  24.443 ms  
24.543 ms
 7  ae-8.r22.asbnva02.us.bb.gin.ntt.net (129.250.4.96)  103.701 ms  104.829 ms  
117.578 ms
 8  ae-0.r23.asbnva02.us.bb.gin.ntt.net (129.250.3.85)  102.750 ms  102.776 ms  
115.097 ms
 9  ae-3.r21.chcgil09.us.bb.gin.ntt.net (129.250.2.139)  122.340 ms  121.706 ms 
 119.258 ms
10  ae-16.r08.chcgil09.us.bb.gin.ntt.net (129.250.2.204)  122.853 ms 
ae-2.r07.chcgil09.us.bb.gin.ntt.net (129.250.4.214)  114.721 ms  117.954 ms
11  ae-1.a01.chcgil09.us.bb.gin.ntt.net (129.250.5.94)  119.707 ms 
ae-0.a01.chcgil09.us.bb.gin.ntt.net (129.250.4.218)  122.066 ms  120.186 ms
12  129.250.199.66 (129.250.199.66)  121.861 ms  125.719 ms  122.840 ms
13  static.66.185.29.254.cyberlynk.net (66.185.29.254)  125.742 ms  126.253 ms  
124.522 ms
14  * wi-mke1-dc2-c5-47-haf-7578.cyberlynk.net (66.185.29.26)  118.165 ms *
15  199.102.239.92 (199.102.239.92)  122.352 ms  126.759 ms  123.944 ms
16  199.102.239.92 (199.102.239.92)  123.890 ms  124.069 ms  126.670 ms


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] asterisk 16.5 / pjsip outage because of task processor queue >= 500 tasks and too many open files later on

[Michael Maier]

Hello!

I encountered an outage of asterisk which showed like that:


- 2019-08-10 07:22:21 Asterisk start
- 2019-08-15 19:39:33 WARNING taskprocessor.c: The 
'pjsip/outreg/ispPJSIP-0060' task processor queue reached 500 scheduled 
tasks.

- 2019-08-15 19:39:34 WARNING res_pjsip_outbound_registration.c: No response 
received from 'sip:isp.de' on registration attempt to '..', retrying in '60'
- 2019-08-15 19:57:19 WARNING res_pjsip_outbound_registration.c: No response 
received from 'sip:isp.de' on registration attempt to '..', retrying in '60'
- 2019-08-15 22:59:59 WARNING res_pjsip_outbound_registration.c: No response 
received from 'sip:isp.de' on registration attempt to '..', retrying in '60'
- 2019-08-16 08:28:04 WARNING res_pjsip_outbound_registration.c: No response 
received from 'sip:isp.de' on registration attempt to '..', retrying in '60'
- 2019-08-16 08:29:04 WARNING res_pjsip_outbound_registration.c: No response 
received from 'sip:isp.de' on registration attempt to '..', retrying in '60'
- 2019-08-16 08:30:04 WARNING res_pjsip_outbound_registration.c: No response 
received from 'sip:isp.de' on registration attempt to '..', retrying in '60'
- 2019-08-16 08:31:04 WARNING res_pjsip_outbound_registration.c: No response 
received from 'sip:isp.de' on registration attempt to '..', retrying in '60'
- 2019-08-16 08:32:04 WARNING res_pjsip_outbound_registration.c: No response 
received from 'sip:isp.de' on registration attempt to '..', retrying in '60'

- 2019-08-16 08:33:04 WARNING res_pjsip_outbound_registration.c: No response 
received from 'sip:isp.de' on registration attempt to '..', retrying in '60'
- 2019-08-16 08:34:04 WARNING pjproject: SSL STATUS_FROM_SSL_ERR (status): 
Level: 0 err: <33558552>  len: 0 
peer: ISP-IP:5061
- 2019-08-16 08:34:04 ERROR pjproject: ssl0x7fbf92d096f0 Error loading CA list 
file '/etc/pki/tls/certs/ca-bundle.crt': Too many open files
- 2019-08-16 08:34:04 WARNING res_pjsip_outbound_registration.c: No response 
received from 'sip:isp.de' on registration attempt to '..', retrying in '60'

Inound calls via other ISP have been dropped - only those logentries can be 
seen:
- 2019-08-16 09:25:43 WARNING[27924] res_rtp_asterisk.c: Unable to allocate 
RTCP socket: Too many open files
- 2019-08-16 09:25:44 WARNING[27924] res_rtp_asterisk.c: Unable to allocate 
RTCP socket: Too many open files



limits of asterisk:
Limit Soft Limit   Hard Limit   Units
Max cpu time  unlimitedunlimitedseconds
Max file size unlimitedunlimitedbytes
Max data size unlimitedunlimitedbytes
Max stack size8388608  unlimitedbytes
Max core file sizeunlimitedunlimitedbytes
Max resident set  unlimitedunlimitedbytes
Max processes 7767 7767 processes
Max open files1024 4096 files
Max locked memory 6553665536bytes
Max address space unlimitedunlimitedbytes
Max file locksunlimitedunlimitedlocks
Max pending signals   7767 7767 signals
Max msgqueue size 819200   819200   bytes
Max nice priority 00
Max realtime priority 00
Max realtime timeout  unlimitedunlimitedus

Memory of the device:
Disk:
7866 MB / (SD card)
771  MB Swap

phys. RAM:
2GB


Memory consumption of the asterisk process 'ps -C asterisk u':

 USER PID%CPU %MEM  VSZ RSS TTYSTAT START 
TIME   COMMAND
15.08.2019 19:01 asterisk 15910  2.2  12.8  2237024 258960  ?  Ssl  Aug10 
173:59 /usr/sbin/asterisk -vvv -mqf -C /etc/asterisk/asterisk.conf
15.08.2019 20:01 asterisk 15910  2.2  12.9  2237024 260016  ?  Ssl  Aug10 
175:06 /usr/sbin/asterisk -vvv -mqf -C /etc/asterisk/asterisk.conf
15.08.2019 21:01 asterisk 15910  2.2  12.9  2237024 260280  ?  Ssl  Aug10 
176:11 /usr/sbin/asterisk -vvv -mqf -C /etc/asterisk/asterisk.conf
15.08.2019 22:01 asterisk 15910  2.2  12.9  2237024 260544  ?  Ssl  Aug10 
177:16 /usr/sbin/asterisk -vvv -mqf -C /etc/asterisk/asterisk.conf
15.08.2019 23:01 asterisk 15910  2.2  12.9  2237024 261072  ?  Ssl  Aug10 
178:21 /usr/sbin/asterisk -vvv -mqf -C /etc/asterisk/asterisk.conf
16.08.2019 00:01 asterisk 15910  2.2  16.0  2302560 323984  ?  Ssl  Aug10 
179:36 /usr/sbin/asterisk -vvv -mqf -C /etc/asterisk/asterisk.conf
16.08.2019 01:01 asterisk 15910  2.2  21.4  2368096 431076  ?  Ssl  Aug10 
180:51 /usr/sbin/asterisk -vvv -mqf -C /etc/asterisk/asterisk.conf
16.08.2019 02:01 asterisk 15910  2.2  26.6  2499168 535784  ?  Ssl  Aug10 
182:06 /usr/sbin/asterisk -vvv -mqf -C 

Re: [asterisk-users] Anyone ever experienced a crash where Asterisk debug output a line with all nulls

[Michael Maier]

On 14.08.19 at 18:12 Dan Cropp wrote:



Maybe because the machine is performing a file system check on some other 
partitions in parallel and it's slowed down therefore?


Wouldn't /var/log/syslog show something like this if it's happening in parallel?


Well, it was just speculation. Is it even now reproducible after the 3. or even later reboot? I would try to log in via ssh as fast as possible 
(or directly via a shell) and try to find the responsible process. Try to examine the IO.



syslog has items before asterisk is starting, but once the Asterisk log files 
show it's starting to completed, /var/log/syslog has nothing.
Syslog has nothing for about 10 minutes after that.

The strange thing is the customer did a manual restart of Ubuntu 20 minutes 
later and the same slow startup time happened.


If the machine is shut down manually, did it perform a correct shutdown (= all file systems have been correctly unmounted and all processes have 
been stopped before unmounting)?


Is the startup slow even if it's done w/o reboot before?


Regards
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Anyone ever experienced a crash where Asterisk debug output a line with all nulls

[Michael Maier]

On 14.08.19 at 16:26 Dan Cropp wrote:
> We have a customer where their VM running Asterisk appears to have crashed.  
> Fortunately, we had some debugging enabled.
> The asterisk messages file has this... (in notepad+ the blank line in the 
> middle is all [NUL][NUL] [NUL][NUL])
> 
> [08/12 15:30:55.880] VERBOSE[6920] app_mixmonitor.c: Begin MixMonitor 
> Recording CBRec/IS__a37ae004-c780-4c7f-88a9-a04402f0ab4e-e70f
> [08/12 15:30:55.881] VERBOSE[6921] bridge_channel.c: Channel 
> CBRec/IS__a37ae004-c780-4c7f-88a9-a04402f0ab4e-e70f joined 'softmix' 
> base-bridge <23340bca-6823-4c70-a395-e3b092aeb671>
>   
>   
>   
>   
>   
>   
>   
> 
> [08/12 15:33:02.887] Asterisk 16.2.1 built by root @ sw-genesis-build4 on a 
> x86_64 running Linux on 2019-04-04 13:41:15 UTC

Did I get it correctly: the last line in the log before asterisk starts again 
after the reboot is the [nul]-line? If so, are you probably using ext4 or maybe 
reiserfs? I know of this problem if the machine crashes, open files can end up
like described. AFAIK it's a file system bug!

> We also had debugging enabled and things were output to our debug file for 17 
> more seconds
> The blank line in my e-mail is once again a line with all [NUL}... (in 
> notepad+ the blank line in the middle is all [NUL][NUL] [NUL][NUL])
> 
> [08/12 15:31:12.776] DEBUG[6781] audiohook.c: Read factory 0x7f079389bff8 and 
> write factory 0x7f079389ca38 both fail to provide 160 samples
> [08/12 15:31:12.777] DEBUG[6709] audiohook.c: Failed to get 160 samples from 
> read factory 0x7f07937066d8
> [08/12 15:31:12.777] DEBUG[6709] audiohook.c: Read factory 0x7f07937066d8 and 
> write factory 0x7f0793707118 both fail to provide 160 samples
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>  [08/12 15:33:02.915] Asterisk 16.2.1 built by root @ sw-genesis-build4 on a 
> x86_64 running Linux on 2019-04-04 13:41:15 UTC
> [Aug 12 15:33:02] DEBUG[1385] config.c: Parsing /etc/iss/asterisk/logger.conf
> 
> 
> 
> I believe this was bad enough that Ubuntu actually crashed, but there is 
> nothing in the syslog indicating anything until 15:32:42 where it appears 
> Linux is starting up.
> 
> 

[asterisk-users] Wanted: professional softphone

[Michael Maier]

Hello!

Does anybody by chance know of a softphone which additionally has a management 
suite to fully configure it userID based for Windows clients? Any idea is 
appreciated!


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] PJSIP / tcp: define local port to use on base of trunk definition

[Michael Maier]

Hello!

Following problem: If there are different trunks (-> different numbers and 
users / passwords) to the same destination, asterisk (16.x) always uses the 
same local tcp port for each connection. This is a problem with Deutsche 
Telekom (they
want to have different local ports for different users).

Besides the possibility to use different IP addresses (aliases) - is there a 
generic way to define on trunk base which local port to use for each user / 
number?


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] unsolved: Re: solved: how to create a working certificate for using TLS?

[Michael Maier]

On 06.07.19 at 22:16 hwilmer wrote:

Is there an advantage to using pjsip?  What's needed for easybell with pjsip?


For easybell, I don't know of any advantage. But that's not very reliable, because I'm using easybell for dedicated requirements only. I'm 
considering chan_sip legacy. I wouldn't build any new installation on chan_sip (if there are no technical contradictions).


Easybell does have a pretty fine documentation for FreePBX and pjsip:
https://www.easybell.de/nc/hilfe/ergebnis/freepbx-130124-mit-asterisk-13.html


[why encryption?]

I consider it a requirement for when employees end up using their mobile phones over foreign wireless networks, which is something that would be 
virtually impossible to prevent should the asterisk server be made reachable from the outside.


That's true. But don't forget to encrypt RTP at this point! This must be done 
additionally.
BTW: easybell doesn't support full RTP encryption. It's supported for outgoing calls only 
(https://en.easybell.de/nc/help/questions/questions-concerning-the-telephone-connection/answer/does-easybell-support-the-data-encryption-srtp-for-voip.html).


That's an example for an inbound call - there isn't any support for RTP 
encryption:

<--- Received SIP request (869 bytes) from TLS:195.185.37.60:5061 --->
INVITE sip:+4912345678989@93.165.22.128:5061;transport=TLS;line=xxx SIP/2.0
Via: SIP/2.0/TLS 195.185.37.60:5061;branch=z9hG4bKcu8ZTaf6c4iPU;rport
From: ;tag=2DC25244-5D21B65400044D02-6A194700
To: 
CSeq: 1891 INVITE
Call-ID: SBC4115eaf5-5d21b654-67c091e3-a60cca0-924117e-01_b2b-1
Max-Forwards: 68
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK
Supported: histinfo
Content-Type: application/sdp
Content-Length: 286
Contact: 


v=0
o=- 1667528048 2824605765 IN IP4 195.185.37.60
s=-
c=IN IP4 195.185.37.60
t=0 0
m=audio 30934 RTP/AVP 9 8 0 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=direction:both
a=sendrecv
a=maxptime:150




And before that, why shouldn't phone calls always be encrypted for just in 
case?  They are always genuinely private, and it doesn't hurt anything.


True - no contradiction of mine.




Setting 'tlscapath' to /etc/pki or to /etc/pki/ca-trust/source/ didn't seem to


I'm sorry - I don't know how to handle ca bundles with chan_sip. With pjsip it's

ca_list_file=/etc/pki/tls/certs/ca-bundle.crt >
in pjsip.transports.conf.


Thanks, setting 'tlscafile=/etc/pki/tls/certs/ca-bundle.crt' seems to do the 
trick.  However:


Happy to here that it's working now.



First I set 'tlsdontverifyserver=no' and issued a 'sip reload'.  There was no error message.  I found that suspicious and restarted asterisk, 
and the error message came back.


There are some config changes which need a complete restart AFAIK (FreePBX 
explicitly warns about some changes requiring a restart).


Only then I added 'tlscafile=/etc/pki/tls/certs/ca-bundle.crt' (which was unset 
before), and after a 'sip reload', the error message was gone.
So far, it hasn't come back even when restarting asterisk.


That's how I'm handling it: After each change concerning the transport I'm restarting asterisk. Just to be sure. But that's a question which 
could be answered by Joshua much better.


This shows that 'sip reload' doesn't really do a reload in that a certificate which hasn't been verified continues to be accepted after the 
configuration changed to now require verifying the certificate.


The certificate check is done on starting the connection (SYN) by openssl. sip reload most probably doesn't restart the connection (because all 
running calls would be disconnected - that's most of the time not a good idea - sip reload usually doesn't destroy running sessions / calls).


This might be a security problem, and if not, it is certainly good for surprises 
and can create much confusion.


Just handle it like this: each transport relevant change requires a complete 
restart!



Is it supposed to be like this, or should I make a bug report?


I think it's supposed to behave like this, because it would mean to disconnect all running calls on sip reload. That's probably not what most of 
the people expect / want to have.



Regards
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] unsolved: Re: solved: how to create a working certificate for using TLS?

[Michael Maier]

On 06.07.19 at 12:16 hwilmer wrote:
> On 7/6/19 10:40 AM, Michael Maier wrote:
>> On 05.07.19 at 22:02 hw wrote:
>>>
>>> openssl verify -CAfile ca.pem asterisk.pem
>>> asterisk.pem: OK
>>>
>>>
>>> When I set tlsdontverifyserver=yes, it works (i. e. asterisk registers
>>> to the SIP provider and there is no error message).  Otherwise I'm
>>> getting the error message and asterisk does not register.
>>>
>>> Reading the comments in sip.conf.sample, I would assume that asterisk
>>> can not verify the certificate of the SIP provider.  Yet
>>>
>>>
>>> openssl s_client -connect secure.sip.easybell.de:5061

I'm using easybell via tls, too - but with pjsip - I had never any problem.

>>
>> You know that you don't need an own certificate to connect via tls to the 
>> ISP?
> 
> No, I didn't know that.  However, there are local clients connecting to 
> asterisk
> using encryption, so I suppose my own certificate is required.

That's true - but why do you need encryption on your own LAN? Just for fun or 
are there any particular requirements?

>> To be able to verify the certificate of the ISP, asterisk has to know the 
>> local CA database. For CentOS 7, this is /etc/pki/tls/certs/ca-bundle.crt.
> 
> How did you know I'm doing this on Centos? :)

This was just meant as an example - chance :-)

> Setting 'tlscapath' to /etc/pki or to /etc/pki/ca-trust/source/ didn't seem to

I'm sorry - I don't know how to handle ca bundles with chan_sip. With pjsip it's

ca_list_file=/etc/pki/tls/certs/ca-bundle.crt

in pjsip.transports.conf.


Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] unsolved: Re: solved: how to create a working certificate for using TLS?

[Michael Maier]

On 05.07.19 at 22:02 hw wrote:
> 
> openssl verify -CAfile ca.pem asterisk.pem
> asterisk.pem: OK
> 
> 
> When I set tlsdontverifyserver=yes, it works (i. e. asterisk registers
> to the SIP provider and there is no error message).  Otherwise I'm
> getting the error message and asterisk does not register.
> 
> Reading the comments in sip.conf.sample, I would assume that asterisk
> can not verify the certificate of the SIP provider.  Yet
> 
> 
> openssl s_client -connect secure.sip.easybell.de:5061

You know that you don't need an own certificate to connect via tls to the ISP?

To be able to verify the certificate of the ISP, asterisk has to know the local 
CA database. For CentOS 7, this is /etc/pki/tls/certs/ca-bundle.crt.



Regards
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] High delay and some echo

[Michael Maier]

On 11.06.19 at 20:32 Luca Bertoncello wrote:
> Hi list!
> 
> I use Asterisk 13.14.1 from Debian repository on a DSL from Deutsche
> Telekom.
> 
> Asterisk works well, but I have really often an high delay (I understand
> it since the other party speak some seconds before he hears my question
> and answer) and sometimes I hear an echo.

First of all: I'm using Deutsche Telekom, too (with pjsip on CentOS 7) and 
don't have this problem.

Let me sum up at first what I understand at the moment:
- Only VoIP
- The problem isn't new.
- The problem doesn't happen always, but often.
- Asterisk uses the internet IP and doesn't do NAT.
- You're using chan_sip - not pjsip
- DSL-Line: 50/10 MBit


My questions to analyze the problem:

- What's the real usable DSL sync (can be seen at the modem)?
- Are there any (CRC) errors on the DSL side? How many and in which time?
- Deutsche Telekom reports the usable bandwidth during pppoe login. In 
messages, you can see
  something like
  SRU=37868#SRD=102957# (it's an example for a 100 MBit line)
  (grep messages for "SRU=" after a successful pppoe login)
  It contains the upload and download bandwidth in kbit/s
- Did you configure traffic shaping with tc to be sure that voice packages are 
always sent at first?
- Problem can be seen with different callees or just with one?
- Are there any callees the problem never occurred?
- Is it "just" a delay or is it choppy, too?
- You're using Banana PI - which one exactly? RAM? eth interface manufacturer? 
What about the load
  (uptime) of the system when the problem occurs? Is it swapping (what says 
"free")?
- What about the temperature of the device if the problem occurs / not occurs?
- Is there any other outbound traffic at the same time? Check with the tool 
bmon at the ppp0
  device and take a look at the upstream. One call creates 50 packages/s (pps) 
on each direction (if there is no other traffic). It shouldn't fluctuate.
- Did you set the correct QoS-type for the outgoing sip and rtp packages? In 
pjsip, the options are:
  tos=cs3
  cos=3
  You can check it with wireshark. The DSCP must be expedited forwarding (or 
the same you can see for incoming voice packages).
- asterisk has an own console, that can be reached with asterisk -r as root.
  At this point, you can get some information about the quality of a running 
call. For pjsip it's reporting the following e.g.:

  *CLI> pjsip show channelstats

 ...Receive. 
.Transmit..
 BridgeId ChannelId  UpTime.. Codec.   CountLost Pct  Jitter   
CountLost Pct  Jitter RTT
 
===

 5d67cd0b x-007e   00:00:39 g722 1296   00   0.000   1299   
00   0.000   0.000
 5d67cd0b y-007f   00:00:39 alaw 1299   00   0.000   1296   
00   0.000   0.000

 Instead of "pjsip show channelstats" you have to use something like sip show 
[press 2 times tab key] to get the possible commands.

 Each call generates two entries: one for the call from your local phone to 
asterisk and the other from asterisk to the ISP.



Hope this helps to locate the problem.
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] pjsip and tls client: How to decrypt Wireshark trace?

[Michael Maier]

Hello!

I'm just wondering if it's possible to decrypt sips packages in Wireshark while 
asterisk runs as sips client (connecting to the provider w/
tls 1.2)? I don't use an own certificate.


Thanks
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Outbound call: caller gets no ringback on session progress

[Michael Maier]

On 17.12.18 at 11:52 Joshua C. Colp wrote:
> On Sun, Dec 16, 2018, at 4:43 AM, Michael Maier wrote:
> 
> 
> 
>>
>> Another question: is there any use case for 183 Session Progress w/o 
>> SDP? IOW: Is a 183 Session
>> Progress just a bug of the ISP? If so, problem could be solved by 
>> dropping each 183 package w/o SDP.
> 
> Nothing really comes to mind that would be accomplished by sending a 183 
> without SDP but there may be cases on the internet.
> 

As long as [1] aren't fixed, the attached patch could be used as workaround. 
This workaround drops 183 Session Progress w/o SDP.

The attached workaround assumes, that 183 Session Progress w/o SDP is followed 
by 180 Ringing. If there isn't any 180 Ringing following, this patch won't fix 
anything. In
the latter case, it would be necessary to generate inband ringing by asterisk 
or send 180 Ringing instead of the broken 183 Session Progress.

The workaround applies to 13.24.1.



Caller  AsteriskISP
-
Invite >
...
<---183 Session Progress 
w/o SDP
<---180 Ringing
<---180 Ringing
...



Another 183 Situation with *P-Early-Media* header
=

Caller  AsteriskISP
-
Invite >
...
<-- 183 Session Progress w 
SDP / P-Early-Media:sendonly
<-  183 Session Progress w SDP sendrecv
<-  RTP
--> RTP
<-- 180 Session Progress 
w/o SDP / P-Early-Media:sendonly
<-- RTP (inband ringback)
...

=> the sendonly-value of P-Early-Media seems to be ignored. Asterisk doesn't 
apply the sendonly value of the P-Early-Media header of the 183 Session 
Progress package
received from the ISP to the 183 Session Progress sent to the caller.
But this is not a problem, as the ringback can still be transferred.


Regards,
Michael


[1] https://issues.asterisk.org/jira/browse/ASTERISK-28208, 
https://issues.asterisk.org/jira/browse/ASTERISK-27994
--- a/res/res_pjsip_session.c	2019-01-20 16:37:16.98300 +0100
+++ b/res/res_pjsip_session.c	2019-01-21 02:34:06.23500 +0100
@@ -2485,6 +2485,17 @@
 {
 	struct ast_sip_session_supplement *supplement;
 	struct pjsip_status_line status = rdata->msg_info.msg->line.status;
+	pjsip_rdata_sdp_info *sdp_info;
+
+	ast_debug(3, "Response is %d %.*s\n", status.code, (int) pj_strlen(),
+			pj_strbuf());
+
+	/* Michael: ignore 183 Session Progress if there is no MEDIA in package */
+	if (status.code == 183 && (! (sdp_info = pjsip_rdata_get_sdp_info(rdata)) || sdp_info->sdp_err != PJ_SUCCESS || ! sdp_info->sdp)) {
+		ast_debug(3, "Ignore response %d %.*s because of missing SDP\n", status.code, (int) pj_strlen(),
+pj_strbuf());
+		return;
+	}
 
 	AST_LIST_TRAVERSE(>supplements, supplement, next) {
 		if (!(supplement->response_priority & response_priority)) {
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Voice mail: MWI problem / pjsip (13.24.0)

[Michael Maier]

On 28.12.18 at 13:20 Doug Lytle wrote:
 Before I'm opening an issue, I would like to prove my expectations - maybe 
 it isn't a problem at all or it's a problem of the phone.
> 
> Michael,
> 
> Just a side note.  I've had reports of MWI not turning off after a message 
> has been listened to under both 13.24.0 and 13.24.1.  It will typically turn 
> off after a few minutes.  We're just using chan_sip.  I haven't had any 
> reports when we were under 13.23.1

Turning off isn't a problem here: Any time I'm requesting VMs on the phone, the 
blinking MWI is turned off and no voice mails are shown on the display any more 
(I think
it's done by the phone itself) - until next REGISTER / NOTIFY is retrieved: if 
there is any unrequested / new voice mail left, it will be signaled again by 
blinking MWI and
on the display.


Regards,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Voice mail: MWI problem / pjsip (13.24.0)

[Michael Maier]

On 27.12.18 at 18:14 Joshua C. Colp wrote:
> On Thu, Dec 27, 2018, at 1:07 PM, Michael Maier wrote:
>> Hi!
>>
>> I just want to say, that 13.24.1 doesn't fix the problem described in 
>> the posts above.
> 
> You're going to need to file an issue[1] with traces and actual configuration.
> 
> [1] https://issues.asterisk.org/jira
> 

Before I'm opening an issue, I would like to prove my expectations - maybe it 
isn't a problem at all or it's a problem of the phone.


That's how it works at the moment:

- MWI Mode: unsolicited
- MWI Aggregation: on
- Call arrives and is received as voice mail

- after next REGISTER, the first NOTIFY is sent to phone
- Phone message indicator is blinking and display says: 1 VM
- after next REGISTER, same NOTIFY is sent again
- Phone message indicator stops blinking. Display still says 1 VM
- ...

=> The phone switches of blinking indicator if NOTIFYs repeatedly send the very 
same information. If there is meanwhile
   one more VM signaled, the indicator is blinking again until this new NOTIFY 
is sent repeatedly.


My questions:
- Is MWI exactly expected to repeatedly send the same information?

- Is it expected, that unsolicited MWIs are sent only after a REGISTER and not 
at the moment the VM has been finalized?


Thanks,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Voice mail: MWI problem / pjsip (13.24.0)

[Michael Maier]

Hi!

I just want to say, that 13.24.1 doesn't fix the problem described in the posts 
above.


Regards,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Voice mail: MWI problem / pjsip (13.24.0)

[Michael Maier]

On 26.12.18 at 14:48 Michael Maier wrote:
> Hello!
> 
> I'm facing a problem concerning MWI. The problem is:
> 
> The phone switches off the MWI exactly at the moment the second NOTIFY 
> package for one voice mail
> arrives.
> 
> The phone switches off MWI independently if the voice mail has been 
> acknowledged or not before.
> 
> 
> The behavior in detail:
> 
> - Once each hour, phone sends SUBSCRIBE
> - Asterisk receives incoming voice mail for Device 200.
> - some time later: Phone executes a REGISTER
> - Directly after succeeded REGISTER, asterisk sends Notify
> - Notify is acked by phone

After enabling debugging, I detected one more strange thing:

After the voice mail call has been ended w/ BYE, asterisk directly sends a 
NOTIFY message - which
*never* reached the network stack!


[2018-12-26 16:51:46] DEBUG[4218]: res_mwi_devstate.c:50 mwi_update_cb: Sending 
inuse devstate change for MWI:1234@device
[2018-12-26 16:51:46] DEBUG[10322]: res_pjsip/pjsip_message_filter.c:288 
filter_on_tx_message: Re-wrote Contact URI host/port to 192.168.16.70:5060 
(this may be re-written again later)
<--- Transmitting SIP request (660 bytes) to UDP:192.168.16.73:7594 --->
NOTIFY sip:1234@192.168.16.73:7594 SIP/2.0
Via: SIP/2.0/UDP 
192.168.16.70:5060;rport;branch=z9hG4bKPjc8294b4c-0d0a-43b6-aaa3-3cd361fd44b2
From: "Home" ;tag=cdf1842f-6845-4419-9bba-b5aa648c1e1a
To: "Home" ;tag=494263154
Contact: 
Call-ID: 2516407290@192_168_16_73
CSeq: 18170 NOTIFY
Event: message-summary
Subscription-State: active;expires=1086
Allow-Events: message-summary, presence, dialog, refer
Max-Forwards: 70
User-Agent: FPBX-13.0.195.19(13.24.0)
Content-Type: application/simple-message-summary
Content-Length:49

Messages-Waiting: yes
Voice-Message: 3/1 (0/0)


Compared to the NOTIFY-packages after REGISTER, there is a difference in 
Subscription-State:

The NOTIFY tried to be sent after the end of the voice mail call has an active 
state:

Subscription-State: active;expires=1086

compared to the NOTIFY state after INVITE (which reach the network stack):

Subscription-State: terminated


Thanks,
regards,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] Voice mail: MWI problem / pjsip (13.24.0)

[Michael Maier]

Hello!

I'm facing a problem concerning MWI. The problem is:

The phone switches off the MWI exactly at the moment the second NOTIFY package 
for one voice mail
arrives.

The phone switches off MWI independently if the voice mail has been 
acknowledged or not before.


The behavior in detail:

- Once each hour, phone sends SUBSCRIBE
- Asterisk receives incoming voice mail for Device 200.
- some time later: Phone executes a REGISTER
- Directly after succeeded REGISTER, asterisk sends Notify
- Notify is acked by phone



The content of the packages

--
SUBSCRIBE

Contact: 
User-Agent: C610 IP/42.231.00.000.000
Event: message-summary
Expires: 3600
Allow: NOTIFY
Accept: application/simple-message-summary
Content-Length: 0


SIP/2.0 200 OK
Expires: 3600
Contact: 
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, 
PRACK, REGISTER,
REFER, MESSAGE
Supported: 100rel, timer, replaces, norefersub
Server: FPBX-13.0.195.19(13.24.0)
Content-Length:  0
--



After REGISTER:

--
NOTIFY

Contact: 
Call-ID: 7a5ee160-47a1-4efa-b190-66843d644243
CSeq: 9921 NOTIFY
Subscription-State: terminated
Event: message-summary
Allow-Events: message-summary, presence, dialog, refer
Max-Forwards: 70
User-Agent: FPBX-13.0.195.19(13.24.0)
Content-Type: application/simple-message-summary
Content-Length:49

Messages-Waiting: yes
Voice-Message: 1/1 (0/0


SIP/2.0 200 OK
Call-ID: 7a5ee160-47a1-4efa-b190-66843d644243
CSeq: 9921 NOTIFY
User-Agent: C610 IP/42.231.00.000.000
Content-Length: 0
---

=> MWI on!

-> That was expected!



Now happens next REGISTER and after this, the next NOTIFY (the same as shown 
above) is sent to the
phone

=> MWI is switched off!



If there coincidentally is a NOTIFY sequence in between ending with

Messages-Waiting: no
Voice-Message: 0/0 (0/0)

Messages-Waiting: yes
Voice-Message: 1/1 (0/0

the MWI will be active again (this may be achieved if mwi aggregation is turned 
off and the order is
exactly as shown above - but that's chance).




I'm wondering now: what's the generally expected behavior? Should the phone 
handle repeatedly sent
NOTIFY packages for same voice mail as if they had been sent once or should 
asterisk signal the same
voice mail only once and not repeatedly?


Configuration:

pjsip.aor.conf:
[1234]
mailboxes=1234@default

pjsip.endpoint.conf
[1234]
aggregate_mwi=yes or no



Thanks,
kind regards,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Outbound call: caller gets no ringback on session progress

[Michael Maier]

On 12.12.18 at 19:43 Joshua C. Colp wrote:
> On Wed, Dec 12, 2018, at 12:31 PM, Michael Maier wrote:
> 
> 
> 
>>
>> The problem: The extension doesn't create a ringback locally, because 
>> it most probably expects it to
>> be sent by the callee - but the callee doesn't send anything (not 
>> surprising, because there has been
>> no SDP).
>>
>> Or should Asterisk create the ringback (Asterisk doesn't send any RTP 
>> package)? Or should the phone
>> create the ringback itself because there is a 180 Ringing (even if it 
>> contains SDP)?
>>
>> I'm wondering: Why does Asterisk create a 183 to the extension 
>> containing SDP if the callee didn't
>> provide any SDP?
>>
>>
>> So many questions ... . Could somebody please shine some light on it? 
>> What's going wrong here?
> 
> The core doesn't communicate whether progress includes media or not, so the 
> PJSIP channel driver (and even chan_sip) assumes media is there. 

Another question: is there any use case for 183 Session Progress w/o SDP? IOW: 
Is a 183 Session
Progress just a bug of the ISP? If so, problem could be solved by dropping each 
183 package w/o SDP.


Thanks,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Outbound call: caller gets no ringback on session progress

[Michael Maier]

On 12.12.18 at 19:43 Joshua C. Colp wrote:
> On Wed, Dec 12, 2018, at 12:31 PM, Michael Maier wrote:
> 
> 
> 
>>
>> The problem: The extension doesn't create a ringback locally, because 
>> it most probably expects it to
>> be sent by the callee - but the callee doesn't send anything (not 
>> surprising, because there has been
>> no SDP).
>>
>> Or should Asterisk create the ringback (Asterisk doesn't send any RTP 
>> package)? Or should the phone
>> create the ringback itself because there is a 180 Ringing (even if it 
>> contains SDP)?
>>
>> I'm wondering: Why does Asterisk create a 183 to the extension 
>> containing SDP if the callee didn't
>> provide any SDP?
>>
>>
>> So many questions ... . Could somebody please shine some light on it? 
>> What's going wrong here?
> 
> The core doesn't communicate whether progress includes media or not, so the 
> PJSIP channel driver (and even chan_sip) assumes media is there. What should 
> happen in chan_pjsip is that it would send inband ringing and not a 180 
> Ringing with SDP, but that is not currently implemented and I don't think 
> this particularly interaction has come up before to cause it to be 
> implemented. I'd therefore suggest raising an issue[1] with the SIP trace.

https://issues.asterisk.org/jira/browse/ASTERISK-28208


Thanks,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] Outbound call: caller gets no ringback on session progress

[Michael Maier]

Hello!

An extension registered at asterisk 13.23 initiates an external call (pjsip). 
After the Invite, the
callee (-> ISP) sends a

100 Trying
183 Session Progress (*without* SDP)


Asterisk now sends to the extension:

183 Session Progress (*with* SDP)
183 Session Progress (*with* SDP) (really two times)


The callee meanwhile sends

180 Ringing (*without* SDP)

which is "forwarded" by Asterisk to the extension with

180 Ringing (*with* SDP)


The problem: The extension doesn't create a ringback locally, because it most 
probably expects it to
be sent by the callee - but the callee doesn't send anything (not surprising, 
because there has been
no SDP).

Or should Asterisk create the ringback (Asterisk doesn't send any RTP package)? 
Or should the phone
create the ringback itself because there is a 180 Ringing (even if it contains 
SDP)?

I'm wondering: Why does Asterisk create a 183 to the extension containing SDP 
if the callee didn't
provide any SDP?


So many questions ... . Could somebody please shine some light on it? What's 
going wrong here?



Thanks,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] pjsip: TOS not working any more

[Michael Maier]

On 08/09/2018 at 10:49 PM Michael Maier wrote:
> Hello!
> 
> I'm using TOS as shown below with pjsip 13.22.0-rc1 (same with 13.21.1).
> Unfortunately, the TOS isn't set in reality any more (it used to work
> some time ago).

Got the problem.

I'm using freepbx and for the configuration of TOS, I'm using the
individual config file pjsip.endpoint_custom_post.conf.

After disabling one of my trunks via GUI, this trunk couldn't be find
any more by asterisk in pjsip.endpoint_custom_post.conf and the complete
configuration provided there was ignored. I had to comment out the
deactivated trunk. Now it's working again.

But I'm wondering why I have to define TOS for each trunk individually
if it is already defined for the transport as defined below?


Thanks,
Michael


> 
> 
> Transport:        
> 
> ==
> 
> 
> Transport:  0.0.0.0-udp   udp  0    184  0.0.0.0:5061
> 
>  ParameterName  : ParameterValue
>  ==
>  allow_reload   : true
>  async_operations   : 1
>  bind   : 0.0.0.0:5061
>  ca_list_file   :
>  ca_list_path   :
>  cert_file  :
>  cipher :
>  cos    : 0
>  domain :
>  external_media_address :
>  external_signaling_address :
>  external_signaling_port    : 0
>  local_net  : 192.168.13.0/255.255.255.0
>  local_net  : 192.168.17.0/255.255.255.0
>  method : unspecified
>  password   :
>  priv_key_file  :
>  protocol   : udp
>  require_client_cert    : No
>  symmetric_transport    : false
>  tos    : 184
>  verify_client  : No
>  verify_server  : No
>  websocket_write_timeout    : 100
> 

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] pjsip: TOS not working any more

[Michael Maier]

Hello!

I'm using TOS as shown below with pjsip 13.22.0-rc1 (same with 13.21.1). 
Unfortunately, the TOS isn't set in reality any more (it used to work 
some time ago).



Transport: 


==

Transport:  0.0.0.0-udp   udp  0184  0.0.0.0:5061

 ParameterName  : ParameterValue
 ==
 allow_reload   : true
 async_operations   : 1
 bind   : 0.0.0.0:5061
 ca_list_file   :
 ca_list_path   :
 cert_file  :
 cipher :
 cos: 0
 domain :
 external_media_address :
 external_signaling_address :
 external_signaling_port: 0
 local_net  : 192.168.13.0/255.255.255.0
 local_net  : 192.168.17.0/255.255.255.0
 method : unspecified
 password   :
 priv_key_file  :
 protocol   : udp
 require_client_cert: No
 symmetric_transport: false
 tos: 184
 verify_client  : No
 verify_server  : No
 websocket_write_timeout: 100


Is there some kernel support needed to get it working? I reduced the 
kernel to a minimum of modules.



Thanks,
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] res_fax_spandsp - information about used protocol t38 or g711?

[Michael Maier]

On 05/21/2018 at 06:46 PM Andre Gronwald wrote:
> after completion you find ${FAXMODE} filled with audio or T38, depending
> on what has been used.
> hope that is what you are looking for.

Yes, that's exactly what I've been looking for!


Thanks,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] res_fax_spandsp - information about used protocol t38 or g711?

[Michael Maier]

Hello!

I'm working on a fax solution, which reports the result of each sent or
received fax to the database.

When using option "F" or not using option "f", it's clear which protocol
has been used. But if "f" is used, it could be g711 or t38. Is there any
variable which contains this information at the end of the fax transmission?

I'm using asterisk 13.


Thanks for any hint,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] Search for (multi tenant) fax to mail solution

[Michael Maier]

Hello!

I'm just searching for a fax to email / email to fax open source based
complete solution which covers the following core features:

- high availability
- possibly multi tenant
- about 40,000 users
- about 100 lines parallel
- supports G.711 / T.38
- scriptable user management (reading, adding and removing of accounts)
  (via REST)
- personal and default smtp address for each user: each user becomes a
  personal address and an additional default fall back address (if
  personal address doesn't work any more).
- Additional web interface for user maintenance
- Support of user based faxcovers
- paid enterprise support
- Linux (RHEL or SLES) based

Does anybody have any idea or experience and may suggest to look at the
one or other solution?


Thanks in advance,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] What does pct mean?

[Michael Maier]

On 02/13/2018 at 08:41 AM Floimair Florian wrote:
> No you're reading it wrong.
> 
> There are 188K received with no loss, and 16441K transmitted.

This doesn't make any sense to me, either. There can't be more packages
transmitted than received. It's the same codec in and out and it's been
running exactly the same time.

> ...Receive. .Transmit..
> CountLost Pct  Jitter   CountLost PctJitter  RTT
> 188K  00   0.000188K   16641K 8809   0.000   0.026
  
There are 188K received and 188K transmitted. Pct is unknown - what's Pct?


> 
> Still 8809 does not sound like a percentage to me  so there is something 
> wrong with either the label or the value.
> From what's in the code, you can see it's clearly a lost Packet count not a 
> percentage.
> So I guess Pct in this case is short for "Packet".
> 
>  
>  
> With best regards
> 
> Florian Floimair
> Innovation - Software-Development
> 
> COMMEND INTERNATIONAL GMBH
> http://www.commend.com
> 
> Security and Communication by Commend
> 
> FN 178618z | LG Salzburg
> 
> -Ursprüngliche Nachricht-
> Von: asterisk-users-boun...@lists.digium.com 
> [mailto:asterisk-users-boun...@lists.digium.com] Im Auftrag von Michael Maier
> Gesendet: Montag, 12. Februar 2018 17:46
> An: asterisk-users@lists.digium.com
> Betreff: Re: [asterisk-users] What does pct mean?
> 
> Hi Carsten,
> 
> On 02/11/2018 at 07:46 PM Carsten Bock wrote:
>> Hi,
>>
>> Lost percent (%)
> 
> Are you sure? I'm seeing here:
> 
> ...Receive. .Transmit..
> CountLost Pct  Jitter   CountLost PctJitter  RTT
> 188K  00   0.000188K   16641K 8809   0.000   0.026
> 
> => This doesn't sound reliable to me: there are 188K packets and 16641K of 
> them are lost?! The Pct value is fluctuating between about 6009 and 9009.
> 
> Thanks,
> Michael
> 
> 
>>
>>
>> Am 11.02.2018 19:27 schrieb "Michael Maier" <m1278...@mailbox.org>:
>>
>>> Hello,
>>>
>>> could somebody please tell me the meaning of "Pct" as seen in asterisk cli:
>>>
>>> ...Receive. .Transmit..
>>> CountLost Pct  Jitter   CountLost Pct  Jitter RTT
>>>
>>>
>>> Thanks,
>>> Michael
> 
> --
> _
> -- Bandwidth and Colocation Provided by 
> https://linkprotect.cudasvc.com/url?a=http://www.api-digital.com=E,1,uxGzivqW6oZ241hxc5A3oz1rZf6JLog-Gi4ziwN-95NzbE_HEndRkD8LLLem_gvmmxd5k_T95J2jepit1IpIkZ2AxkG4RSoADT-AMulX4hxaaQ,,=1
>  --
> 
> Check out the new Asterisk community forum at: https://community.asterisk.org/
> 
> New to Asterisk? Start here:
>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
> 
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>
> https://linkprotect.cudasvc.com/url?a=http://lists.digium.com/mailman/listinfo/asterisk-users=E,1,wIdvPI63-ImQqWZFblrmlGJbQ_cbmu31TlSPHYv9kAkHrNRLdIAjL2IUr9sVYxm6piHc0Pf2Zna7zuNOJ2hb4CVzp2WYVDsgZJqAyHt2YkVuGQ,,=1
> 


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] What does pct mean?

[Michael Maier]

Hi Carsten,

On 02/11/2018 at 07:46 PM Carsten Bock wrote:
> Hi,
> 
> Lost percent (%)

Are you sure? I'm seeing here:

...Receive. .Transmit..
CountLost Pct  Jitter   CountLost PctJitter  RTT
188K  00   0.000188K   16641K 8809   0.000   0.026

=> This doesn't sound reliable to me: there are 188K packets and 16641K
of them are lost?! The Pct value is fluctuating between about 6009 and 9009.

Thanks,
Michael


> 
> 
> Am 11.02.2018 19:27 schrieb "Michael Maier" <m1278...@mailbox.org>:
> 
>> Hello,
>>
>> could somebody please tell me the meaning of "Pct" as seen in asterisk cli:
>>
>> ...Receive. .Transmit..
>> CountLost Pct  Jitter   CountLost Pct  Jitter RTT
>>
>>
>> Thanks,
>> Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] What does pct mean?

[Michael Maier]

Hello,

could somebody please tell me the meaning of "Pct" as seen in asterisk cli:

...Receive. .Transmit..
CountLost Pct  Jitter   CountLost Pct  Jitter RTT


Thanks,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] asterisk 13.18.0: pjsip: unnecessary 603 decline because of wrong codec decision

[Michael Maier]

On 11/01/2017 at 10:14 AM Antony Stone wrote:
> On Wednesday 01 November 2017 at 08:10:36, Michael Maier wrote:
> 
>> Hello!
>>
>> I'm facing the following scenario:
>>
>> - Initial call opened to asterisk: SDP g722,alaw,ulaw
>>
>> - Outgoing call to provider started with Invite / SDP alaw, g726 and
>>   g729.
> 
> So, you're claiming to the provider that you can support all those codecs.
> 
>> - Provider sends 183 Session progress SDP: g729, alaw
>>
>> - Provider sends g729 rtp packages
>>
>>
>> But: there is no license to transcode g729.
> 
> So, you shouldn't be offering it.

Why? Asterisk lists this codec as supported - it just cannot transcode
it (but it could be passed through). And it wouldn't be necessary to
transcode at all, because provider offered alaw, too.

BTW: here is a g729 library to transcode:
https://gist.github.com/worldadventurer/c80e4d051937db887b40f3ab0084ce06

> 
>>
>> What is asterisk doing?
>> Asterisk decides to stop the call at all:
>> - Sends cancel to provider and 603 decline to internal caller.
>>
>> What would have been correct?
>> It would have been correctly to switch to alaw as provider offered it, too.
> 
> Once the codec's been agreed on,

Asterisk didn't agree! There has been no 200 ok sdp. Therefore Asterisk
would have the chance to pick the other codec. But it didn't try it at
all. It just canceled the call.

> between what the two sides offer to each 
> other, you can't change it later.  Only offer what you're prepared to accept.
> 
>> Workaround:
>> My workaround is to disable g729 and things are working fine again for
>> me (for this special case).
> 
> That's not a workaround - that's correct configuation.
> 
> If you don't have a G.729 licence, don't offer G.729 to the peer.

Passthrough would work if there would be a phone on the other side
supporting g729. Therefore it's ok to offer it.


Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] asterisk 13.18.0: pjsip: unnecessary 603 decline because of wrong codec decision

[Michael Maier]

Hello!

I'm facing the following scenario:

- Initial call opened to asterisk: SDP g722,alaw,ulaw

- Outgoing call to provider started with Invite / SDP alaw, g726 and
  g729.

- Provider sends 183 Session progress SDP: g729, alaw

- Provider sends g729 rtp packages


But: there is no license to transcode g729.


What is asterisk doing?
Asterisk decides to stop the call at all:
- Sends cancel to provider and 603 decline to internal caller.


What would have been correct?
It would have been correctly to switch to alaw as provider offered it, too.


Workaround:
My workaround is to disable g729 and things are working fine again for
me (for this special case).


I'm seeing here two basic problems:
1. Asterisk prevents a call which could have been working fine if
   asterisk would have done the switch to alaw which is offered by
   provider.
2. Asterisk would have done completely unnecessary transcoding even if
   g729 transcoding would have been supported.


I would be glad, if Asterisk would take better care of what it's
deciding which codec to use. g729 was the codec with the lowermost
priority in the own offered SDP to the provider but it anyway accepts
this codec even though provider offers the own most desired alaw!



Thanks,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] asterisk 13.16. - sigseg during negotiation

[Michael Maier]

On 06/18/2017 at 12:11 PM, Joshua Colp wrote:
> On Sun, Jun 18, 2017, at 06:00 AM, Michael Maier wrote:
>> Hello!
>>
>> unchanged asterisk crashes during udptl / t.38 negotiation with telekom
>> - they do not support t.38 / udptl.
> 
> All Asterisk issues need to go through the issue tracker[1]. In this
> case we'd also need to see the full SIP debug so we can understand the
> complete interaction.
> 
> [1] https://issues.asterisk.org/jira
> 

See https://issues.asterisk.org/jira/browse/ASTERISK-27061

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] asterisk 13.16. - sigseg during negotiation

[Michael Maier]

Hello!

unchanged asterisk crashes during udptl / t.38 negotiation with telekom
- they do not support t.38 / udptl.

In detail:

fax client -> asterisk -> telekom -> easybell -> asterisk -> fax server


Fax server sends t.38 reinvite via asterisk to easybell.

   Session Description Protocol Version (v): 0
   Owner/Creator, Session Id (o): - 2447581897 4 IN IP4 46.17.15.23
   Session Name (s): Asterisk
   Connection Information (c): IN IP4 46.17.15.23
   Time Description, active time (t): 0 0
   Media Description, name and address (m): image 4573 udptl t38
   Media Attribute (a): T38FaxVersion:0
   Media Attribute (a): T38MaxBitRate:14400
   Media Attribute (a): T38FaxRateManagement:transferredTCF
   Media Attribute (a): T38FaxMaxDatagram:397
   Media Attribute (a): T38FaxUdpEC:t38UDPRedundancy


This reinvite is received by asterisk via telekom:

   Session Description Protocol Version (v): 0
   Owner/Creator, Session Id (o): - 1811299599 2925027276 IN IP4 0.0.0.0
   Session Name (s): -
   Time Description, active time (t): 0 0
   Media Description, name and address (m): image 0 udptl t38
   Media Attribute (a): sendrecv
   Media Attribute (a): T38FaxVersion:0
   Media Attribute (a): T38MaxBitRate:14400
   Media Attribute (a): T38FaxRateManagement:transferredTCF
   Media Attribute (a): T38FaxMaxDatagram:397
   Media Attribute (a): T38FaxUdpEC:t38UDPRedundancy


And asterisk gives it to the fax client:

   Session Description Protocol Version (v): 0
   Owner/Creator, Session Id (o): - 1497774025 5 IN IP4 192.168.12.13
   Session Name (s): Asterisk
   Connection Information (c): IN IP4 192.168.12.13
   Time Description, active time (t): 0 0
   Media Description, name and address (m): image 4284 udptl t38
   Media Attribute (a): T38FaxVersion:0
   Media Attribute (a): T38MaxBitRate:14400
   Media Attribute (a): T38FaxRateManagement:transferredTCF
   Media Attribute (a): T38FaxMaxDatagram:393
   Media Attribute (a): T38FaxUdpEC:t38UDPRedundancy

Completely ignoring, that telekom doesn't support it (port and ip
addresses are set to 0).

On completing the negotiation after 200 ok SDP and ACK from fax client,
asterisk crashes. Stack trace is attached!


Regards,
Michael
Program terminated with signal 11, Segmentation fault.

#0  ast_copy_pj_str (dest=0x7fb9f5901100 "x\277\001

Re: [asterisk-users] asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'

[Michael Maier]

On 06/17/2017 at 02:18 PM, Michael Maier wrote:
> On 06/16/2017 at 04:00 PM, Joshua Colp wrote:
>> On Fri, Jun 16, 2017, at 10:49 AM, Michael Maier wrote:
>>
>> 
>>
>>>
>>> t38modem and asterisk are using
>>>
>>> m=image 35622 udptl t38
>>>^
>>>
>>> Provider uses
>>>
>>> m=image 35622 UDPTL t38
>>>^
>>>
>>> Could this be a problem? If I'm sending internal only, it's always 
>>> lowercase.
>>
>> Looking at the tests we have we only use 'udptl' as the transport.
>> Without diving deep into the SDP negotiator it is possible that it gets
>> upset at that, as we would only produce 'udptl'. If the SDP negotiator
>> in PJSIP is case sensitive then you'd get a declined stream like you
>> see. Looking at the T.38 examples from the ITU doc also shows it in
>> lowercase, so uppercase is probably not commonly used.
> 
> I can proof, that UDPTL vs. udptl is the problem. After "fixing"
> asterisk and opal both using UDPTL, the negotiation works flawlessly.
> See attached patches.

For opal, the sip patch (src/t38/sipt38.cxx) is enough - the other two
patches aren't necessary. It's only a SIP-problem.


Regards,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'

[Michael Maier]

On 06/16/2017 at 04:00 PM, Joshua Colp wrote:
> On Fri, Jun 16, 2017, at 10:49 AM, Michael Maier wrote:
> 
> 
> 
>>
>> t38modem and asterisk are using
>>
>> m=image 35622 udptl t38
>>^
>>
>> Provider uses
>>
>> m=image 35622 UDPTL t38
>>^
>>
>> Could this be a problem? If I'm sending internal only, it's always 
>> lowercase.
> 
> Looking at the tests we have we only use 'udptl' as the transport.
> Without diving deep into the SDP negotiator it is possible that it gets
> upset at that, as we would only produce 'udptl'. If the SDP negotiator
> in PJSIP is case sensitive then you'd get a declined stream like you
> see. Looking at the T.38 examples from the ITU doc also shows it in
> lowercase, so uppercase is probably not commonly used.

I can proof, that UDPTL vs. udptl is the problem. After "fixing"
asterisk and opal both using UDPTL, the negotiation works flawlessly.
See attached patches.

Sending t38 faxes internally works fine. Externally via provider gets
stuck: the provider doesn't send back any t38-package to the client
(t38-packages are leaving asterisk towards the provider, but the
provider doesn't send back any package to the client :-().

Any idea what to change to get the provider to communicate?

(From the 200 Ok from the provider - nothing critical from my point of
view - these are the values I sent in the reinvite to the provider)

Connection Information (c): IN IP4 195.185.37.60
  Time Description, active time (t): 0 0
  Media Description, name and address (m): image 31410 UDPTL t38
  Media Attribute (a): sendrecv
  Media Attribute (a): T38FaxVersion:0
  Media Attribute (a): T38MaxBitRate:14400
  Media Attribute (a): T38FaxRateManagement:transferredTCF
  Media Attribute (a): T38FaxMaxDatagram:397
  Media Attribute (a): T38FaxUdpEC:t38UDPRedundancy


Thanks,
Michael
--- a/src/t38/t38proto.cxx	2013-02-20 03:18:46.0 +0100
+++ b/src/t38/t38proto.cxx	2017-06-17 06:08:19.447901812 +0200
@@ -470,7 +470,7 @@
 };
 
 
-PFACTORY_CREATE(PFactory, T38PseudoRTP_Handler, "udptl", false);
+PFACTORY_CREATE(PFactory, T38PseudoRTP_Handler, "UDPTL", false);
 
 
 /
--- a/src/t38/sipt38.cxx	2013-02-20 03:18:46.0 +0100
+++ b/src/t38/sipt38.cxx	2017-06-17 06:09:08.687899689 +0200
@@ -82,7 +82,7 @@
 
 PCaselessString SDPFaxMediaDescription::GetSDPTransportType() const
 { 
-  return "udptl";
+  return "UDPTL";
 }
 
 SDPMediaDescription * SDPFaxMediaDescription::CreateEmpty() const
--- a/src/t38/t38mf.cxx	2013-02-20 03:18:46.0 +0100
+++ a/src/t38/t38mf.cxx	2017-06-17 06:07:51.499903017 +0200
@@ -92,7 +92,7 @@
 
 PString OpalFaxMediaType::GetRTPEncoding() const
 {
-  return "udptl";
+  return "UDPTL";
 }
 
 
--- a/res/res_pjsip_t38.c	2017-06-15 19:17:02.31600 +0200
+++ b/res/res_pjsip_t38.c	2017-06-15 19:20:26.28000 +0200
@@ -728,7 +730,7 @@
 	static const pj_str_t STR_IN = { "IN", 2 };
 	static const pj_str_t STR_IP4 = { "IP4", 3};
 	static const pj_str_t STR_IP6 = { "IP6", 3};
-	static const pj_str_t STR_UDPTL = { "udptl", 5 };
+	static const pj_str_t STR_UDPTL = { "UDPTL", 5 };
 	static const pj_str_t STR_T38 = { "t38", 3 };
 	static const pj_str_t STR_TRANSFERREDTCF = { "transferredTCF", 14 };
 	static const pj_str_t STR_LOCALTCF = { "localTCF", 8 };
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] pjsip: asterisk can't decide which codec to use

[Michael Maier]

On 05/13/2017 at 07:21 AM Michael Maier wrote:
> On 05/12/2017 at 08:49 PM, Joshua Colp wrote:
>> On Fri, May 12, 2017, at 02:46 PM, Michael Maier wrote:
>>
>> 
>>
>>>
>>> If I'm doing exactly the same call originated with another extension,
>>> there can't be seen these frequent changes. But the strange thing is,
>>> that in both cases the part between extension and asterisk doesn't show
>>> any codec changes ... .
>>>
>>> Deeper investigations show, that if the conference (callee) sends the
>>> first rtp package (-> g711 - should be g722), things are going choppy, 
>>> if the extension (caller) sends the first package (g722), things are 
>>> running stable.
>>>
>>>
>>> Any idea to convince asterisk always to use the first codec of ok sdp 
>>> or how to convince asterisk to put only one codec to ok sdp (the first).
>>
>> This is not currently an option in chan_pjsip but I'd suggest filing an
>> issue[1] for this scenario with all available information.
>>
>> [1] https://issues.asterisk.org/jira
> 
> https://issues.asterisk.org/jira/browse/ASTERISK-26996

I just tested your fix 2 times w/ using the scenario mentioned in the
bug report. It has been working for me. No more flipping.

Asterisks indeed commits more than one codec in ok sdp, but always uses
the first one afterwards. Hopefully the peer always handles it the same
way. I would have thought that the ok sdp contains just one codec (the
best).


Thanks,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'

[Michael Maier]

Am 16.06.2017 um 11:12 schrieb Joshua Colp:

On Fri, Jun 16, 2017, at 02:13 AM, Michael Maier wrote:


Has anybody any idea why asterisk drops the media stream in the 200 OK?
The channel has been T38_ENABLED before! Or is it necessary to add more
debug code? Who does the negotiating?
Only asterisk or is pjsip doing some parts, too?


Asterisk does the T.38 negotiation and produces the answer SDP, PJSIP
does the SDP negotiation. It's likely in the realm of Asterisk where it
is doing that.



t38modem and asterisk are using

m=image 35622 udptl t38
  ^

Provider uses

m=image 35622 UDPTL t38
  ^

Could this be a problem? If I'm sending internal only, it's always 
lowercase.


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'

[Michael Maier]

On 06/15/2017 at 08:15 AM Michael Maier wrote:
> On 06/14/2017 at 10:17 PM, Joshua Colp wrote:
>> On Wed, Jun 14, 2017, at 05:09 PM, Michael Maier wrote:
>>
>> 
>>
>>>
>>> I can now say, that asterisk / pjsip seams to work *mostly* as expected.
>>> Just one exception - and that's the package in question, which can't be
>>> seen in tcpdump.
>>>
>>> I extended the above patch by adding the info at the last output:
>>>
>>> ast_debug(3, "PJ_TRUE 3 - ready %s\n", pjsip_rx_data_get_info(rdata));
>>>
>>> This gives, that for *all* received packages return PJ_TRUE is reached.
>>>
>>> But: all packages besides of the phantom resend use the same address
>>> rdata0x7f963c0009b8 - only the phantom resent package uses
>>> rdata0x7f9654081e18. I think, that's the problem. But I don't know what
>>> it means and where it comes from. Do you have an idea?
>>
>> Not without setting up the scenario and digging deep into it. Nothing
>> immediately springs to mind.
>>
> 
> After enabling pjsip specific debug log in asterisk, I can see, the
> following behavior:
> Incoming packages from network are always signaled like this (e.g.):
> 
> sip_endpoint.c Processing incoming message: Request msg INVITE/cseq=10 
> (rdata0x7f5f1801a758)
> <--- Received SIP request (918 bytes) from UDP:195.185.37.60:5060
> ...
> 
> 
> The path of the critical not existing package is like this and can't 
> be seen elsewhere (there wasn't any corresponding incoming 
> message entry before):
> 
> sip_endpoint.c Distributing rdata to modules: Request msg INVITE/cseq=10 
> (rdata0x7f5f100e4c38)
> <--- Received SIP request (918 bytes) from UDP:195.185.37.60:5060 --->
> ...
> 
> Normally, "Distributing rdata to modules" can be seen only if 
> pjsip_rx_data_clone is called like in res_pjsip/pjsip_distributor.c
> 
> This is really odd, because if the fax is sent locally (w/o provider) 
> directly between the same extension, this behavior can't be seen and 
> therefore it's working fine as expected!
> 
> 
> 
> That's the complete critical excerpt, starting with the regular reInvite 
> received from provider:
> 
> 
> [2017-06-15 07:43:57] DEBUG[11705]: pjproject:0 :
> sip_endpoint.c Processing incoming message: Request msg INVITE/cseq=10 
> (rdata0x7f5f1801a758)
> <--- Received SIP request (918 bytes) from UDP:195.185.37.60:5060 --->
> INVITE sip:+49111@42.13.16.27:5061 SIP/2.0
> Via: SIP/2.0/UDP 195.185.37.60;branch=z9hG4bKHeVwGavN;rport
> From: 
> <sip:1...@sip.easybell.de>;tag=72F0675F-5942027B00075955-FB9F9700
> To: 
> <sip:+49...@sip.easybell.de>;tag=f045584d-da09-4913-9b46-102361e397f2
> CSeq: 10 INVITE
> Call-ID: 7f582402-0ce9-4a1a-87f6-b8de8b2a7bc8
> Max-Forwards: 68
> Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, 
> PRACK, REGISTER, REFER, MESSAGE
> Supported: 100rel, timer, replaces, norefersub
> Content-Type: application/sdp
> Content-Length: 265
> Contact: <sip:64A510CA-5942027B00065C24-6F93C700@195.185.37.60;transport=udp>
> 
> v=0
> o=- 1935061780 1935061784 IN IP4 195.185.37.60
> s=-
> c=IN IP4 195.185.37.60
> t=0 0
> m=image 33818 UDPTL t38
> a=sendrecv
> a=T38FaxVersion:0
> a=T38MaxBitRate:14400
> a=T38FaxRateManagement:transferredTCF
> a=T38FaxMaxDatagram:1393
> a=T38FaxUdpEC:t38UDPRedundancy
> 
> [2017-06-15 07:43:57] DEBUG[11705]: res_pjsip/pjsip_distributor.c:379 
> distributor: Searching for serializer on dialog dlg0x7f5f18034698 for Request 
> msg INVITE/cseq=10 (rdata0x7f5f1801a758)
> [2017-06-15 07:43:57] DEBUG[11705]: res_pjsip/pjsip_distributor.c:385 
> distributor: Found serializer pjsip/outsess/easybellPJSIP-0076 on dialog 
> dlg0x7f5f18034698
> [2017-06-15 07:43:57] DEBUG[11705]: res_pjsip/pjsip_distributor.c:433 
> distributor: rdata clone: Request msg INVITE/cseq=10 (rdata0x7f5f18052b08)
> [2017-06-15 07:43:57] DEBUG[11705]: res_pjsip/pjsip_distributor.c:446 
> distributor: PJ_TRUE 3 - ready Request msg INVITE/cseq=10 
> (rdata0x7f5f1801a758)
> [2017-06-15 07:43:57] DEBUG[25171]: pjproject:0 :
> sip_endpoint.c Distributing rdata to modules: Request msg INVITE/cseq=10 
> (rdata0x7f5f18052b08)
> [2017-06-15 07:43:57] DEBUG[25171]: res_pjsip_t38.c:268 
> t38_initialize_session: UDPTL initialized on session for 
> PJSIP/easybellPJSIP-0009
> [2017-06-15 07:43:57] DEBUG[25171]: res_pjsip_t38.c:138 t38_change_state: 
> T.38 state changed to '2' from '0' on channel 'PJSIP/easybellPJSIP-0009'
> [2017-06-15 07:43:57] DEBUG[25171]: res_pjsip_t38.c:673 
> d

Re: [asterisk-users] asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'

[Michael Maier]

On 06/14/2017 at 10:17 PM, Joshua Colp wrote:
> On Wed, Jun 14, 2017, at 05:09 PM, Michael Maier wrote:
> 
> 
> 
>>
>> I can now say, that asterisk / pjsip seams to work *mostly* as expected.
>> Just one exception - and that's the package in question, which can't be
>> seen in tcpdump.
>>
>> I extended the above patch by adding the info at the last output:
>>
>> ast_debug(3, "PJ_TRUE 3 - ready %s\n", pjsip_rx_data_get_info(rdata));
>>
>> This gives, that for *all* received packages return PJ_TRUE is reached.
>>
>> But: all packages besides of the phantom resend use the same address
>> rdata0x7f963c0009b8 - only the phantom resent package uses
>> rdata0x7f9654081e18. I think, that's the problem. But I don't know what
>> it means and where it comes from. Do you have an idea?
> 
> Not without setting up the scenario and digging deep into it. Nothing
> immediately springs to mind.
> 

After enabling pjsip specific debug log in asterisk, I can see, the
following behavior:
Incoming packages from network are always signaled like this (e.g.):

sip_endpoint.c Processing incoming message: Request msg INVITE/cseq=10 
(rdata0x7f5f1801a758)
<--- Received SIP request (918 bytes) from UDP:195.185.37.60:5060
...


The path of the critical not existing package is like this and can't 
be seen elsewhere (there wasn't any corresponding incoming 
message entry before):

sip_endpoint.c Distributing rdata to modules: Request msg INVITE/cseq=10 
(rdata0x7f5f100e4c38)
<--- Received SIP request (918 bytes) from UDP:195.185.37.60:5060 --->
...

Normally, "Distributing rdata to modules" can be seen only if 
pjsip_rx_data_clone is called like in res_pjsip/pjsip_distributor.c

This is really odd, because if the fax is sent locally (w/o provider) 
directly between the same extension, this behavior can't be seen and 
therefore it's working fine as expected!



That's the complete critical excerpt, starting with the regular reInvite 
received from provider:


[2017-06-15 07:43:57] DEBUG[11705]: pjproject:0 :sip_endpoint.c 
Processing incoming message: Request msg INVITE/cseq=10 (rdata0x7f5f1801a758)
<--- Received SIP request (918 bytes) from UDP:195.185.37.60:5060 --->
INVITE sip:+49111@42.13.16.27:5061 SIP/2.0
Via: SIP/2.0/UDP 195.185.37.60;branch=z9hG4bKHeVwGavN;rport
From: <sip:1...@sip.easybell.de>;tag=72F0675F-5942027B00075955-FB9F9700
To: 
<sip:+49...@sip.easybell.de>;tag=f045584d-da09-4913-9b46-102361e397f2
CSeq: 10 INVITE
Call-ID: 7f582402-0ce9-4a1a-87f6-b8de8b2a7bc8
Max-Forwards: 68
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, 
PRACK, REGISTER, REFER, MESSAGE
Supported: 100rel, timer, replaces, norefersub
Content-Type: application/sdp
Content-Length: 265
Contact: <sip:64A510CA-5942027B00065C24-6F93C700@195.185.37.60;transport=udp>

v=0
o=- 1935061780 1935061784 IN IP4 195.185.37.60
s=-
c=IN IP4 195.185.37.60
t=0 0
m=image 33818 UDPTL t38
a=sendrecv
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxDatagram:1393
a=T38FaxUdpEC:t38UDPRedundancy

[2017-06-15 07:43:57] DEBUG[11705]: res_pjsip/pjsip_distributor.c:379 
distributor: Searching for serializer on dialog dlg0x7f5f18034698 for Request 
msg INVITE/cseq=10 (rdata0x7f5f1801a758)
[2017-06-15 07:43:57] DEBUG[11705]: res_pjsip/pjsip_distributor.c:385 
distributor: Found serializer pjsip/outsess/easybellPJSIP-0076 on dialog 
dlg0x7f5f18034698
[2017-06-15 07:43:57] DEBUG[11705]: res_pjsip/pjsip_distributor.c:433 
distributor: rdata clone: Request msg INVITE/cseq=10 (rdata0x7f5f18052b08)
[2017-06-15 07:43:57] DEBUG[11705]: res_pjsip/pjsip_distributor.c:446 
distributor: PJ_TRUE 3 - ready Request msg INVITE/cseq=10 (rdata0x7f5f1801a758)
[2017-06-15 07:43:57] DEBUG[25171]: pjproject:0 :sip_endpoint.c 
Distributing rdata to modules: Request msg INVITE/cseq=10 (rdata0x7f5f18052b08)
[2017-06-15 07:43:57] DEBUG[25171]: res_pjsip_t38.c:268 t38_initialize_session: 
UDPTL initialized on session for PJSIP/easybellPJSIP-0009
[2017-06-15 07:43:57] DEBUG[25171]: res_pjsip_t38.c:138 t38_change_state: T.38 
state changed to '2' from '0' on channel 'PJSIP/easybellPJSIP-0009'
[2017-06-15 07:43:57] DEBUG[25171]: res_pjsip_t38.c:673 
defer_incoming_sdp_stream: Deferring incoming SDP stream on 
PJSIP/easybellPJSIP-0009 for peer re-invite
[2017-06-15 07:43:57] DEBUG[25198][C-0004]: bridge_native_rtp.c:348 
native_rtp_bridge_compatible_check: Bridge 
'f8e63423-8fc7-44e4-a33d-c55b7d87d30f' can not use native RTP bridge as it was 
forbidden while getting details
[2017-06-15 07:43:57] DEBUG[25198][C-0004]: bridge.c:506 
find_best_technology: Bridge technology native_rtp is not compatible with 
properties of existing bridge.
[2017-06-15 07:43:57] DEBUG[25198][C-0004]: bridge.c:496 
find_best_te

Re: [asterisk-users] asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'

[Michael Maier]

On 06/14/2017 at 05:53 PM Joshua Colp wrote:
> On Wed, Jun 14, 2017, at 12:47 PM, Michael Maier wrote:
> 
> 
> 
>>
>> I added this patch to see, if really all packages are are freed after
>> they have been processed:
>>
>> --- b/res/res_pjsip/pjsip_distributor.c 2017-05-30 19:44:16.0
>> +0200
>> +++ a/res/res_pjsip/pjsip_distributor.c 2017-06-13 20:25:27.23300
>> +0200
>> @@ -407,6 +407,7 @@
>> /* We have a BYE or CANCEL request without a serializer.
>> */
>> pjsip_endpt_respond_stateless(ast_sip_get_pjsip_endpoint(),
>> rdata,
>> PJSIP_SC_CALL_TSX_DOES_NOT_EXIST, NULL, NULL,
>> NULL);
>> +   ast_debug(3, "PJ_TRUE 1\n");
>> return PJ_TRUE;
>> } else {
>> if (ast_taskprocessor_alert_get()) {
>> @@ -439,8 +440,8 @@
>> pjsip_rx_data_free_cloned(clone);
>> }
>>  
>> +   ast_debug(3, "PJ_TRUE 3 - ready\n");
>> ast_taskprocessor_unreference(serializer);
>> -
>> return PJ_TRUE;
>>  }
>>  
>>
>>
>> Unfortunately, this patch crashes asterisk when debug is enabled. Is
>> there another way to check, if all the packages are really freed?
> 
> That shouldn't cause Asterisk to crash. There's nothing built in to
> specifically try to debug this kind of situation. Adding logging to try
> to understand what is going on is probably the easiest way.
> 

Got it - I had to change the complete asterisk-packages (I'm compiling
on base of spec file) - and not just the asterisk-core.

I can now say, that asterisk / pjsip seams to work *mostly* as expected.
Just one exception - and that's the package in question, which can't be
seen in tcpdump.

I extended the above patch by adding the info at the last output:

ast_debug(3, "PJ_TRUE 3 - ready %s\n", pjsip_rx_data_get_info(rdata));

This gives, that for *all* received packages return PJ_TRUE is reached.

But: all packages besides of the phantom resend use the same address
rdata0x7f963c0009b8 - only the phantom resent package uses
rdata0x7f9654081e18. I think, that's the problem. But I don't know what
it means and where it comes from. Do you have an idea?


Thanks,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'

[Michael Maier]

On 06/11/2017 at 06:51 PM Joshua Colp wrote:
> On Sun, Jun 11, 2017, at 01:47 PM, Joshua Colp wrote:
>> The distributor is in res/res_pjsip/pjsip_distributor.c, the distributor
>> function being the entry point. That function returning PJ_TRUE
>> indicates to PJSIP that it has been handled and no subsequent modules
>> should be called by that running thread. The distributor itself, though,
>> ends up executing things further in a worker thread using the distribute
>> function.
> 
> To be more detailed - PJSIP maintains no queue, a message comes in from
> a transport and is given to modules until one says it has handled the
> message. We place our distributor close to the transport and it puts the
> message into a queue for handling in Asterisk ensuring serialization as
> appropriate, returning that it has handled the message so no other
> modules handle it at that time. Once the message is handled from the
> queue it picks back up invoking modules at the point where the original
> thread left off. This ensures messages are handled as quickly as
> possible without blocking the transport but also provides guarantees on
> ordering and simultaneous execution. (Two messages for the same call
> will be handled in order, one at a time).
> 

I added this patch to see, if really all packages are are freed after
they have been processed:

--- b/res/res_pjsip/pjsip_distributor.c 2017-05-30 19:44:16.0 +0200
+++ a/res/res_pjsip/pjsip_distributor.c 2017-06-13 20:25:27.23300 +0200
@@ -407,6 +407,7 @@
/* We have a BYE or CANCEL request without a serializer. */
pjsip_endpt_respond_stateless(ast_sip_get_pjsip_endpoint(), 
rdata,
PJSIP_SC_CALL_TSX_DOES_NOT_EXIST, NULL, NULL, NULL);
+   ast_debug(3, "PJ_TRUE 1\n");
return PJ_TRUE;
} else {
if (ast_taskprocessor_alert_get()) {
@@ -439,8 +440,8 @@
pjsip_rx_data_free_cloned(clone);
}
 
+   ast_debug(3, "PJ_TRUE 3 - ready\n");
ast_taskprocessor_unreference(serializer);
-
return PJ_TRUE;
 }
 


Unfortunately, this patch crashes asterisk when debug is enabled. Is
there another way to check, if all the packages are really freed?


Thanks,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'

[Michael Maier]

On 06/11/2017 at 11:35 PM Daniel Tryba wrote:
> On Sun, Jun 11, 2017 at 01:16:10PM +0200, Michael Maier wrote:
>> Let's go into details:
>> I'm starting at the point where asterisk / fax client receives the T.38
>> reininvite from the server from the provider 195.185.37.60:5060 for the
>> fax client (extension 91):
> 
> I'm running Asterisk 11 on my faxserver so not using pjsip but chan_sip.
> But IIRC I had problems with asterisk-11/t38modem-2.0.0/hylafax if the
> upstream side started the t38 reINVITE on sending a fax. My hylafax
> config.ttyT38* contains the AT F command to initiale t38 on the t38modem
> side for outgoing calls. For incoming t38modem also starts the reINVITE
> but there is no parameter to influence this in my configs.
> 
> No idea if this is in anyway related nor what the default is of the
> options below and neither if it depends on the t38modem version.

Didn't change anything unfortunately.

Thanks anyway!
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'

[Michael Maier]

On 06/11/2017 at 04:34 PM Michael Maier wrote:
> On 06/11/2017 at 01:29 PM Joshua Colp wrote:
>> On Sun, Jun 11, 2017, at 08:16 AM, Michael Maier wrote:
>>
>> 
>>  
>>> I did some further investigations and fixed a local problem. Now,
>>> asterisk is able to successfully activate T.38 - unfortunately just for
>>> very shot time because of a phantom package it receives!
>>
>> What was the local problem?
> 
> Update of t38modem from 3.13 to 3.15

I forgot to mention the main thing: I initially used *two* trunks (and
one number), one "normal" trunk and another trunk_fax additionally
enabling udptl. Outbound not a problem - but inbound used the normal
trunk - this can't work. Merging both trunks to one trunk has been the
solution, which isn't a problem with udptl, because it's initially
handled by the extension (t38modem). That's why I came across line
option for the other provider I'm using and which wasn't that easy to
use with FreePBX, because it is not yet directly supported and
pjsip.registration_custom_post.conf unfortunately doesn't work (I'm not
the only one experiencing this problem). Therefore I'm using now a trick
which works especially for the registration problem within FreePBX as
long as it isn't supported natively.



Thanks,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'

[Michael Maier]

On 06/11/2017 at 04:39 PM Joshua Colp wrote:
> On Sun, Jun 11, 2017, at 11:34 AM, Michael Maier wrote:
> 
> 
> 
>>>
>>> PJSIP uses a dispatch model. The request is queued up, acted on, and
>>> then that's it. The act of acting on it removes it from the queue.
>>
>> That's the *expected* behavior ... . I rechecked again and again. All
>> existing tcpdumps. The "resent" package isn't part of any tcpdump
>> (wireshark doesn't show it) - and during tcpdump no package was dropped.
>>
>>> The
>>> only reason I'd expect to see it again is if there was a retransmission
>>> or something somehow requeued it up - but I don't think we do that
>>> anywhere. Not quite sure why it would be happening...
>>
>> But even if this package would have really been sent (as retransmission)
>> - shouldn't there be another response? T.38 has been successfully
>> enabled before and the faxclient has already sent a valid 200 ok
>> including complete SDP information to asterisk.
>>
>> All in all it looks really odd to me.
> 
> Depends on how we handle that scenario. I don't think we have any tests
> to cover it, so it's entirely possible that we wouldn't respond like
> that. Why it's happening in the first place I still don't know though,
> haven't seen anything like it.

Do you have any idea where to check if acted packages are really
removed? Is there a way to check the pjsip-queue? Where could I start to
look at? How does asterisk get them from the queue? And how does pjsip
know that asterisk has processed them?



Thanks,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'

[Michael Maier]

On 06/11/2017 at 01:29 PM Joshua Colp wrote:
> On Sun, Jun 11, 2017, at 08:16 AM, Michael Maier wrote:
> 
> 
>  
>> I did some further investigations and fixed a local problem. Now,
>> asterisk is able to successfully activate T.38 - unfortunately just for
>> very shot time because of a phantom package it receives!
> 
> What was the local problem?

Update of t38modem from 3.13 to 3.15

>> Let's go into details:
>> I'm starting at the point where asterisk / fax client receives the T.38
>> reininvite from the server from the provider 195.185.37.60:5060 for the
>> fax client (extension 91):
> 
> 
> 
>>
>> But now, something strange happens: Asterisk "receives" a T.38 reinvite
>> package from provider!
>> Why is it strange? Because *this package doesn't exist at all* ! It
>> can't be seen in tcpdump. I did 4 tests - always the same! Where does
>> this package come from? It's exactly the same package which can be seen
>> at the beginning of the trace excerpted here! Isn't it been deleted
>> after it has been processed the first time?
> 
> PJSIP uses a dispatch model. The request is queued up, acted on, and
> then that's it. The act of acting on it removes it from the queue.

That's the *expected* behavior ... . I rechecked again and again. All
existing tcpdumps. The "resent" package isn't part of any tcpdump
(wireshark doesn't show it) - and during tcpdump no package was dropped.

> The
> only reason I'd expect to see it again is if there was a retransmission
> or something somehow requeued it up - but I don't think we do that
> anywhere. Not quite sure why it would be happening...

But even if this package would have really been sent (as retransmission)
- shouldn't there be another response? T.38 has been successfully
enabled before and the faxclient has already sent a valid 200 ok
including complete SDP information to asterisk.

All in all it looks really odd to me.


Thanks,
regards,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'

[Michael Maier]

On 06/05/2017 at 09:32 PM Joshua Colp wrote:
> On Mon, Jun 5, 2017, at 04:26 PM, Michael Maier wrote:
>> On 06/05/2017 at 06:29 PM, Joshua Colp wrote:
>>> On Mon, Jun 5, 2017, at 01:22 PM, Michael Maier wrote:
>>>>
>>>> Do you have any idea where to start to look at? Adding additional output
>>>> in the source code? Which functions could be interesting? I may add own
>>>> debug code to see why things are happening as they happen here.
>>>
>>> The logic for T.38 negotiation lives all in the res_pjsip_t38 module and
>>> the request to negotiate works using a control frame which is handled by
>>> the t38_interpret_parameters function. It's up to that to initialize
>>> things and then request that a session refresh occurs (which sends the
>>> re-invite). That'd be the place to look.
>>
>> I added a debug output at the beginning of the function to see if it's
>> ever 
>> been called.
>>
>> t38_interpret_parameters is never been called ... .
> 
> That would likely mean that the frame is not getting sent (this also
> happens in that module) or that it is getting lost in the bridging
> framework. Digging into that is not something that can be expressed in
> general terms in email...

I did some further investigations and fixed a local problem. Now,
asterisk is able to successfully activate T.38 - unfortunately just for
very shot time because of a phantom package it receives!

Let's go into details:
I'm starting at the point where asterisk / fax client receives the T.38
reininvite from the server from the provider 195.185.37.60:5060 for the
fax client (extension 91):



<--- Received SIP request (918 bytes) from UDP:195.185.37.60:5060 --->
INVITE sip:+4971511336089@42.21.35.43:5061 SIP/2.0
Via: SIP/2.0/UDP 195.185.37.60;branch=z9hG4bKd8EHOaij;rport
From: <sip:071511336...@sip.easybell.de>;tag=124E09F9-593D01CC00045378-134F4700
To: 
<sip:+4971511336...@sip.easybell.de>;tag=dd67e8fd-cd74-40e2-bf58-dc99b182aec9
CSeq: 10 INVITE
Call-ID: c34cc459-96f3-47a6-8279-d46cddf9abb7
Max-Forwards: 68
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, 
PRACK, REGISTER, REFER, MESSAGE
Supported: 100rel, timer, replaces, norefersub
Content-Type: application/sdp
Content-Length: 265
Contact: <sip:38BD4B10-593D01CC0003604C-F1EE2700@195.185.37.60;transport=udp>

v=0
o=- 2068461195 2068461199 IN IP4 195.185.37.60
s=-
c=IN IP4 195.185.37.60
t=0 0
m=image 24842 UDPTL t38
a=sendrecv
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxDatagram:1393
a=T38FaxUdpEC:t38UDPRedundancy

[2017-06-11 10:39:42] DEBUG[24434]: res_pjsip/pjsip_distributor.c:379 
distributor: Searching for serializer on dialog dlg0x7fdde801e258 for Request 
msg INVITE/cseq=10 (rdata0x7fddb4012488)
[2017-06-11 10:39:42] DEBUG[24434]: res_pjsip/pjsip_distributor.c:385 
distributor: Found serializer pjsip/outsess/easybellPJSIP-0076 on dialog 
dlg0x7fdde801e258
[2017-06-11 10:39:42] DEBUG[25822]: res_pjsip_t38.c:268 t38_initialize_session: 
UDPTL initialized on session for PJSIP/easybellPJSIP-0005
[2017-06-11 10:39:42] DEBUG[25822]: res_pjsip_t38.c:138 t38_change_state: T.38 
state changed to '2' from '0' on channel 'PJSIP/easybellPJSIP-0005'
[2017-06-11 10:39:42] DEBUG[25822]: res_pjsip_t38.c:696 
defer_incoming_sdp_stream: Deferring incoming SDP stream on 
PJSIP/easybellPJSIP-0005 for peer re-invite
[2017-06-11 10:39:42] DEBUG[25987][C-0002]: bridge_native_rtp.c:348 
native_rtp_bridge_compatible_check: Bridge 
'a10ac2c1-5045-4a7d-ada4-6a6e54671b9d' can not use native RTP bridge as it was 
forbidden while getting details
[2017-06-11 10:39:42] DEBUG[25987][C-0002]: bridge.c:506 
find_best_technology: Bridge technology native_rtp is not compatible with 
properties of existing bridge.
[2017-06-11 10:39:42] DEBUG[25987][C-0002]: bridge.c:496 
find_best_technology: Bridge technology softmix does not have any capabilities 
we want.
[2017-06-11 10:39:42] DEBUG[25987][C-0002]: bridge.c:496 
find_best_technology: Bridge technology holding_bridge does not have any 
capabilities we want.
[2017-06-11 10:39:42] DEBUG[25987][C-0002]: bridge.c:515 
find_best_technology: Chose bridge technology simple_bridge
[2017-06-11 10:39:42] DEBUG[25987][C-0002]: bridge.c:1046 
smart_bridge_operation: Bridge a10ac2c1-5045-4a7d-ada4-6a6e54671b9d is already 
using the new technology.
[2017-06-11 10:39:42] DEBUG[25822]: res_pjsip_t38.c:268 t38_initialize_session: 
UDPTL initialized on session for PJSIP/91-0004
[2017-06-11 10:39:42] DEBUG[25822]: res_pjsip_t38.c:138 t38_change_state: T.38 
state changed to '1' from '0' on channel 'PJSIP/91-0004'
[2017-06-11 10:39:42] DEBUG[25822]: res_rtp_asterisk.c:5342 ast_rtp_prop_set: 
Ignoring duplicate RTCP property on RTP instance '0x7fddc8011b10'

Re: [asterisk-users] pjsip: Inbound calls: selecting the correct trunk with one provider and different numbers

[Michael Maier]

On 06/09/2017 at 08:44 PM Michael Maier wrote:
> On 06/08/2017 at 10:22 PM Michael Maier wrote:
>> Hello Joshua,
>>
>> thank you very much for your extremely quick answer! I really appreciate
>> your work and your friendly and your patient support!
>>
>>
>> On 06/07/2017 at 10:33 PM, Joshua Colp wrote:
>>> On Wed, Jun 7, 2017, at 05:28 PM, Michael Maier wrote:
>>>> Hello!
>>>>
>>>> I've got a problem to select the correct trunk if there is one provider
>>>> and different numbers with different configurations for this same
>>>> provider.
>>>>
>>>> Example:
>>>>
>>>> trunk-prov1-2345
>>>> trunk-prov1-2346
>>>> trunk-prov1-2347
>>>>
>>>> Each trunk registers an own number (at the same provider) and provides
>>>> own configuration: they have different allowed codecs e.g..
>>>>
>>>> What I'm experiencing now, is, that each incoming call is provided by
>>>> trunk-prov1-2346, no matter which number has been dialed.
>>>>
>>>> The problem isn't the routing (this is done on base of the correct DID),
>>>> but the problem is, that wrong codices are used if the wrong trunk is
>>>> selected.
>>>>
>>>> Is this a problem of asterisk or is it caused by the provider, which
>>>> always addresses the same "trunk" regardless which number has been
>>>> called?
>>>
>>> Asterisk is the one who associates an incoming message with an endpoint.
>>> In the case of providers you can use IP based matching - which would
>>> behave as you see, only one can be matched. The second option is the
>>> line option[1] which may or may not work (it depends on the behavior of
>>> the provider). If it works then the right endpoint would be chosen. Out
>>> of those two options there's nothing else applicable built in to match.
>>>
>>> [1]
>>> http://blogs.asterisk.org/2016/01/27/the-pjsip-outbound-registration-line-option/
>>>
>>
>> Unfortunately Deutsche Telekom doesn't support this solution :-(.
> 
> Further investigation showed, that Telekom provides the line info in the
> Request Line (as seen by Wireshark):
> 
> Request-Line: INVITE sip:+49@46.37.15.4:5060;line=azpreyb SIP/2.0
> 
> You can't find it if you expect it in contact header - or do you expect
> it in the Request-Line?

Ok - got it.

It's necessary, that the value given for endpoint= is exactly the same
name as used for the trunk name itself and the match option for this
trunk should be omitted completely.


Thanks,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] pjsip: Inbound calls: selecting the correct trunk with one provider and different numbers

[Michael Maier]

On 06/08/2017 at 10:22 PM Michael Maier wrote:
> Hello Joshua,
> 
> thank you very much for your extremely quick answer! I really appreciate
> your work and your friendly and your patient support!
> 
> 
> On 06/07/2017 at 10:33 PM, Joshua Colp wrote:
>> On Wed, Jun 7, 2017, at 05:28 PM, Michael Maier wrote:
>>> Hello!
>>>
>>> I've got a problem to select the correct trunk if there is one provider
>>> and different numbers with different configurations for this same
>>> provider.
>>>
>>> Example:
>>>
>>> trunk-prov1-2345
>>> trunk-prov1-2346
>>> trunk-prov1-2347
>>>
>>> Each trunk registers an own number (at the same provider) and provides
>>> own configuration: they have different allowed codecs e.g..
>>>
>>> What I'm experiencing now, is, that each incoming call is provided by
>>> trunk-prov1-2346, no matter which number has been dialed.
>>>
>>> The problem isn't the routing (this is done on base of the correct DID),
>>> but the problem is, that wrong codices are used if the wrong trunk is
>>> selected.
>>>
>>> Is this a problem of asterisk or is it caused by the provider, which
>>> always addresses the same "trunk" regardless which number has been
>>> called?
>>
>> Asterisk is the one who associates an incoming message with an endpoint.
>> In the case of providers you can use IP based matching - which would
>> behave as you see, only one can be matched. The second option is the
>> line option[1] which may or may not work (it depends on the behavior of
>> the provider). If it works then the right endpoint would be chosen. Out
>> of those two options there's nothing else applicable built in to match.
>>
>> [1]
>> http://blogs.asterisk.org/2016/01/27/the-pjsip-outbound-registration-line-option/
>>
> 
> Unfortunately Deutsche Telekom doesn't support this solution :-(.

Further investigation showed, that Telekom provides the line info in the
Request Line (as seen by Wireshark):

Request-Line: INVITE sip:+49@46.37.15.4:5060;line=azpreyb SIP/2.0

You can't find it if you expect it in contact header - or do you expect
it in the Request-Line?


Regards,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] pjsip: Inbound calls: selecting the correct trunk with one provider and different numbers

[Michael Maier]

Hello Joshua,

thank you very much for your extremely quick answer! I really appreciate
your work and your friendly and your patient support!


On 06/07/2017 at 10:33 PM, Joshua Colp wrote:
> On Wed, Jun 7, 2017, at 05:28 PM, Michael Maier wrote:
>> Hello!
>>
>> I've got a problem to select the correct trunk if there is one provider
>> and different numbers with different configurations for this same
>> provider.
>>
>> Example:
>>
>> trunk-prov1-2345
>> trunk-prov1-2346
>> trunk-prov1-2347
>>
>> Each trunk registers an own number (at the same provider) and provides
>> own configuration: they have different allowed codecs e.g..
>>
>> What I'm experiencing now, is, that each incoming call is provided by
>> trunk-prov1-2346, no matter which number has been dialed.
>>
>> The problem isn't the routing (this is done on base of the correct DID),
>> but the problem is, that wrong codices are used if the wrong trunk is
>> selected.
>>
>> Is this a problem of asterisk or is it caused by the provider, which
>> always addresses the same "trunk" regardless which number has been
>> called?
> 
> Asterisk is the one who associates an incoming message with an endpoint.
> In the case of providers you can use IP based matching - which would
> behave as you see, only one can be matched. The second option is the
> line option[1] which may or may not work (it depends on the behavior of
> the provider). If it works then the right endpoint would be chosen. Out
> of those two options there's nothing else applicable built in to match.
> 
> [1]
> http://blogs.asterisk.org/2016/01/27/the-pjsip-outbound-registration-line-option/
> 

Unfortunately Deutsche Telekom doesn't support this solution :-(. I
tried it by faking DNS entries and use different server names to get
different IP addresses. Unfortunately, this doesn't work, because the
name wasn't accepted by the ISP. Using the IP address directly isn't a
good solution, too, because you can't receive changes any more.

A "solution" would be via regularly created rpz DNS entries, which are
used to resolve a fake server name (like fake1.real.name.com) by
asterisk to the desired IP. All other string operations would use the
real.name.com.

Ok, it's a pipe dream!


Regards,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] pjsip: Inbound calls: selecting the correct trunk with one provider and different numbers

[Michael Maier]

Hello!

I've got a problem to select the correct trunk if there is one provider
and different numbers with different configurations for this same provider.

Example:

trunk-prov1-2345
trunk-prov1-2346
trunk-prov1-2347

Each trunk registers an own number (at the same provider) and provides
own configuration: they have different allowed codecs e.g..

What I'm experiencing now, is, that each incoming call is provided by
trunk-prov1-2346, no matter which number has been dialed.

The problem isn't the routing (this is done on base of the correct DID),
but the problem is, that wrong codices are used if the wrong trunk is
selected.

Is this a problem of asterisk or is it caused by the provider, which
always addresses the same "trunk" regardless which number has been called?



Thanks for any hint,
regards,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'

[Michael Maier]

On 06/05/2017 at 06:29 PM, Joshua Colp wrote:
> On Mon, Jun 5, 2017, at 01:22 PM, Michael Maier wrote:
>>
>> Do you have any idea where to start to look at? Adding additional output
>> in the source code? Which functions could be interesting? I may add own
>> debug code to see why things are happening as they happen here.
> 
> The logic for T.38 negotiation lives all in the res_pjsip_t38 module and
> the request to negotiate works using a control frame which is handled by
> the t38_interpret_parameters function. It's up to that to initialize
> things and then request that a session refresh occurs (which sends the
> re-invite). That'd be the place to look.

I added a debug output at the beginning of the function to see if it's ever 
been called.

t38_interpret_parameters is never been called ... .


[2017-06-05 20:52:21] DEBUG[719]: res_pjsip_t38.c:772 
create_outgoing_sdp_stream: Not creating outgoing SDP stream: T.38 not enabled
[2017-06-05 20:52:22] DEBUG[719]: res_pjsip_t38.c:772 
create_outgoing_sdp_stream: Not creating outgoing SDP stream: T.38 not enabled
[2017-06-05 20:52:22] DEBUG[719]: res_pjsip_t38.c:768 
create_outgoing_sdp_stream: Not creating outgoing SDP stream: T.38 not enabled
[2017-06-05 20:52:23] DEBUG[719]: res_pjsip_t38.c:772 
create_outgoing_sdp_stream: Not creating outgoing SDP stream: T.38 not enabled
[2017-06-05 20:52:23] DEBUG[921]: res_pjsip_t38.c:772 
create_outgoing_sdp_stream: Not creating outgoing SDP stream: T.38 not enabled
[2017-06-05 20:52:24] DEBUG[719]: res_pjsip_t38.c:268 t38_initialize_session: 
UDPTL initialized on session for PJSIP/91-0003
[2017-06-05 20:52:24] DEBUG[719]: res_pjsip_t38.c:138 t38_change_state: T.38 
state changed to '2' from '0' on channel 'PJSIP/91-0003'
[2017-06-05 20:52:24] DEBUG[719]: res_pjsip_t38.c:696 
defer_incoming_sdp_stream: Deferring incoming SDP stream on PJSIP/91-0003 
for peer re-invite
[2017-06-05 20:52:29] DEBUG[719]: res_pjsip_t38.c:207 t38_automatic_reject: 
Automatically rejecting T.38 request on channel 'PJSIP/91-0003'
[2017-06-05 20:52:29] DEBUG[719]: res_pjsip_t38.c:138 t38_change_state: T.38 
state changed to '4' from '2' on channel 'PJSIP/91-0003'
[2017-06-05 20:52:29] DEBUG[719]: res_pjsip_t38.c:721 
negotiate_incoming_sdp_stream: Declining; T.38 state is rejected or declined
[2017-06-05 20:52:29] DEBUG[719]: res_pjsip_t38.c:138 t38_change_state: T.38 
state changed to '0' from '4' on channel 'PJSIP/91-0003'
[2017-06-05 20:52:29] DEBUG[719]: res_pjsip_t38.c:772 
create_outgoing_sdp_stream: Not creating outgoing SDP stream: T.38 not enabled



Thanks,
regards,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'

[Michael Maier]

On 06/05/2017 at 06:10 PM, Joshua Colp wrote:
> On Mon, Jun 5, 2017, at 12:00 PM, Joshua Colp wrote:
>> On Mon, Jun 5, 2017, at 11:49 AM, Michael Maier wrote:
>>> On 06/05/2017 at 11:30 AM, Joshua Colp wrote:
>>>> On Sun, Jun 4, 2017, at 10:40 AM, Michael Maier wrote:
>>>>> On 06/04/2017 at 01:41 PM Telium Technical Support wrote:
>>>>>> Just a guess (without knowing about your network), but are the two ends
>>>>>> points on public networks and visible to one another?  If not the 
>>>>>> reinvite
>>>>>> may be passing an internal (nat'ed) address to the other and the 
>>>>>> connection
>>>>>> will fail...just a though
>>>>>
>>>>> t38modem -tt -o /var/log/t38modem.log --no-h323 -u 91 --sip-listen
>>>>> udp\$127.0.0.1:6060 --ptty +/dev/ttyT380,+/dev/ttyT381 --route
>>>>> 'modem:.*=sip:@127.0.0.1:5061' --route 'sip:.*=modem:'
>>>>> --sip-register 91@127.0.0.1:5061,password
>>>>>
>>>>> I tried it with a global IP (instead of 127.0.0.1) - same behavior.
>>>>>
>>>>> The point is, that the receiving part, which initiates the t.38 switch,
>>>>> doesn't sent the switch to the ISP. It is blocked / ignored by asterisk
>>>>> at all - don't know why it isn't sent to the ISP.
>>>>
>>>> I'd suggest providing the console output and SIP traffic (pjsip set
>>>> logger on) so we can see exactly what is going on.
>>>>
>>>
>>> I attached the debug output I already created before.
>>>
>>> Interesting part starts around line 2740.
>>>
>>>
>>> 91 -> local pjsip fax-extension
>>>
>>> 127.0.0.1:5061 -> asterisk server local connect for fax-extension (->
>>> not encrypted even if it is port 5061!)
>>>
>>> external fax number at easybell (195.185.37.60), which is called and
>>> which is answered here: 122
>>
>> And the pjsip.conf endpoint entry for easybellPJSIP_FAX?
> 
> I plugged the provided configuration into an existing testsuite test
> quickly and things still worked as expected, so it's something outside
> of that but nothing stands out in the debug log.

Do you have any idea where to start to look at? Adding additional output
in the source code? Which functions could be interesting? I may add own
debug code to see why things are happening as they happen here.


Thanks,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'

[Michael Maier]

On 06/05/2017 at 05:00 PM, Joshua Colp wrote:
> On Mon, Jun 5, 2017, at 11:49 AM, Michael Maier wrote:
>> On 06/05/2017 at 11:30 AM, Joshua Colp wrote:
>>> On Sun, Jun 4, 2017, at 10:40 AM, Michael Maier wrote:
>>>> On 06/04/2017 at 01:41 PM Telium Technical Support wrote:
>>>>> Just a guess (without knowing about your network), but are the two ends
>>>>> points on public networks and visible to one another?  If not the reinvite
>>>>> may be passing an internal (nat'ed) address to the other and the 
>>>>> connection
>>>>> will fail...just a though
>>>>
>>>> t38modem -tt -o /var/log/t38modem.log --no-h323 -u 91 --sip-listen
>>>> udp\$127.0.0.1:6060 --ptty +/dev/ttyT380,+/dev/ttyT381 --route
>>>> 'modem:.*=sip:@127.0.0.1:5061' --route 'sip:.*=modem:'
>>>> --sip-register 91@127.0.0.1:5061,password
>>>>
>>>> I tried it with a global IP (instead of 127.0.0.1) - same behavior.
>>>>
>>>> The point is, that the receiving part, which initiates the t.38 switch,
>>>> doesn't sent the switch to the ISP. It is blocked / ignored by asterisk
>>>> at all - don't know why it isn't sent to the ISP.
>>>
>>> I'd suggest providing the console output and SIP traffic (pjsip set
>>> logger on) so we can see exactly what is going on.
>>>
>>
>> I attached the debug output I already created before.
>>
>> Interesting part starts around line 2740.
>>
>>
>> 91 -> local pjsip fax-extension
>>
>> 127.0.0.1:5061 -> asterisk server local connect for fax-extension (->
>> not encrypted even if it is port 5061!)
>>
>> external fax number at easybell (195.185.37.60), which is called and
>> which is answered here: 122
> 
> And the pjsip.conf endpoint entry for easybellPJSIP_FAX?
> 

[easybellPJSIP_FAX]
type=endpoint
transport=0.0.0.0-udp
context=from-trunk
disallow=all
allow=alaw,ulaw
aors=easybellPJSIP_FAX
language=de
outbound_auth=easybellPJSIP_FAX
from_domain=sip.easybell.de
from_user=+49222
t38_udptl=yes
t38_udptl_ec=redundancy
fax_detect=no
t38_udptl_nat=no
send_rpid=yes
send_pai=yes
dtmf_mode=rfc4733
tos_audio=0xb8
direct_media=yes
rewrite_contact=no
force_rport=yes



 ParameterName  : ParameterValue
 =
 100rel : yes
 accountcode:
 acl:
 aggregate_mwi  : true
 allow  : (alaw|ulaw)
 allow_overlap  : true
 allow_subscribe: true
 allow_transfer : true
 aors   : easybellPJSIP_FAX
 asymmetric_rtp_codec   : false
 auth   :
 bind_rtp_to_media_address  : false
 call_group :
 callerid   : 
 callerid_privacy   : allowed_not_screened
 callerid_tag   :
 connected_line_method  : invite
 contact_acl:
 context: from-trunk
 cos_audio  : 0
 cos_video  : 0
 device_state_busy_at   : 0
 direct_media   : true
 direct_media_glare_mitigation  : none
 direct_media_method: invite
 disable_direct_media_on_nat: false
 dtls_ca_file   :
 dtls_ca_path   :
 dtls_cert_file :
 dtls_cipher:
 dtls_fingerprint   : SHA-256
 dtls_private_key   :
 dtls_rekey : 0
 dtls_setup : active
 dtls_verify: No
 dtmf_mode  : rfc4733
 fax_detect : false
 fax_detect_timeout : 0
 force_avp  : false
 force_rport: true
 from_domain: sip.easybell.de
 from_user  : +49222
 g726_non_standard  : false
 ice_support: false
 identify_by: username
 inband_progress: false
 language   : de
 mailboxes  :
 media_address  :
 media_encryption   : no
 media_encryption_optimistic: false
 media_use_received_transport   : false
 message_context:
 moh_suggest: default
 mwi_from_user  :
 mwi_subscribe_replaces_unsolicited : false
 named_call_group   

Re: [asterisk-users] asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'

[Michael Maier]

On 06/05/2017 at 11:30 AM, Joshua Colp wrote:
> On Sun, Jun 4, 2017, at 10:40 AM, Michael Maier wrote:
>> On 06/04/2017 at 01:41 PM Telium Technical Support wrote:
>>> Just a guess (without knowing about your network), but are the two ends
>>> points on public networks and visible to one another?  If not the reinvite
>>> may be passing an internal (nat'ed) address to the other and the connection
>>> will fail...just a though
>>
>> t38modem -tt -o /var/log/t38modem.log --no-h323 -u 91 --sip-listen
>> udp\$127.0.0.1:6060 --ptty +/dev/ttyT380,+/dev/ttyT381 --route
>> 'modem:.*=sip:@127.0.0.1:5061' --route 'sip:.*=modem:'
>> --sip-register 91@127.0.0.1:5061,password
>>
>> I tried it with a global IP (instead of 127.0.0.1) - same behavior.
>>
>> The point is, that the receiving part, which initiates the t.38 switch,
>> doesn't sent the switch to the ISP. It is blocked / ignored by asterisk
>> at all - don't know why it isn't sent to the ISP.
> 
> I'd suggest providing the console output and SIP traffic (pjsip set
> logger on) so we can see exactly what is going on.
> 

I attached the debug output I already created before.

Interesting part starts around line 2740.


91 -> local pjsip fax-extension

127.0.0.1:5061 -> asterisk server local connect for fax-extension (->
not encrypted even if it is port 5061!)

external fax number at easybell (195.185.37.60), which is called and
which is answered here: 122




Thanks,
Michael


t38.debug.bz2
Description: application/bzip
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'

[Michael Maier]

On 06/04/2017 at 01:41 PM Telium Technical Support wrote:
> Just a guess (without knowing about your network), but are the two ends
> points on public networks and visible to one another?  If not the reinvite
> may be passing an internal (nat'ed) address to the other and the connection
> will fail...just a though

t38modem -tt -o /var/log/t38modem.log --no-h323 -u 91 --sip-listen
udp\$127.0.0.1:6060 --ptty +/dev/ttyT380,+/dev/ttyT381 --route
'modem:.*=sip:@127.0.0.1:5061' --route 'sip:.*=modem:'
--sip-register 91@127.0.0.1:5061,password

I tried it with a global IP (instead of 127.0.0.1) - same behavior.

The point is, that the receiving part, which initiates the t.38 switch,
doesn't sent the switch to the ISP. It is blocked / ignored by asterisk
at all - don't know why it isn't sent to the ISP.

The extension is a normal pjsip extension with these additional options:


 t38_udptl  : true
 t38_udptl_ec   : redundancy
 t38_udptl_ipv6 : false
 t38_udptl_maxdatagram  : 400
 t38_udptl_nat  : no (or yes - doesn't matter)


The trunk looks exactly the same:

 t38_udptl  : true
 t38_udptl_ec   : redundancy
 t38_udptl_ipv6 : false
 t38_udptl_maxdatagram  : 400
 t38_udptl_nat  : no (or yes - doesn't matter)



Thanks,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'

[Michael Maier]

Hello!

I'm still trying to get a working t.38 configuration w/ pjsip.

I'm now able to send t.38 faxes to my own extension:


hylafax -> t38modem -> extension -> extension -> t38modem -> hylafax.


The fax is sent by t38modem. The receiving part of t38modem accepts the
call, sends ReInvite for t.38 and things are working as expected.



Now, let's do the nearly same thing, but use an ISP:

hylafax -> t38modem -> extension -> trunk -> ISP ->
trunk -> extension -> t39modem(2) -> hylafax


Same procedure: the receiving t38modem(2) sends ReInvite for t.38 - but
this time, the extension / asterisk just ignores it. After the 5. retry
to switch to T.38, asterisk tells:

res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38
request on channel 'PJSIP/91-0007'

=> Why does asterisk reject the switch / ReInvite to T.38 this time? It
never even tried to send it to the ISP!


Thanks for any hint!

Regards,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] pjsip: asterisk can't decide which codec to use

[Michael Maier]

On 05/12/2017 at 08:49 PM, Joshua Colp wrote:
> On Fri, May 12, 2017, at 02:46 PM, Michael Maier wrote:
> 
> 
> 
>>
>> If I'm doing exactly the same call originated with another extension,
>> there can't be seen these frequent changes. But the strange thing is,
>> that in both cases the part between extension and asterisk doesn't show
>> any codec changes ... .
>>
>> Deeper investigations show, that if the conference (callee) sends the
>> first rtp package (-> g711 - should be g722), things are going choppy, 
>> if the extension (caller) sends the first package (g722), things are 
>> running stable.
>>
>>
>> Any idea to convince asterisk always to use the first codec of ok sdp 
>> or how to convince asterisk to put only one codec to ok sdp (the first).
> 
> This is not currently an option in chan_pjsip but I'd suggest filing an
> issue[1] for this scenario with all available information.
> 
> [1] https://issues.asterisk.org/jira

https://issues.asterisk.org/jira/browse/ASTERISK-26996


Thanks,
regards,
Michael


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] pjsip: asterisk can't decide which codec to use

[Michael Maier]

On 05/12/2017 at 07:46 PM, Michael Maier wrote:

Forgot to mention: It's actual asterisk 13 branch from today (version 
before I tested, which has the same problem, was 13.15).



Regards,
Michael



Hello!

I'm facing completely choppy sound. The wireshark trace shows, that
there are a lot of codec changes without any trigger (means no options
or reinvite or any other package).

Background:
The call is initiated by asterisk and is received by the same asterisk
conference room via
Phone extension ->  asterisk -> provider A -> provider B -> asterisk.

Asterisk initially sends invites using g722 and g711 and gets exactly
this invite back as incoming call. The answer is g722,g711 in the ok sdp.

Now, Asterisk can't decide, which codec to use. It frequently changes
the codec just as it likes to apparently without any visible reason.

[2017-05-11 17:28:03] DEBUG[5121][C-003a]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from none to alaw

[2017-05-11 17:28:03] DEBUG[5113][C-0039]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from none to alaw
[2017-05-11 17:28:04] DEBUG[5123][C-0039]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from none to alaw
[2017-05-11 17:28:04] DEBUG[5113][C-0039]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from alaw to g722

[2017-05-11 17:28:04] DEBUG[5121][C-003a]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from alaw to g722
[2017-05-11 17:28:04] DEBUG[5121][C-003a]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from g722 to alaw
[2017-05-11 17:28:13] DEBUG[5121][C-003a]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from alaw to g722
[2017-05-11 17:28:13] DEBUG[5121][C-003a]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from g722 to alaw
[2017-05-11 17:28:19] DEBUG[5121][C-003a]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from alaw to g722
[2017-05-11 17:28:19] DEBUG[5121][C-003a]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from g722 to alaw
[2017-05-11 17:28:23] DEBUG[5121][C-003a]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from alaw to g722
[2017-05-11 17:28:23] DEBUG[5121][C-003a]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from g722 to alaw

[2017-05-11 17:28:23] DEBUG[5123][C-0039]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from alaw to g722

[2017-05-11 17:28:23] DEBUG[5121][C-003a]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from alaw to g722
[2017-05-11 17:28:28] DEBUG[5121][C-003a]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from g722 to alaw

[2017-05-11 17:28:28] DEBUG[5123][C-0039]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from g722 to alaw

003a -> inbound channel (callee)
0039 -> outbound channel (caller)


If I'm doing exactly the same call originated with another extension,
there can't be seen these frequent changes. But the strange thing is,
that in both cases the part between extension and asterisk doesn't show
any codec changes ... .

Deeper investigations show, that if the conference (callee) sends the
first rtp package (-> g711 - should be g722), things are going choppy,
if the extension (caller) sends the first package (g722), things are
running stable.


Any idea to convince asterisk always to use the first codec of ok sdp
or how to convince asterisk to put only one codec to ok sdp (the first).



Thanks,
regards,
Michael




--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] pjsip: asterisk can't decide which codec to use

[Michael Maier]

Hello!

I'm facing completely choppy sound. The wireshark trace shows, that
there are a lot of codec changes without any trigger (means no options
or reinvite or any other package).

Background:
The call is initiated by asterisk and is received by the same asterisk
conference room via
Phone extension ->  asterisk -> provider A -> provider B -> asterisk.

Asterisk initially sends invites using g722 and g711 and gets exactly
this invite back as incoming call. The answer is g722,g711 in the ok sdp.

Now, Asterisk can't decide, which codec to use. It frequently changes
the codec just as it likes to apparently without any visible reason.

[2017-05-11 17:28:03] DEBUG[5121][C-003a]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from none to alaw

[2017-05-11 17:28:03] DEBUG[5113][C-0039]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from none to alaw
[2017-05-11 17:28:04] DEBUG[5123][C-0039]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from none to alaw
[2017-05-11 17:28:04] DEBUG[5113][C-0039]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from alaw to g722

[2017-05-11 17:28:04] DEBUG[5121][C-003a]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from alaw to g722
[2017-05-11 17:28:04] DEBUG[5121][C-003a]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from g722 to alaw
[2017-05-11 17:28:13] DEBUG[5121][C-003a]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from alaw to g722
[2017-05-11 17:28:13] DEBUG[5121][C-003a]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from g722 to alaw
[2017-05-11 17:28:19] DEBUG[5121][C-003a]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from alaw to g722
[2017-05-11 17:28:19] DEBUG[5121][C-003a]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from g722 to alaw
[2017-05-11 17:28:23] DEBUG[5121][C-003a]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from alaw to g722
[2017-05-11 17:28:23] DEBUG[5121][C-003a]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from g722 to alaw

[2017-05-11 17:28:23] DEBUG[5123][C-0039]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from alaw to g722

[2017-05-11 17:28:23] DEBUG[5121][C-003a]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from alaw to g722
[2017-05-11 17:28:28] DEBUG[5121][C-003a]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from g722 to alaw

[2017-05-11 17:28:28] DEBUG[5123][C-0039]: res_rtp_asterisk.c:3634 
ast_rtp_write: Ooh, format changed from g722 to alaw

003a -> inbound channel (callee)
0039 -> outbound channel (caller)


If I'm doing exactly the same call originated with another extension,
there can't be seen these frequent changes. But the strange thing is,
that in both cases the part between extension and asterisk doesn't show
any codec changes ... .

Deeper investigations show, that if the conference (callee) sends the
first rtp package (-> g711 - should be g722), things are going choppy, 
if the extension (caller) sends the first package (g722), things are 
running stable.


Any idea to convince asterisk always to use the first codec of ok sdp 
or how to convince asterisk to put only one codec to ok sdp (the first).



Thanks,
regards,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] Some questions regarding jitterbuffer in asterisk / pjsip

[Michael Maier]

Hello!

I just implemented a jitterbuffer for pjsip in the dialplan in a SBC:

[fromtrunk]
exten => _[+0-9]!,1,Set(JITTERBUFFER(fixed)=default)


This jitterbuffer catches all calls coming from ISP.

My understanding is, that the incoming rtp stream in leg1a is now
buffered and handed out "jitter-optimized" to leg2a on the other site
(this could be internal or external again).

---> leg1a  leg2a >
ISP SBC callee
<--- leg1b  leg2b <


My question: What's about the rtp stream which is received by leg1b from
callee? Is there a receive buffer on the leg1b-site, too? Or is it
expected to be done by leg2b before handing it out to leg1b?

Iow: is it enough to implement one jitterbuffer? Or should there be a
second jitterbuffer on the side of leg2?



Thanks for clarification!
Regards,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Outbound T.38 via RTP with pjsip does not work as expected

[Michael Maier]

On 04/06/2017 at 08:33 PM Joshua Colp wrote:
> On Thu, Apr 6, 2017, at 03:15 PM, Michael Maier wrote:
>> Hello!
>>
>> I'm trying to send a fax via T.38 to a destination, which should be T.38
>> capable. My provider supports T.38, too. Unfortunately, it doesn't work.
>> This means:
>>
>> Call is started and SDP is negotiated w/ alaw. Callee sends reinvite -
>> for alaw again (and not for T.38)!! After about 30s, callee hangs up
>> because of missing data (this is true, because I don't send alaw coded
>> fax data.
>>
>> Tracing the signaling shows, that the callee doesn't have any
>> possibility to recognize, if I'm supporting T.38, because it is never
>> sent during Invite process.
>>
>> I'm missing the media feature tag sip.fax in the contact header. Did I
>> miss some configuration?
> 
> This is not currently supported in either chan_sip or chan_pjsip.
> There's no configuration which will enable it. It would need to be
> written. Have you confirmed this is what is needed by them?

It turned out, that there is a  third provider in between, which doesn't
support T.38 ... .


Thanks,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Outbound T.38 via RTP with pjsip does not work as expected

[Michael Maier]

On 04/06/2017 at 08:33 PM, Joshua Colp wrote:
> On Thu, Apr 6, 2017, at 03:15 PM, Michael Maier wrote:
>> Hello!
>>
>> I'm trying to send a fax via T.38 to a destination, which should be T.38
>> capable. My provider supports T.38, too. Unfortunately, it doesn't work.
>> This means:
>>
>> Call is started and SDP is negotiated w/ alaw. Callee sends reinvite -
>> for alaw again (and not for T.38)!! After about 30s, callee hangs up
>> because of missing data (this is true, because I don't send alaw coded
>> fax data.
>>
>> Tracing the signaling shows, that the callee doesn't have any
>> possibility to recognize, if I'm supporting T.38, because it is never
>> sent during Invite process.
>>
>> I'm missing the media feature tag sip.fax in the contact header. Did I
>> miss some configuration?
> 
> This is not currently supported in either chan_sip or chan_pjsip.
> There's no configuration which will enable it. It would need to be
> written. Have you confirmed this is what is needed by them?

No - I have to confirm it. But this may take some time :-).


Thanks,
Michaal

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] Outbound T.38 via RTP with pjsip does not work as expected

[Michael Maier]

Hello!

I'm trying to send a fax via T.38 to a destination, which should be T.38
capable. My provider supports T.38, too. Unfortunately, it doesn't work.
This means:

Call is started and SDP is negotiated w/ alaw. Callee sends reinvite -
for alaw again (and not for T.38)!! After about 30s, callee hangs up
because of missing data (this is true, because I don't send alaw coded
fax data.

Tracing the signaling shows, that the callee doesn't have any
possibility to recognize, if I'm supporting T.38, because it is never
sent during Invite process.

I'm missing the media feature tag sip.fax in the contact header. Did I
miss some configuration?

That's my setup:
Hylafax sends fax to t38modem and t38modem is connected via SIP to
asterisk as extension. The extension is bound to an outbound route,
which uses the t.38 capable ISP.

pjsip.endpoint.conf:

[ISP]
t38_udptl=yes
t38_udptl_nat=no # there is no nat necessary
t38_udptl_ec=fec

[t38endpoint]
t38_udptl=yes
t38_udptl_ec=fec


Any idea?


Thanks,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Asterisk 13.13.1

[Michael Maier]

On 01/30/2017 at 05:55 PM Motty Cruz wrote:
> Fresh installed CentOS 7.3 and Asterisk 13.13.1. Download Asterisk from here: 
> http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-13-current.tar.gz
>
> 
>  
> 
> I continue to see errors like this: 
> 
> [2017-01-30 08:37:17] WARNING[2332]: chan_sip.c:4061 retrans_pkt: 
> Retransmission timeout reached on transmission 
> 56849706-ba96a6d9-817305d0@192.168.125.173 for seqno 109 (Critical Request) 
> -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
> 
> Packet timed out after 32000ms with no response
> 
> [2017-01-30 08:37:17] WARNING[2332]: chan_sip.c:4061 retrans_pkt: 
> Retransmission timeout reached on transmission 
> 6e3dd238-911e2ac3-f1260152@192.168.125.152 for seqno 103 (Critical Request) 
> -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
> 
> Packet timed out after 32000ms with no response
> 
> [2017-01-30 08:37:17] WARNING[2332]: chan_sip.c:4061 retrans_pkt: 
> Retransmission timeout reached on transmission 
> ed38f9c8-295a9db-c23f5242@192.168.125.144 for seqno 103 (Critical Request) -- 
> See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
> 
> Packet timed out after 32000ms with no response
> 
> [2017-01-30 08:37:17] WARNING[2332]: chan_sip.c:4061 retrans_pkt: 
> Retransmission timeout reached on transmission 
> ef497d11-a81b1c00-8bfbd3bf@192.168.1.244 for seqno 103 (Critical Request) -- 
> See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
> 
>  
> 
> Before upgrading to this new server, Asterisk version 1.8 on  CentOS 5.9 
> hardware on both servers were similar in CPU, Memory 
> 
>  
> 
> Any support on this matter is appreciated!

Did you setup tcpdump (behind the machine) to see, if the packets really
leave the machine? Can you see any answer?


Regards,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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