search for: res_pjsip_t38

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

...afax -> 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-00000007' => 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

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

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

On 06/14/2017 at 05:53 PM Joshua Colp wrote: > On Wed, Jun 14, 2017, at 12:47 PM, Michael Maier wrote: > > <snip> > >> >> 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.000000000 >> +0200 >> +++

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

..._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-00000009 [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-00000009' [2017-06-15 07:43:57] DEBUG[2517...

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

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

On Sun, Jun 11, 2017, at 11:34 AM, Michael Maier wrote: <snip> > > > > 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

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

On Sun, Jun 11, 2017, at 08:16 AM, Michael Maier wrote: <snip> > 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

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

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)

...so res_pjsip_pidf_eyebeam_body_supplement.so res_pjsip_publish_asterisk.so res_pjsip_pubsub.so res_pjsip_refer.so res_pjsip_registrar_expire.so res_pjsip_registrar.so res_pjsip_rfc3326.so res_pjsip_sdp_rtp.so res_pjsip_send_to_voicemail.so res_pjsip_session.so res_pjsip_sips_contact.so res_pjsip.so res_pjsip_t38.so res_pjsip_transport_management.so res_pjsip_transport_websocket.so res_pjsip_xpidf_body_generator.so Asterisk CLI : [Aug 14 12:02:32] WARNING[20712]: loader.c:599 load_dynamic_module: Error loading module 'res_pjsip_registrar.so': /usr/lib64/asterisk/modules/res_pjsip_registrar.so:...

..._pjsip_rfc3326: A lot of endpoints do not correctly handle two Reason headers (Reported by Ross Beer) * ASTERISK-27763 - res_pjsip_session: Initial INVITE with audio+fax results in 488 instead of declining stream (Reported by Thiago Coutinho) * ASTERISK-27657 - res_pjsip_t38: ATA fails with hangupcause 58(Bearer capability not available) (Reported by Jared Hull) * ASTERISK-27080 - res_pjsip_t38: Slow T.38 re-invite rejection if remote leg has T.38 disabled (Reported by Torrey Searle) * ASTERISK-26686 - res_pjsip: Lock inversion in...

...anuel BUU) * ASTERISK-27881 - PBX calls via chan_sip TCP trunk now get authentification error (Reported by Ian Gilmour) * ASTERISK-28011 - chan_sip: get_refer_info() attempted unlock mutex 'peer' without owning it! (Reported by Alec Davis) * ASTERISK-27944 - res_pjsip_t38: Crash receiving 1xx responses other than 100 before 200 for T.38 reINVITE (Reported by Joshua Elson) * ASTERISK-28007 - rtcp-mux is put in SDP answer regardless of offer (Reported by Torrey Searle) * ASTERISK-27398 - No joint capabilities with video and audio-...

...\001<h\025\220", <incomplete sequence \365>, src=0x20, size=1025) at res_pjsip.c:4147 #1 0x00007fb9f0b02334 in negotiate_incoming_sdp_stream (session=0x7fba3c031200, session_media=<value optimized out>, sdp=<value optimized out>, stream=<value optimized out>) at res_pjsip_t38.c:703 #2 0x00007fba0499ccf6 in handle_incoming_sdp (session=0x7fba3c031200, sdp=0x7fba3c0adfb8) at res_pjsip_session.c:243 #3 0x00007fba0499e650 in session_inv_on_rx_offer (inv=0x7fba3c0504e8, offer=0x7fba3c0adfb8) at res_pjsip_session.c:3009 #4 0x00007fba44b1b501 in inv_check_sdp_in_incoming_ms...

...Description When Asterisk sends a re-invite initiating T.38 faxing, and the endpoint responds with a declined media stream a crash will then occur in Asterisk. Modules Affected res_pjsip_t38.c Resolution If T.38 faxing is not required then setting the “t38_udptl” configuration option on the endpoint to “no” disables this functionality. This option defaults to “no” so you have to ha...

...Description If Asterisk receives a re-invite initiating T.38 faxing and has a port of 0 and no c line in the SDP, a crash will occur. Modules Affected res_pjsip_t38.c Resolution If T.38 faxing is not needed, then the “t38_udptl” configuration option in pjsip.conf can be set to “no” to disable the functionality. This option automatically de...