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-17 Thread Joshua Colp 
On Sat, Jun 17, 2017, at 09:18 AM, Michael Maier wrote:



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

Nope, I don't really have anything to add to try to make it communicate.
T.38 support over all can be very problematic depending on the endpoint.

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

-- 
_
-- 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-17 Thread Marcelo Terres 
Yes, let's stop to use our gmail accounts because JUST THE DIGIUM
MAILING LIST is bouncing.

All other mailman servers must be wrongly configured, and the Digium
server is the only one that is correct. Perfect!

:-D
Marcelo H. Terres 
IM: mhter...@jabber.mundoopensource.com.br
https://www.mundoopensource.com.br
https://twitter.com/mhterres
https://linkedin.com/in/marceloterres


On 16 June 2017 at 22:37, James B. Byrne  wrote:
>
> On Fri, June 16, 2017 12:28, Tim S wrote:
>
> Whether it is intentional or not these messages railing against the
> list operators has a decided tone of condescension which is not
> warranted.  The fact of the matter is that DMARC is broken by design
> and the unpleasant effects that adoption of it has on mailing-list
> traffic were well hashed out on the ITEF mailing lists before it was
> adopted anyway.  What was predicted there has come to pass.
>
> DMARC conflicts with the existing SMTP RFCs in several ways, none of
> which I will elaborate here but all of which may be discovered by
> perusing the relevant threads on the ITEF mailing lists.  Some mailing
> list management software, notably Mailman, since has been modified to
> 'work around' the problems with DMARC if so configured by the list
> owners.  But only at the cost of violating the SMTP RFCs themselves.
> Do not take my word for it.  Raise these issues on the Postfix mailing
> list and discover what response you get from Viktor and Wietse.
>
> The driving force behind DMARC was YAHOO's shoddy security of their
> own users' accounts.  With Hotmail and similar ilk close behind. It is
> a completely inappropriate, and in my opinion ill-thought-out,
> technical solution to what is essentially an internal security problem
> at some email providers, albeit very large ones.  In general it is an
> example of what is called 'externalising your costs'.
>
> The appropriate answer has been provided: lose the
> gmail/hotmail/yahoo/freemail account and administer your own domain
> for personal email. Configure the spf and dkim settings on your own
> domain as required to suit your needs and not those of someone else.
>
> --
> ***  e-Mail is NOT a SECURE channel  ***
> Do NOT transmit sensitive data via e-Mail
>  Do NOT open attachments nor follow links sent by e-Mail
>
> James B. Byrnemailto:byrn...@harte-lyne.ca
> Harte & Lyne Limited  http://www.harte-lyne.ca
> 9 Brockley Drive  vox: +1 905 561 1241
> Hamilton, Ontario fax: +1 905 561 0757
> Canada  L8E 3C3
>
>
> --
> _
> -- 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

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-17 Thread 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