| 01:03.52 | *** join/#asterisk-dev wdoekes (~walter@wjd.osso.nl) |
| 01:30.46 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 01:30.46 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 02:43.29 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 02:43.30 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 03:19.45 | *** join/#asterisk-dev mvanbaak (~michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 03:19.45 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 05:45.04 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 05:45.04 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 06:22.42 | *** join/#asterisk-dev jmls (~jmls@77.107.171.82) |
| 06:36.08 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 06:36.08 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:48.49 | *** join/#asterisk-dev bulkorok (~bulkorok@85.183.36.36) |
| 07:04.23 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:04.24 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:08.59 | *** join/#asterisk-dev oron_laptop (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 09:02.30 | *** join/#asterisk-dev wedhorn (~wedhorn@123-243-209-34.static.tpgi.com.au) |
| 09:09.02 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 09:09.02 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:11.39 | oej | Hello folks! |
| 10:09.01 | jmls | morening |
| 10:28.57 | oej | Back to RTCP work, now in Asterisk 11 |
| 10:37.49 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 10:37.49 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 10:39.52 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 10:39.52 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:02.41 | *** join/#asterisk-dev caio1982 (~caio1982@189.125.242.3) |
| 12:55.21 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-jwgobrpzswbpgpno) |
| 13:14.13 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 13:14.14 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 13:36.32 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-xudporutogjpmqlk) |
| 13:36.32 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:18.17 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:18.17 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 14:24.58 | file | opticron, do you have a branch for your pimpin' media changes? |
| 14:26.12 | opticron | I do not, but I could |
| 14:26.21 | file | was just WONDERIN' |
| 14:26.46 | opticron | I initially thought the patch would be smaller, so I didn't think to create a branch for it |
| 14:27.55 | file | kharwell, I have video capable stuff here if you get to a point where you are happy and want someone else to try it out fyi |
| 14:28.38 | opticron | immediately regrets looking at code in cdr.c |
| 14:31.00 | file | opticron, thoughts on the pjmedia SDP negotiator? like it/hate it? |
| 14:31.10 | kharwell | file: I am getting close. I'll let you know as I can always use the extra testing. |
| 14:32.01 | file | kharwell, cool |
| 14:33.25 | opticron | I like that it handles a lot of the things that chan_sip had wrong for so long automatically that we really have no need to ever touch, like proper ordering of streams in the reply and proper declination of streams we don't touch/want |
| 14:35.01 | opticron | I'd have liked it to have some kind of built in SDP validation, but I understand why it's not there |
| 14:35.41 | file | it validates the stuff it can, it won't let you construct an obvious broken SDP |
| 14:35.48 | opticron | right |
| 14:35.54 | opticron | and that's enough |
| 14:36.54 | opticron | overall, I like it :) |
| 14:40.58 | file | mjordan, I'm trying to decide if I like you enough to subject myself to anything remotely CDR related |
| 14:42.33 | opticron | file, even the shutdown stuff in there is complicated |
| 14:43.11 | file | opticron, stab stab stab? |
| 14:43.34 | opticron | a little bit |
| 14:55.29 | bulkorok | opticron is alive :-) |
| 14:55.49 | file | should he not be? |
| 14:56.32 | bulkorok | I hope that not! |
| 14:56.47 | bulkorok | I have an open issue he is taking care of ;-) |
| 15:06.04 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 15:07.03 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 15:07.03 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:09.26 | oej | file? |
| 15:09.30 | file | hi |
| 15:09.45 | oej | Good afternoon/morning/<your choosing> |
| 15:10.20 | oej | I have issues with the RTT in RTCP in Asteirsk 1.8/11 |
| 15:10.32 | oej | Did you test that at any point when you created the RTP engine? |
| 15:10.35 | oej | What's the value? |
| 15:10.44 | file | nope, the code was moved as-is from rtp.c |
| 15:10.59 | file | I didn't do any functional changes of that level |
| 15:11.04 | oej | Hmm. I need to go back to 1.4 then and see what's different. |
| 15:11.16 | oej | THanks. |
| 15:14.53 | *** join/#asterisk-dev opticron (~opticron@pianoben.ch) |
| 15:14.53 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 15:22.51 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:48.55 | *** join/#asterisk-dev pietro (~pietro@78.134.12.196) |
| 16:46.38 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:46.38 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:49.00 | *** join/#asterisk-dev rgagnon (~rgagnon@d24-57-198-219.home.cgocable.net) |
| 16:49.27 | *** part/#asterisk-dev rgagnon (~rgagnon@d24-57-198-219.home.cgocable.net) |
| 18:15.55 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 18:15.55 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:48.44 | jmls | Adding RESTful API's to Asterisk ,,, yay ! |
| 18:52.49 | mjordan | jmls: feedback will be very appreciated |
| 18:52.59 | mjordan | although it is still a work in progress |
| 18:58.26 | mjordan | jmls: also - https://github.com/asterisk/asterisk_rest_libraries |
| 19:00.25 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 19:00.25 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 19:18.43 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 19:35.15 | jmls | intend to make huge use of rest api - are all manager commands exposed this way ? |
| 19:35.48 | snuff-home | everything appears to be open.. or going open in 12/13 :) |
| 19:38.13 | jmls | how are the rest libraries generated ? Manually or automatically ? |
| 19:38.27 | serafie | jmls: unsure |
| 19:38.29 | jmls | c#, progress, ruby etc |
| 19:38.36 | serafie | you can generate them, but they don't do anything yet |
| 19:39.30 | serafie | Still work to be done before they will be usable. |
| 19:39.34 | jmls | I get the feeling that -12 is a huge leap forward |
| 19:40.04 | file | it is. |
| 19:40.37 | snuff-home | file i might buzz u in 2hrs or so.. |
| 19:40.48 | file | snuff-home, I think I'll be here |
| 19:40.59 | jmls | is stasis a new mechanism for publishing events ? |
| 19:42.37 | file | grins |
| 19:43.30 | pabelanger | jmls, 2.0 huge |
| 19:47.33 | leifmadsen | Asterisk 12 is going to have some new hotness |
| 19:47.41 | jmls | I feel the heat already |
| 19:47.44 | leifmadsen | new sip channel driver and rest apis? ftw!!! |
| 19:47.52 | leifmadsen | just those 2 things alone are the hotness |
| 19:47.57 | jmls | wants to play! |
| 19:48.46 | jmls | ultimate hotness would be to have a stomp client posting events to jms server ... |
| 19:48.48 | Marquis42 | Yeah, I totally can't wait for 12. |
| 19:49.10 | opticron | a lot of task processors that were attached to event system callbacks get to go away as well since the stasis guarantees serialized invocations |
| 19:49.25 | opticron | during conversion of events to stasis messages/topics |
| 19:50.49 | jmls | so, are stasis messages/topics exposed , or do we have to write something to interpret them as we see fit ? |
| 19:52.44 | Marquis42 | Indeed, statis is another thing I'm absolutely looking forward to. |
| 19:57.12 | opticron | jmls, everything stasis is not exposed, but large swaths of it are via stasis-http |
| 19:59.51 | jmls | opticron, right - but that implies polling, yes ? |
| 20:00.54 | jmls | or can you post the event data to a url ? |
| 20:01.17 | jmls | wonders why it isn't "an url". |
| 20:01.24 | file | it's via websockets |
| 20:02.21 | jmls | you send data to a websocket ? |
| 20:02.30 | jmls | starts to get excited ... |
| 20:02.39 | file | you connect via websockets and then you get stuff over it |
| 20:02.43 | jmls | urgh. that sounds really bad ... |
| 20:02.48 | file | and there's RESTful things outside of that |
| 20:02.52 | jmls | not you file ;) |
| 20:06.43 | jmls | ok, so I will need a "client" to connect to the websocket - just like I need a client to connect to the AMI socket ? |
| 20:06.43 | opticron | it's not "an url" because url is "you are ell", not "earl" |
| 20:07.08 | *** join/#asterisk-dev TheCompWiz (~TheCompWi@63.214.236.169) |
| 20:07.23 | jmls | opticron, but it stands for "Uniform resource locator" [or something like thayt |
| 20:07.28 | file | you will need something to connect |
| 20:07.28 | jmls | *] |
| 20:07.34 | file | it could itself be a server to other stuff |
| 20:07.40 | jmls | yah |
| 20:10.19 | mjordan | jmls: sorry, was bouncing around in meetings. So, first, there's two things going on here - Stasis-Core, and Stasis-HTTP |
| 20:10.21 | Kobaz | shouldn't rtptimeout not get hit if you're on musiconhold |
| 20:10.36 | mjordan | Stasis-Core is an internal message bus to Asterisk, which is the whole topic/message stuff you see flying around on review board |
| 20:10.48 | mjordan | that's useful if you want to build your own modules that interact with the internal state of Asterisk |
| 20:11.14 | mjordan | internal state == MWI, device state, presence, channel state, bridge state, as well as the 'other' stuff that AMI currently has knowledge of |
| 20:11.24 | mjordan | and... be back in a bit :-) |
| 20:12.37 | Kobaz | [2013-03-14 10:35:05] VERBOSE[11432] channel.c: [2013-03-14 10:35:05] -- <SIP/AudioCodesFXO1-00000a26> was put on hold by its bridged peer: SIP/420-00000a27 |
| 20:12.38 | Kobaz | [2013-03-14 10:36:06] NOTICE[12417] chan_sip.c: Disconnecting call 'SIP/420-00000a27' for lack of RTP activity in 61 seconds |
| 20:13.00 | Kobaz | cisco spa phones |
| 20:13.26 | Kobaz | that doesn't seem right |
| 20:43.40 | jmls | is dying for mjordan to get back ... |
| 20:45.14 | mjordan | jmls: sorry, some days I exist in an event driven loop |
| 20:45.53 | jsmith | mjordan: Gotta hate those non-maskable interrupts :-p |
| 20:46.07 | mjordan | jmls: so, Stasis-Core provides a cache and a pub/sub architecture for modules to get informed of the state of useful things in Asterisk. That lets all of the various Asterisk interfaces to be refactored on top of that message bus so that they no longer have to go get the objects themselves in order to get that info |
| 20:46.23 | mjordan | that means you don't have to worry about deadlocking, lifetime interference, etc. |
| 20:46.35 | mjordan | as the stasis message payloads have a well-defined and rather simple set of rules |
| 20:46.49 | mjordan | AMI gets refactored on top of Stasis Core |
| 20:47.02 | mjordan | as does CDRs and CEL. The jury is out on Queue Log. |
| 20:47.07 | file | (mjordan has said this a lot) |
| 20:48.07 | jmls | why not queue log ? |
| 20:48.16 | mjordan | just not sure it needs to be yet |
| 20:48.42 | mjordan | Stasis-HTTP is a brand spankin new interface built on top of Stasis-Core. While AMI provides some call management and system control but not individual call manipulation, and AGI provides individual call manipulation but (unless you use FastAGI/AsyncAGI and unify it with AMI) not a system level view, both are dependent on the applications that Asterisk provides |
| 20:48.59 | mjordan | They don't really let you get at the raw operations within Asterisk, nor do they let you take a pool of channels and just go do stuff to them |
| 20:49.14 | mjordan | Stasis-HTTP lets you built telephony applications using the telephony objects in Asterisk. |
| 20:49.25 | mjordan | It doesn't let you put a channel into Queue - it let's you build your own Queue. |
| 20:49.36 | jsmith | really needs to start playing with Stasis-HTTP |
| 20:49.46 | Marquis42 | mjordan: And *that* is what excites me about it. |
| 20:49.48 | pabelanger | jsmith, :) |
| 20:50.39 | mjordan | so, when you're looking at the REST API and the things it let's you do, think about specific use cases |
| 20:50.52 | mjordan | I have a channel put into a Stasis-HTTP app. I want to bridge it with an Agent. |
| 20:51.43 | mjordan | bridge.add_channel_to(inbound_caller, agent_one) |
| 20:52.17 | mjordan | bridge.record('agent_one.wav', beep_boolean=True) |
| 20:52.30 | mjordan | etc. |
| 20:52.32 | Marquis42 | Excellent. I've admittedly only been keeping one eye on it with the hopes that I understood the intent. This definitely makes me think I need to be paying more attention. |
| 20:52.38 | mjordan | (using serafie's python wrapper) |
| 20:54.28 | pabelanger | Hmm, sounds like a good presentation for astricon. |
| 20:55.18 | jmls | so this is all done through web sockets ? |
| 20:56.01 | file | no |
| 20:59.22 | file | if only *cough* leedm777 would speak up |
| 21:00.15 | jmls | faceplants |
| 21:00.16 | mjordan | he's talking to me... sorry :-P |
| 21:00.40 | file | CRAZY |
| 21:01.10 | leedm777 | pays attention |
| 21:04.49 | leedm777 | okay, finished reading the backlog |
| 21:05.09 | leedm777 | WebSockets are used by Stasis-HTTP to generate events back to the client |
| 21:05.19 | leedm777 | such as DTMF, channel state changes, etc. |
| 21:05.42 | leedm777 | When the client wants to query Asterisk, or make it do things, it hits the RESTful API |
| 21:06.25 | jmls | cheers |
| 21:06.29 | jmls | ok, I get it |
| 21:06.34 | leedm777 | The REST API itself is documented using Swagger, which allows client bindings to be generated (see serafie's work) |
| 21:06.48 | serafie | ...which is not currently in a usable state. |
| 21:06.53 | jmls | heh |
| 21:07.12 | leedm777 | serafie: neither is Stasis-HTTP :-D |
| 21:07.42 | serafie | leedm777: you've got an advantage... my work can't possibly surpass yours in completeness. |
| 21:07.48 | serafie | :) |
| 21:07.53 | leedm777 | There's also swagger-ui, which you can point to the API to generate executable documentation |
| 21:07.55 | serafie | Unless I find my third eye. |
| 21:08.13 | leedm777 | Such as this petstore demo: http://petstore.swagger.wordnik.com/ |
| 21:08.14 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-159-37.user.veloxzone.com.br) |
| 21:08.52 | jmls | so, bridge.record is a python "method" which internally send some "stuff" to the REST API ? |
| 21:08.59 | leedm777 | yes |
| 21:09.00 | mjordan | yup |
| 21:09.02 | jmls | yay! |
| 21:09.06 | mjordan | https://github.com/asterisk/asterisk_rest_libraries/blob/master/python/lib/bridge.py |
| 21:09.09 | jmls | doesn't feel too stupid now |
| 21:09.34 | leedm777 | The client libraries aren't strictly necessary, since it's just REST/HTTP. |
| 21:09.42 | leedm777 | But they're really nice to get started |
| 21:09.50 | leedm777 | Or, at least, they will be when they're done :-D |
| 21:09.52 | mjordan | is a fan of having things done for him |
| 21:10.08 | serafie | also just pushed javascript |
| 21:10.22 | mjordan | woot |
| 21:10.29 | file | gives serafie a cookie |
| 21:10.35 | serafie | \o/ |
| 21:10.44 | serafie | next up: Assembly! |
| 21:13.18 | jmls | Z80 I hope |
| 21:13.52 | jmls | not that 6502 crap |
| 21:14.13 | jmls | shows his true age :( |
| 21:14.31 | leedm777 | bbiab |
| 21:15.43 | jmls | ld a,30 |
| 21:17.14 | file | leedm777, CHEATER! |
| 21:19.01 | jmls | really sad, I know .. but .. http://archive.org/details/popular-computing-weekly-1986-03-13 page 26 - details on how to hack sourcery on the Amstrad CPC :( |
| 21:19.30 | jmls | just thought that "sourcery" has some meaning right now ;) |
| 21:20.24 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 21:20.24 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 21:25.37 | wedhorn | snuff-work: new patch for skinny gpickup (including greying) - https://issues.asterisk.org/jira/browse/ASTERISK-21224 |
| 21:25.37 | LieutPants | [ASTERISK-21224] [Status: Open] Skinny groupPickup issues - https://issues.asterisk.org/jira/browse/ASTERISK-21224 |
| 21:28.08 | mjordan | jmls: it does :-) |
| 21:29.26 | jmls | yay. I was hacking sourcery 27 years ago ! talk about being ahead of the times .. |
| 21:33.02 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-xudporutogjpmqlk) |
| 21:39.00 | *** join/#asterisk-dev Marquis42 (~mrbmw@c-68-43-254-216.hsd1.mi.comcast.net) |
| 22:23.08 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 22:23.09 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 22:25.06 | snuff-work | file: same question as last time i think.. how do we intend to 'get' the * callerid into res_sip.. i understand reading / adding to the responses res_sip sends.. |
| 22:26.03 | file | snuff-work, so there's two ways! you can hook into the sending of messages and change them (ie: add headers) or chan_gulp can explicit call an API in res_sip_session |
| 22:26.14 | file | same goes for receiving |
| 22:27.14 | snuff-work | mm.. but if i'm doing a dial(gulp/sip:user@someip).. but above that i've decided i want my callerid to be 'joe blogs <5000>' |
| 22:27.59 | file | I like the API approach, myself, versus automatic |
| 22:28.25 | snuff-work | atm how do i get 'joe blogs <5000>' to be seen within res_sip.. because we send a null chan to res_sip to recreate 1.. |
| 22:28.51 | snuff-work | maybe i'm still not getting it.. |
| 22:29.05 | file | chan_gulp would call an API in res_sip_session with that information |
| 22:29.45 | file | to say "here, put this information on using the configuration details of the endpoint" - if the endpoint is configured to do P-Asserted-Identity then the underlying implementation would do that |
| 22:30.17 | snuff-work | yes.. i understand if its within our config file of res_sip.. i'm talking via dialplan |
| 22:30.23 | snuff-work | aka the way most ppl work :) |
| 22:30.28 | file | I wasn't talking about config file |
| 22:30.48 | file | when a channel is requested from a channel driver it is given the requestor channel, and it uses that to get the callerid information |
| 22:31.29 | file | or is the cid changed... |
| 22:31.35 | file | I can't remember, lemme check! |
| 22:32.03 | snuff-work | on the flip side.. i think i've almost made remote-party-id header implementation within pjsip |
| 22:32.08 | file | please hold |
| 22:32.11 | file | your request is important to me |
| 22:36.02 | snuff-work | is there a way to force rebuild just pjproject? |
| 22:36.17 | file | are you modifying pjproject? |
| 22:36.40 | pabelanger | Sends audio file on channel. |
| 22:36.44 | pabelanger | what does that even mean |
| 22:37.04 | snuff-work | for a side project of making a nice 'remote-party-id' like the via header / fromto etc |
| 22:37.38 | snuff-work | rather than parsing it up within * via find_msg_header ( i think its called) |
| 22:38.05 | file | we ultimately probably won't have our own pjproject... so that'll have to go upstream |
| 22:39.01 | snuff-work | i've noticed.. the removal work going on by qwell in a branch if i recall |
| 22:39.10 | file | yeah, it's merged in now |
| 22:40.08 | snuff-work | mm i didn't know it had merged in.. |
| 22:40.33 | snuff-work | wasn't there an effort to cleanup pjsip building?.. did any of that work go upstream? |
| 22:41.09 | file | the work was just finished |
| 22:41.51 | file | I almost have a question to your answer |
| 22:41.58 | file | or an answer to your question |
| 22:42.17 | snuff-work | that's ok.. atm i'm just watchin a ted X talk |
| 22:43.21 | file | snuff-work, within gulp_call in chan_gulp.c, or really even within res_sip you can use ast_channel_connected to get the details for who you are connected to - and in that case who is calling you |
| 22:43.51 | snuff-work | not interested in person calling me.. interested in us calling out :) |
| 22:44.22 | file | so a call INBOUND from a phone? |
| 22:45.12 | snuff-work | yes.. so.. i make a call.. that goes out via chan_gulp.. |
| 22:45.17 | snuff-work | to somewhere else |
| 22:45.25 | file | well, no that's not specific enough |
| 22:45.57 | file | what does "go out" mean |
| 22:46.12 | file | Gulp/sip:user@someip like you said before? |
| 22:46.27 | file | an IAX2 client calling a SIP user using chan_gulp? |
| 22:48.26 | snuff-work | so.. a person with 'my caller <5000>' calls into ast (via gulp if u want).. then goes out to another user using the default gulp/sip:exten@host |
| 22:48.49 | file | stick to one Gulp channel on a side or else you are going to confuse me |
| 22:49.09 | snuff-work | ok.. a skinny call or IAX.. wants to go out gulp.. |
| 22:49.18 | file | okay, so an outbound Gulp call |
| 22:49.36 | snuff-work | as it goes through the DP before dialing.. we set a new callerid out as 'someone else <6000>' |
| 22:49.45 | file | well, no |
| 22:49.50 | file | you change the callerid of the calling channel |
| 22:50.07 | file | that's what Set(CALLERID()) etc in the dialplan does, it changes the callerid of the current channel |
| 22:50.29 | snuff-work | mm sorry.. my bad.. i sometimes wish i could set the other :) |
| 22:50.40 | file | so in chan_gulp or any other channel driver you retrieve the callerid of the calling channel - and it may or may not have been changed, it doesn't really know |
| 22:50.50 | file | and you retrieve it using ast_channel_connected |
| 22:52.52 | snuff-work | k |
| 22:53.13 | snuff-work | i will have another go on weekend.. re-read some chan_skinny cause its slightly easier than old chan_sip |
| 22:53.21 | file | aye |
| 22:54.22 | file | thanks for looking! this is one of those things I've wanted for a bit, but other stuff has been more important |
| 23:29.27 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |