similar to: Possible handle leak in PJSIP

Hi, We're holding ourselves back from moving to PJSIP as we don't appear to have figured out how to force codec preference in a dial plan. The 'PJSIP Advanced Codec Negotiation' document (https://wiki.asterisk.org/wiki/display/AST/PJSIP+Advanced+Codec+Negotiation) appears to ultimately be what we're after, but we're not comfortable running Asterisk 18 in production just

Hi, I am trying to find a way to add the following info in CDRs (with asterisk 1.4.23.1): 1. Codec used 2. RTP QoS statistics 3. RTP IP of remote host 4. For answered calls, the peer that requested to end the conversation I have managed to get 1 and 2 for the caller, like that: exten => h,1,Set(CDR(userfield)=RIP=${SIPCHANINFO(recvip)}

Hello list, Grandstream GXP2010 phone calling to Snom 320, Asterisk in the middle. Grandstream allows for 8 different codec specifications. I have defined them as 4 x G726 & 4 x alaw. Snom allow for 7 different codec specifications. I have defined them as 3 x G726 & 4 x G729. The SIP peers are both defined as : disallow=all allow=g726 allow=alaw allow=g729 allow=gsm This is the

Hi, Is there a variable that contains the Sip Peer name? I was using ${CALLERID(num)} for outgoing calls, but when a call is being transferred, that variable contains something else. I need a variable that is always set to the SIP Peer's name. Thanks Dan -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello, I finally got to look at chan_sip to chan_pjsip migration again. This time I’m having problems with influencing codec selection on originating (calling) channel. It looks like PJSIP_MEDIA_OFFER only works on outbound (called) channel and has no affect on calling channel. My experiments and function documentation (which says “Media and codec offerings to be set on an outbound SIP

Hello, Anyone? I have hard time to believe this is not possible with chan_pjsip. Anyway, may I ask how people handle the following scenario which I imagine should be quite common: - I have internal extensions talk to each other using g722. so their codec setting (with chan_sip now) is "allow=g722,ulaw" - I have carriers trunks that handle ulaw only (allow=ulaw) - calls between

Hi, I had tried all the steps which I used to inatall Asterisk 12.3.2 Pjsip in Asterisk 12.3.2 is working but in new release Asterisk 12.4.0 it is not working I am getting XXX in make menuselect resource_module. I tried all trouble shooting steps along with ldconfig etc. I think its a bug can any one help me on this ? -- Regards Sameer Rathod 8109413462 -------------- next part

Hi: I am useing asterisk 11.12. I use G722 as preferred codec for my ip-phone. and my PSTN DAHDI use alaw. G722 is great when ip-phone talks to each other. but when ip-phone dialout to PSTN DAHDI, G722 is not great, since it is need to transcode to alaw. so I try to change the codec when dial from SIP to DAHDI. I tried to use IP_CODEC/SIP_CODEC_OUTBOUND at dialplan. but the SIP

Hi, after update on 12.4.0 asterisk crashes on MeetMe ending on 12.3.2 it worked well. Is some one else have this issues? should someone open a ticket?

I downloaded asterisk-12.4.0 (asterisk-12-current.tar.gz, dated 10-JUL_2014) from http://downloads.asterisk.org/pub/telephony/asterisk/. The packaged configured OK. However, I'm getting a compile error: use of undeclared identifier 'pvt'. I've found similar reports for other versions (asterisk-11 and dongle; macports; a couple others), but nothing for 12.4. Any suggestions to

I found an issue with how PJSIP handles a typo in the Dial application. If the Channel is mistakenly typed with two slashes (i.e Dial(PJSIP//xxxx...), the Dial applications fails (obviously), but it also kills the server. I put some code in my pbx_config to check for that string and not let the dialplan reload, but it seems like there should be a better way to handle in in the PJSIP stack or Dial

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

Dear Tariq; About elastix.org, this can be use with Asterisk or it is coming as a complete IP Telephony, Call Center, IVR and Reporting? Because, I do not need to install another IP Telephony on the server which already has asterisk which is an IP Telephony, this will cause a problem in the service (for example, when listening for SIP port of 5060).

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

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

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

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