similar to: SIP re-invite and billing

On 8/9/16 12:40 PM, Matt Fredrickson wrote: > On Mon, Aug 8, 2016 at 9:25 AM, Tammy Firefly <tammy-lists at wiztech.biz> wrote: >> Hi All, >> >> We have asterisk 11.23 running sip to vitelity and from there IAX trunks >> split off to where they need to go. We are having a problem getting >> chan_sip to quit ignoring re-invites from Vitelity. Our side ends

Hello, as a variation of our issues with Adhearsion calls dropping when an INVITE comes in for a bridged call, I now have a new issue to contend with. Our call is in an AsyncAGI application, and has been bridged to another channel. The provider that supplies the DID sends a polling reINVITE every 15 minutes (it's a documented Metaswitch behavior amongst others). The reINVITE is seen as a new

Hello all! I can see a strange problem during invite in dialog in the context of timer handling. Given is the following incoming call from provider at 8.195.88.234 (2 at 2) to my asterisk at 28.19.57.152 (1 at 1): After 900s suddenly *asterisk* starts the timer reinvite - I would have expected the reinvite started by the provider as usual. The expected reinvite by the provider is started

Hi All, We have asterisk 11.23 running sip to vitelity and from there IAX trunks split off to where they need to go. We are having a problem getting chan_sip to quit ignoring re-invites from Vitelity. Our side ends up sending a reinvite which their side & they do not support us sending a reinvite. Ive tried: canreinvite=no which was supposedly replaced by: directmedia=no Can anyone shed

Hello, I think I met a case similar to the one solved by [1] . Quoting this case : * res_pjsip: Handle deferred SDP hold/unhold properly. Some SIP devices indicate hold/unhold using deferred SDP reinvites. In other words, they provide no SDP in the reinvite. A typical transaction that starts hold might look something like this: * Device sends reinvite with no SDP * Asterisk

Hi All, We are using asterisk 16.5 and having an issue with the first re-invite after the call has been established. We can see the call gets up and you see in the logs the bridge type has changed and after that a re-invite is triggered. Is there any possibility to deactivate this kind of reInvite? We have some race conditions while have multiple asterisk in the call flow and the different

been testing with a rather simple setup. The mission is to actually get a reinvite to work on the lan. I am trying with two sipura phones G.711 codec forced on both both on the lan no nat no fancy options suchs as tT or H No matter what we do asterisk hangs on to the media path, how in the world do I get a reinvite to work where the media path is actually handled by the two phones on the lan?

Hi All, I haven't started sip traces or debug yet, but was wondering what the deal is with the CCM and reinvite, why it doesn't work with Asterisk (using 1.2.9.1). I can make calls back and forth all day with canreinvite=no, when I try to reinvite an inbound sip call from the CCM with Asterisk server 1 to Asterisk Server 2, I get one-way audio issues. All the RTP ports are configured

Hi, I just ran into what seems to be an issue on re-invites. I'm not sure if it's a bug or as designed, so I thought I'd ask the question. Here's my setup: - Asterisk 1.8.13.0 - Phone A: Polycom ip331, only allowed to use ulaw, canreinvite=yes - Phone B: Polycom ip330, only allowed to use alaw, canreinvite=yes Phone A calls the extension of phone B. After the normal call setup

Hi all, So the scenario is: A -> Asterisk -> B after B send back 200 OK Asterisk is answering the call to A. Directly after the Answer Asterisk generates a ReInvite to A and the only difference between the 200 OK sdp and the reInvite sdp are the offered codecs which are forwarded from B to A. Here i do not understand why this could not be done in the 200OK to A? As far as i understood

Hi All, I'm having a really weird can reinvite issue. I've been banging my head around on this for days now.. I have two asterisk servers. One at 172.20.0.11 One at 172.20.2.5 172.20.0.11 is a hosted box and serves multiple offices 172.20.2.5 is a box on site at a customer's office. A phone at 172.20.128.10 makes a call using server 172.20.0.11 to a phone at 172.20.2.80 via server

Hello, I know there's a problem with Asterisk at the moment in that while it's easy for one caller to dial another (using the dial command), it's tricky to connect two calls that are already in progress. I've been using MeetMe to achieve this (with each caller's call being directed to a dynamically created conference room programatically), and this is working - kind of -

Hello! I'm facing ReInvites as caller from UAS despite configured session-timers=refuse (which can be seen in the SIP trace) always after 900s. (The behavior is the same if session-timers is set to accept). This just happens with one provider (German Telekom to callee at kabelbw). - The incoming ReInvite is answered immediately by asterisk (Status 100 / Status 200 - 0.02s). Media stream

On Wed, Sep 25, 2019 at 5:02 PM Eli Friedman via llvm-dev < llvm-dev at lists.llvm.org> wrote: > My biggest question about this architecture is about when propeller runs > basic block reordering within a function. It seems like a lot of the > complexity comes from using the proposed -fbasicblock-sections to generated > mangled ELF, and then re-parsing the mangled ELF as a

Is it possible to allow reinvites to/from specific devices? For example; exten 2001 and 2002 can reinvite to each other, but not 2003 and 2004 exten 2003 and 2004 can reinvite to each other, but not 2001 and 2002 Can that be done? Devices 2001 & 2002 are behind one firewall, and 2003 & 2004 are behind another. Tim

On Fri, Sep 27, 2019 at 10:36 PM Eric Christopher <echristo at gmail.com> wrote: > On Fri, Sep 27, 2019 at 2:08 PM Sriraman Tallam via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > On Fri, Sep 27, 2019 at 1:16 PM Eli Friedman <efriedma at quicinc.com> > wrote: > > > > > > > -----Original Message----- > > > > From:

On Fri, Sep 27, 2019 at 1:16 PM Eli Friedman <efriedma at quicinc.com> wrote: > > > -----Original Message----- > > From: Sriraman Tallam <tmsriram at google.com> > > Sent: Friday, September 27, 2019 9:43 AM > > To: Eli Friedman <efriedma at quicinc.com> > > Cc: Xinliang David Li <xinliangli at gmail.com>; llvm-dev <llvm-dev at

On Mon, Sep 30, 2019 at 12:26 PM Eric Christopher <echristo at gmail.com> wrote: > On Sat, Sep 28, 2019 at 8:25 AM Sriraman Tallam <tmsriram at google.com> > wrote: > > > > > > > > On Fri, Sep 27, 2019 at 10:36 PM Eric Christopher <echristo at gmail.com> > wrote: > >> > >> On Fri, Sep 27, 2019 at 2:08 PM Sriraman Tallam via

On Mon, Sep 30, 2019 at 1:27 PM Eric Christopher <echristo at gmail.com> wrote: > On Mon, Sep 30, 2019 at 12:31 PM Sriraman Tallam <tmsriram at google.com> > wrote: > > > > > > > > On Mon, Sep 30, 2019 at 12:26 PM Eric Christopher <echristo at gmail.com> > wrote: > >> > >> On Sat, Sep 28, 2019 at 8:25 AM Sriraman Tallam

On Thu, Sep 26, 2019 at 5:13 PM Eli Friedman <efriedma at quicinc.com> wrote: > > > -----Original Message----- > > From: Sriraman Tallam <tmsriram at google.com> > > Sent: Thursday, September 26, 2019 3:24 PM > > To: Eli Friedman <efriedma at quicinc.com> > > Cc: Xinliang David Li <xinliangli at gmail.com>; llvm-dev <llvm-dev at