search for: callsetup

...it. Maybe we could have CGP take care of it, too. > The proposal doesn’t address what happens if llvm.call.setup is called > while there’s another llvm.call.setup still active. Is it legal to call > llvm.call.setup in a loop? Or should nested llvm.call.setup calls have the > parent callsetup token as an operand? > Nested setup is OK, but the verifier rule that there must be a paired call site should make it impossible to do in a loop. I guess we should have some rule to reject the following: %cs1 = llvm.call.setup() %cs2 = llvm.call.setup() call void @cs1() [ "callsetup"(...

...2: call void @callee2(i32 %x, %struct.Foo* preallocated(%struct.Foo) %foo) br label %rejoin rejoin: ... A logical next step would be to run DAE. Suppose one callee does not use i32 %x above. Now the prototypes disagree, and we can't lower the call. We could teach DAE that all calls using callsetup tokens have to have the same prototype, but a simple verifier rule earlier (one call per call setup) seems easier to enforce. > > Nested setup is OK, but the verifier rule that there must be a paired > call site should make it impossible to do in a loop. I guess we should have > some r...

...ment. I recently took the time to write up a design using token values that will hopefully be better named and easier to work with and around. For the technical details of the proposal, I've written up the RFC in Markdown here: https://github.com/rnk/llvm-project/blob/call-setup-docs/llvm/docs/CallSetup.md I've pasted the text below if you want to quote and reply on the list. The main question I have for the community is, given that it is infeasible to upgrade inalloca to llvm.call.setup, can we drop support for the old IR? So far as I am aware, Clang has been the only user of this attribute,...

...nymore. At this moment DTMF send from A isn't getting recognized by U, which IMHO is totally understandable since U doesn't know about payload 96. To me this looks like a bug in asterisk. Either asterisk should use the same rtp payloads for telephone-events on both call legs during inital callsetup or asterisk should come to the conclusion there is an incompatible "codec" on both legs so it shouldn't switch to direct media. Has anyone else seen this issue?

...ight 2000-2002 Motorola, Inc. [AG] MotorolaLara > +BRSF: 63 [AG] MotorolaLara > OK [AG] MotorolaLara < AT+CIND=? [AG] MotorolaLara > +CIND: ("Voice Mail",(0,1)),("service",(0,1)),("call",(0,1)),("Roam",(0-2)),("signal",(0-5)),("callsetup",(0-3)),("smsfull",(0,1)) [AG] MotorolaLara > OK [AG] MotorolaLara < AT+CIND? [AG] MotorolaLara > +CIND: 0,1,0,0,3,0,1 [AG] MotorolaLara > OK [AG] MotorolaLara < AT+CMER=3,0,0,1 [AG] MotorolaLara > OK [AG] MotorolaLara < AT+CLIP=1 [AG] MotorolaLara > O...

Hello-- Why do I target chan_sip for so much effort? Because, it seems to me, chan_sip is probably the most used channel driver in the asterisk community!! (and, of course, the zap/dahdi driver, is also pretty popular) I haven't had time to follow up on chan_sip, and I probably won't for several months. But, if I had time, here is what I'd do: There are two ways to speed up

...V3: Unhandled Unsolicited: +BRSF: 63 [AG] V3 > +BRSF: 63 [AG] V3 > OK [AG] V3 < AT+CIND=? [AG] V3 > +CIND: ("Voice Mail",(0,1)),("service",(0,1)),("call",(0,1)),("Roam",(0-2)),("signal",(0-5)),("callsetup",(0-3)),("smsfull",(0,1)) [AG] V3 > OK [AG] V3 < AT+CIND? NOTICE[3263]: /usr/src/asterisk-test/bluetooth/chan_bluetooth/chan_bluetooth.c:510 set_cind: Audio Gateway V3 got signal [AG] V3 > +CIND: 0,1,0,0,5,0,0 [AG] V3 > OK [AG]...

hello, i've an asterisk box which is connected to an E1/PRI via a TE110P card. incoming calls from mobile phones where the number is transfered as a whole block work fine, but when dialing from an analog or ISDN line to the asterisk box there is a timeout of about 3-5 seconds. originally my incoming context looked like: exten => _X.,1,Dial(SIP/${EXTEN}@domain.tld) so i assumed that the