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'

2017-06-15 Thread 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: 
> ;tag=72F0675F-5942027B00075955-FB9F9700
> To: 
> ;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: 
> 
> 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

Re: [asterisk-users] Is this the future of telephony?

2017-06-15 Thread Bruce Ferrell 

What might be good to consider is that "traditional" telcos actually use VOIP 
tech on the back end a lot.

SIP URIs seem to be a kewl and ubiquitous solution, but for the average joe, 
not so easy to setup and use.

And for the record, I consider wireless carriers as traditional telcos as well 
as wireline carriers.


On 06/15/2017 05:56 PM, Christopher van de Sande wrote:

Hey, so not particularly asterisk related, but I think the people on
this list are the right bunch to ask.

So does anyone here think the traditional telephone company will go
extinct, and voice communication will take place via email like (or
equal to) sip uri's?

I just setup an anonymous endpoint in pjsip.conf and a context that
forwards to $EXTEN and when I setup the correct SRV records, it seems
that any SIP client that's smart enough can just dial my SIP/email
address.  Is this what the future looks like?







--
_
-- 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] Is this the future of telephony?

2017-06-15 Thread Christopher van de Sande 

Hey, so not particularly asterisk related, but I think the people on
this list are the right bunch to ask.

So does anyone here think the traditional telephone company will go
extinct, and voice communication will take place via email like (or
equal to) sip uri's?

I just setup an anonymous endpoint in pjsip.conf and a context that
forwards to $EXTEN and when I setup the correct SRV records, it seems
that any SIP client that's smart enough can just dial my SIP/email
address.  Is this what the future looks like?




signature.asc
Description: OpenPGP digital signature
-- 
_
-- 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] OT: Explain where mailing list bouncing comes from ?

2017-06-15 Thread Tim S 
Another "me too" (also Gmail).

 I just received my 4th "account suspended, too many bounces" email,
after having several days of lost mailing list content over a short
vacation break the last time.  When I notified the admin email account of
the failure, it seemed the responder missed the point about the emails,
saying the link had expired (it had been more than three days since I had
checked Gmail) - not seeming to notice that there was a problem with users
having errant email bounce account suspensions.

Whatever has been done, if anything, isn't working effectively.  At this
point I'd like to see some response from the mailing list admin about any
root-cause efforts, AFAIC this is starting to smear the Digium/Asterisk
brand's ability to handle IT related issues...  No response = no confidence
vote.

-Tim


On Tue, Jun 13, 2017 at 7:04 AM, Patrick L Archibald (PLA) ☮  <
patrick.archib...@gmail.com> wrote:

> Me too. Also gmail.
> R☮ck on, PLA
>
> Patrick L Archibald
> http://PatrickArchibald.com
>
>
> On Mon, Jun 12, 2017 at 4:26 AM, Jonathan H 
> wrote:
> > Me too, also gmail. I emailed the list owner a couple of days ago, but
> no reply.
> >
> > Is everyone else affected also forwarding to another email address
> > (gmail or not)?
> >
> > Could be wrong, but I'm guessing there may be an incorrect DMARC
> > policy somewhere - although this is the only fail I could find in the
> > headers.
> >
> > boun...@lists.digium.com;
> >dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=gmail.com
> >
> >
> >
> > On 12 June 2017 at 09:12, Steve Davies  wrote:
> >> I am also getting this, three or four times in the last month after
> years of
> >> no problems.
> >>
> >> I agree that Gmail is the likely common factor, but I would love to have
> >> access to these bounce messages to know whether it is actually an
> >> overly-paranoid list server!
> >>
> >> Steve
> >>
> >> On Mon, 12 Jun 2017 at 09:09 Andrew Furey 
> wrote:
> >>>
> >>> Ditto; a Gmail issue?
> >>>
> >>> Andrew
> >>>
> >>> On 12 June 2017 at 16:00, Marcelo Terres  wrote:
> 
>  It is happening the same with me.
> 
>  Regards,
>  Marcelo H. Terres 
>  IM: mhter...@jabber.mundoopensource.com.br
>  https://www.mundoopensource.com.br
>  https://twitter.com/mhterres
>  https://linkedin.com/in/marceloterres
> 
> 
>  On 12 June 2017 at 08:07, Olivier  wrote:
>  > Hello,
>  >
>  > I'm a faithful reader of this mailing list, for several years now.
>  >
>  > Lately, I'm receiving emails asking me to re-enable my list
>  > subscription due
>  > to "excessive bouncing".
>  >
>  > What does this exactly mean and why am I receiving this ?
>  > Beside re-enabling my subscription, what can I do to improve things
> ?
>  >
>  > Regards
>  >
>  > --
>  > 
> _
>  > -- 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
> 
>  --
>  _
>  -- 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
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Linux supports the notion of a command line or a shell for the same
> >>> reason that only children read books with only pictures in them.
> >>> Language, be it English or something else, is the only tool flexible
> >>> enough to accomplish a sufficiently broad range of tasks.
> >>>   -- Bill Garrett
> >>> --
> >>> _
> >>> -- 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 1.6.2 how to debug T.38 udptl problems

2017-06-15 Thread Daniel Tryba 
On Thu, Jun 15, 2017 at 12:11:36PM +0200, Benoit Panizzon wrote:
> Or does anyone have an idea over what the asterisk is stumbling?

What if you set the maxdata in asterisk to a value lower than the other
side? e.g. sip.conf: 
t38pt_udptl = yes,fec,maxdatagram=400

-- 
_
-- 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 1.6.2 how to debug T.38 udptl problems

2017-06-15 Thread Benoit Panizzon 
Hi all

I know, a fairly old asterisk installation.

Is there any way to debug T.38 handshaking issues?

We have a C3 Voice Switch with link to the Asterisk server.

I see this Dialogue:

C3 => Asterisk
=> Invite g711
<= 200OK

C3 detects Fax and send re-invite

=> Invite T.38
Version:0
RateManagement:transferredTCF
MaxDatagram:512

So, this is only a very basic invite.

The Asterisk picks that up and replies with details:

<= 200 OK + SDP T.38

Version:0
BaxBitRate:14400
RateManagement:transferredTCF
MAxDatagramm:1400
UdpEC:t38UDPFEC

The C3 Switch then compares this whith it's capabilities and answers
with one more re-invite:

=> Invite + SDP T.38

Version:0
RateManagement:trasferredTCF
UdpEC:t38UDPFEC
MaxBitRate:14400
MaxDatagramm:512

Well so the C3 just tells the asterisk, that it only support 512 byte
datagramm, but everything else is the same.

The Asterisk replies to this invite with:

488 Not acceptable here.

Now I would like to find out what is not acceptable for the asterisk.

core set verbose 99 and debug 99 does not show any futher information.
udptl set debug on neither.

Any other way to debug the T.38 handshake?

Or does anyone have an idea over what the asterisk is stumbling?

-- 
-Benoît Panizzon-
-- 
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__

-- 
_
-- 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'

2017-06-15 Thread 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: ;tag=72F0675F-5942027B00075955-FB9F9700
To: 
;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: 

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_technology: Bridge technology softmix does not have any capabilities 
we want.
[2017-06-15 07:43:57] DEBUG[25198][C-0004]: bridge.c:496 
find_best_technology: Bridge