similar to: pjsip: Inbound calls: selecting the correct trunk with one provider and different numbers

Displaying 20 results from an estimated 7000 matches similar to: "pjsip: Inbound calls: selecting the correct trunk with one provider and different numbers"

2017 Jun 08
3
pjsip: Inbound calls: selecting the correct trunk with one provider and different numbers
Hello Joshua, thank you very much for your extremely quick answer! I really appreciate your work and your friendly and your patient support! On 06/07/2017 at 10:33 PM, Joshua Colp wrote: > On Wed, Jun 7, 2017, at 05:28 PM, Michael Maier wrote: >> Hello! >> >> I've got a problem to select the correct trunk if there is one provider >> and different numbers with
2017 Jun 05
3
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 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)
2017 Jun 11
3
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 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
2017 Jun 16
3
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
2017 Jun 05
2
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 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
2017 Jun 05
2
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
2017 Jun 11
2
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 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
2017 Jun 16
2
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 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
2017 May 13
2
pjsip: asterisk can't decide which codec to use
On 05/12/2017 at 08:49 PM, Joshua Colp wrote: > On Fri, May 12, 2017, at 02:46 PM, Michael Maier wrote: > > <snip> > >> >> If I'm doing exactly the same call originated with another extension, >> there can't be seen these frequent changes. But the strange thing is, >> that in both cases the part between extension and asterisk doesn't show
2016 May 12
2
[asterisk 13.9] pjsip: Extensions always lost after short period of time
Hello! Today, I tried to switch from asterisk 13.7.2 to 13.9, but I'm getting strange problem w/ the registering of all of my extensions. It looks like that: [2016-05-12 08:59:38] VERBOSE[2332] res_pjsip/pjsip_configuration.c: Contact 107/sip:107 at 192.168.15.73:5060 has been created [2016-05-12 08:59:38] VERBOSE[2272] res_pjsip_registrar.c: Added contact 'sip:107 at
2017 Apr 06
3
Outbound T.38 via RTP with pjsip does not work as expected
Hello! I'm trying to send a fax via T.38 to a destination, which should be T.38 capable. My provider supports T.38, too. Unfortunately, it doesn't work. This means: Call is started and SDP is negotiated w/ alaw. Callee sends reinvite - for alaw again (and not for T.38)!! After about 30s, callee hangs up because of missing data (this is true, because I don't send alaw coded fax data.
2017 Jun 11
2
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 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
2017 Jun 04
2
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/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
2018 Dec 27
2
Voice mail: MWI problem / pjsip (13.24.0)
Hi! I just want to say, that 13.24.1 doesn't fix the problem described in the posts above. Regards, Michael
2016 Jun 05
3
pjsip: occasional sip_transactio Unable to register REGISTER transaction (key exists)
Hello! I occasionally can see warnings like these during *idle* times in asterisk log (asterisk 13.7.2): [2016-06-05 06:11:51] WARNING[27817] pjsip: sip_transactio Unable to register REGISTER transaction (key xists) [2016-06-05 06:11:51] WARNING[27817] pjsip: sip_transactio Unable to register REGISTER transaction (key exists) Nothing more. The third REGISTER package works as expected.
2017 Jun 14
2
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/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
2017 Jun 05
3
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
2017 Nov 01
3
asterisk 13.18.0: pjsip: unnecessary 603 decline because of wrong codec decision
Hello! I'm facing the following scenario: - Initial call opened to asterisk: SDP g722,alaw,ulaw - Outgoing call to provider started with Invite / SDP alaw, g726 and g729. - Provider sends 183 Session progress SDP: g729, alaw - Provider sends g729 rtp packages But: there is no license to transcode g729. What is asterisk doing? Asterisk decides to stop the call at all: - Sends cancel
2017 May 12
3
pjsip: asterisk can't decide which codec to use
Hello! I'm facing completely choppy sound. The wireshark trace shows, that there are a lot of codec changes without any trigger (means no options or reinvite or any other package). Background: The call is initiated by asterisk and is received by the same asterisk conference room via Phone extension -> asterisk -> provider A -> provider B -> asterisk. Asterisk initially sends
2010 Aug 17
1
MySQL Connect problem...
Right, I'm baffled. I have: exten => s,1,MYSQL(Connect DB1 127.0.0.1 geraint xxx amis2) exten => s,n,MYSQL(Query NORESULT ${DB1} INSERT\ INTO\ recordings\ (caller_number\,called_number\,date_created\,date_started\,in_use\,server_id)\ VALUES\ (\'${CALLERID(number)}\'\,\'${ARG1}\'\,NOW()\,NOW()\,\'Yes\'\,12)) exten => s,n,MYSQL(Query RESULT1 ${DB1} SELECT\