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

On Fri, Jun 16, 2017, at 10:49 AM, Michael Maier wrote:

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

On 06/16/2017 at 04:00 PM, Joshua Colp wrote:
> On Fri, Jun 16, 2017, at 10:49 AM, Michael Maier wrote:
> 
> <snip>
> 
>>
>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: opal-UDPTL.patch
Type: text/x-patch
Size: 960 bytes
Desc: not available
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20170617/d005a53d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asterisk-t38.UDPTL.patch
Type: text/x-patch
Size: 565 bytes
Desc: not available
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20170617/d005a53d/attachment-0001.bin>

On Sat, Jun 17, 2017, at 09:18 AM, Michael Maier wrote:

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

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