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'

[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] 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] asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'

[Joshua Colp]

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.

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

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

-- 
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] 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: 
> ;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] 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: ;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 

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'

[Joshua Colp]

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.

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

[Joshua Colp]

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.

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

[Daniel Tryba]

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.

# T.38 dial modifiers
#
# F - enable T.38 mode request after dialing
# V - disable T.38 mode request after dialing (remote host should do it)
#
# calling/called number dial modifiers
#
# L - reset and begin of calling number
# D - continue of called number
#
ModemDialCmd:   ATDF%s  # user can override F by dial V
#ModemDialCmd:  ATDV%s  # user can override V by dial F
#ModemDialCmd:  ATD%sF  # user can't override F
#ModemDialCmd:  ATD%sV  # user can't override V
#ModemDialCmd:  ATD%sVL # user can't override V or calling 
number


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

[Joshua Colp]

On Sun, Jun 11, 2017, at 01:47 PM, Joshua Colp wrote:
> On Sun, Jun 11, 2017, at 01:31 PM, Michael Maier wrote:
> > 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?
> 
> 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).

-- 
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] asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'

[Joshua Colp]

On Sun, Jun 11, 2017, at 01:31 PM, Michael Maier wrote:
> 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?

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.

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

[Joshua Colp]

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.

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

[Joshua Colp]

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

-- 
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] 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: ;tag=124E09F9-593D01CC00045378-134F4700
To: 
;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: 

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'
[2017-06-11 10:39:42] DEBUG[25822]: res_pjsip_session.c:971 
ast_sip_session_refresh: Sending session refresh SDP via re-INVITE to 91
[2017-06-11 10:39:42] DEBUG[25822]: res_pjsip_session.c:2501 

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'

[Joshua Colp]

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

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

[Joshua Colp]

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.

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

[Joshua Colp]

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. I'd suggest filing an
issue[1] with all the logs and such, it'll allow whomever works on the
issue to write a specific testsuite test and hopefully recreate it in a
controlled environment.

[1] https://issues.asterisk.org/jira

-- 
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] 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   :
 named_pickup_group :
 one_touch_recording: false
 outbound_auth  : easybellPJSIP_FAX
 outbound_proxy :
 pickup_group   :
 record_off_feature : automixmon
 record_on_feature  : automixmon
 rewrite_contact: false
 

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'

[Joshua Colp]

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?

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

[Joshua Colp]

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.

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

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'

[Telium Technical Support]

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

-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Michael Maier
Sent: Sunday, June 4, 2017 3:39 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
<asterisk-users@lists.digium.com>
Subject: [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-0007'

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


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