Joshua Colp
2017-Jun-05 16:29 UTC
[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'
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
Michael Maier
2017-Jun-05 19:26 UTC
[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'
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-00000003 [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-00000003' [2017-06-05 20:52:24] DEBUG[719]: res_pjsip_t38.c:696 defer_incoming_sdp_stream: Deferring incoming SDP stream on PJSIP/91-00000003 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-00000003' [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-00000003' [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-00000003' [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
Joshua Colp
2017-Jun-05 19:32 UTC
[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'
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
Possibly Parallel Threads
- asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'
- asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'
- Parking in Asterisk 12.0.0
- Sporadic duplicate requests with lpxelinux.0
- sparseM and kronecker product_R latest version