| 00:02.03 | Greenlight | Would it be possible to have a function hook to a channel, by using the Variables in an AMI originate command, or must it be via a Set command ? |
| 00:03.43 | WIMPy | mjordan: Calls going TO chan_sip. |
| 00:04.45 | mjordan | Greenlight: Set would call the function on the channel. Something has to apply the frame hook on the channel, and usually a function does that. |
| 00:04.55 | WIMPy | I guess they shouldn;t have a codec or something. |
| 00:05.29 | mjordan | WIMPy: So when you say a call going to chan_sip, an INVITE request comes in from some endpoint. What does the SDP contain? |
| 00:05.36 | mjordan | if it contains app, we'll discard it |
| 00:05.40 | mjordan | audio, video, text, image |
| 00:05.51 | mjordan | those are allowed in some combination (audio being required) |
| 00:06.02 | WIMPy | No, to can_sip within Asterisk. I.e. Dial(SIP/... |
| 00:06.07 | mjordan | ah |
| 00:06.15 | mjordan | so what is the channel that is doing the Dial? |
| 00:06.26 | WIMPy | isdn |
| 00:07.02 | WIMPy | 64kbps unrestricted digital information. Not something a phone can make sense of. |
| 00:08.12 | mjordan | ah. |
| 00:08.25 | mjordan | in that case, I'd imagine the mISDN channel or Dahdi channel wouldn't have any codecs |
| 00:08.38 | mjordan | or their format would be something that would be incompatible with the SIP channel |
| 00:09.09 | mjordan | at some point in time before bridging, Asterisk will attempt to make the channels compatible, fail, and the call would fail |
| 00:09.32 | mjordan | but yes, you may get an outbound Dial first. But then again, you did go into the Dialplan and ask that it Dial a SIP device :-) |
| 00:09.43 | WIMPy | It shouldn't even ring. |
| 00:10.13 | mjordan | you don't know that it can't accept the format |
| 00:10.19 | WIMPy | The old phones don't ring as they know they are incompatible with the call, but with sip it somehow gets through. |
| 00:10.28 | WIMPy | I guess I should make some comparisons of cahnnels there. |
| 00:10.36 | mjordan | who knows. I could create a wacky SIP device that accepts just about anything. Until I send back the 200 OK, you don't know what I truly accept |
| 00:10.54 | snuff-work | mjordan: your doing some work on the bridging stuff right? |
| 00:11.04 | mjordan | snuff-work: I'm involved |
| 00:11.59 | snuff-work | when doing a 'softmix' bridge (aka confbridge).. it always seems for me to default to 8k.. even if both chans involved are 16k |
| 00:12.29 | mjordan | snuff-work: yeah, I remember that coming up. It will mix at the right sampling rate, but it transcodes down to slin8 |
| 00:12.55 | mjordan | snuff-work: there needs to be support put into ConfBridge/softmix to support slin16 |
| 00:13.45 | snuff-work | mm.. i tried doing just an 'add' of 16k to the 'default' formats in the softmix |
| 00:14.02 | snuff-work | but still dropped to slin8.. |
| 00:14.05 | mjordan | WIMPy: think about it this way, a SIP device could be a camera that only supports video (not even audio) or some 'app' type. If all you have is a URI to dial, you don't really know much about what I am until I respond with a 200 OK. In your case, they're phones - which means they have no hope of ever working - but unfortunately chan_sip (nor any SIP channel driver) can make that assumption until they get something back from the device |
| 00:14.55 | snuff-work | if we updated softmix.. we'd probably also want to fix up 'record' to accept slin16 as well as slin8 |
| 00:15.02 | snuff-work | record/mixmon |
| 00:15.43 | WIMPy | mjordan: Do you think there is any chance of caompatibility? |
| 00:15.57 | WIMPy | Maybe if HLC/LLC information would be taken into account. |
| 00:16.12 | mjordan | snuff-work: did you add to the softmix_channel? |
| 00:16.18 | mjordan | snuff-work: that'd be nice |
| 00:16.49 | mjordan | WIMPy: no, probably not. But I'm not sure you can make those assumptions either way |
| 00:18.11 | WIMPy | I'd go and check for CHANNEL(transfercapability), but filtering SIP destination ist probably a case for an AGI. |
| 00:18.16 | mjordan | snuff-work: honestly, I haven't spent enough time looking at the softmix transcoding code to have a good feel for what is needed there. |
| 00:18.37 | snuff-work | mm np |
| 00:18.42 | mjordan | snuff-work: a lot of the work being done right now is dealing with the threading model used by the bridging API as a whole, as well as applying that API to the two party bridges that are currently handled in features.c |
| 00:18.57 | mjordan | but I don't anticipate a lot to change with softmix specifically, so any work that is done to improve on that would be awesome |
| 00:19.43 | mjordan | it feels like you'd have to make the softmix_channel private data structure 'pick' slin16 as opposed to slin8 |
| 00:19.55 | mjordan | but I'd have to poke at it a bit more to know for sure |
| 00:19.57 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-hrhedrelvvtixkjn) |
| 00:36.02 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 00:36.02 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 00:40.40 | WIMPy | I'm updating my test box, but it looks like the SDP inclueds all audio codecs even if it's a non-audio call. |
| 00:40.59 | WIMPy | all configured codecs |
| 01:17.11 | *** join/#asterisk-dev serafie (~erin@24.214.158.242) |
| 01:23.02 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 01:23.02 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 01:26.09 | WIMPy | With SVN versions of libpri, dahdi and Asterisk, the same thing happens. |
| 02:05.36 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 02:05.36 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:47.24 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 02:57.36 | WIMPy | Looks like neither the digium hosted misdn/hfcmulti nor dahdi/wcb4xxp do a propper initialisation. Using one and then rebooting the other without hardware reset causes malfunction. |
| 03:32.14 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 03:32.16 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 04:24.33 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 04:24.33 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 04:49.29 | *** join/#asterisk-dev serafie1 (~erin@24.214.158.242) |
| 05:23.45 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 05:23.45 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 05:45.54 | wedhorn | snuff-work: good stuff |
| 05:48.47 | wedhorn | can you push it one channel further on eg connected_id(redirect_party)? |
| 05:49.22 | snuff-work | question still is why a skin -> sip -> skin works fine by default.. yet skin -> sip -> sip does not |
| 05:50.25 | snuff-work | all i do in callinfo.. redir_id = ast_channel_redirecting_effective_to(ast); / if(redir_id.number.str != NULL) { toname = S_COR(redir_id.name.valid, redir_id.name.str, ""); } etc |
| 05:50.42 | wedhorn | because local disappears on the skinny channel |
| 05:51.23 | snuff-work | u committed ur 144 change etc the other day right? |
| 05:54.22 | wedhorn | yep |
| 05:55.56 | snuff-work | http://pastebin.ca/2317353 |
| 05:56.51 | snuff-work | what i've done.. i dont 'think' you need the other part i added for control_redirecting |
| 05:57.02 | snuff-work | which called update_connectedline |
| 05:57.11 | wedhorn | during the cfwd, are there 3 channels or 4? I there's 4, you probably want something like ast_channel_connected_effective_id(ast_channel_redirecting) ie the final chan |
| 05:58.13 | wedhorn | ... to get the real final number |
| 05:59.19 | snuff-work | mm so after i PICKUP the call.. local goes away.. == Spawn extension (national-outgoing, 00410551660, 1) exited non-zero on 'Local/00410xxxxxx@syd-phones-00000010;2' |
| 05:59.34 | snuff-work | mm so my fail |
| 05:59.52 | snuff-work | remove number once not twice :( |
| 06:00.41 | wedhorn | ? |
| 06:02.28 | snuff-work | http://pastebin.ca/2317355 |
| 06:02.55 | snuff-work | as u can see.. after we 'pickup' the local is removed |
| 06:03.12 | wedhorn | and? |
| 06:03.33 | snuff-work | u'd think the clid should update like ur skinny :) |
| 06:03.35 | snuff-work | but.. |
| 06:03.44 | snuff-work | works with my patch fine |
| 06:04.25 | wedhorn | nope |
| 06:05.06 | wedhorn | with sip it appears local stays in the loop til the last minute |
| 06:05.30 | wedhorn | assume a masq then occurs |
| 06:05.47 | wedhorn | with no further indications (except rtp updates) |
| 06:06.09 | wedhorn | which is an ugly spot to put the callerid update, but would probably work as well |
| 06:06.31 | wedhorn | but you wouldn't see the number until the call is answered |
| 06:07.06 | snuff-work | issue with my patch is that its taking the 'early' number.. |
| 06:07.09 | wedhorn | having a look at sip, it seems to send callerid stuff at fairly random places |
| 06:08.08 | wedhorn | Based on a call path, after the forward but before answering final device, of skinny -> local1 -> local2 -> sip |
| 06:08.20 | wedhorn | you're probably picking up the details from local2 |
| 06:08.29 | wedhorn | ie 00 |
| 06:08.46 | snuff-work | mm |
| 06:09.05 | wedhorn | all speculation, but I'm guessing local1 is redirect_from and local2 is redirect_to |
| 06:09.29 | snuff-work | i only see 1 local die.. |
| 06:09.32 | wedhorn | hence me saying you may need connected(redirect_to) => sip |
| 06:09.39 | snuff-work | mm |
| 06:09.43 | snuff-work | could try |
| 06:09.53 | snuff-work | have to rebuild whole * since svn up ;) |
| 06:10.56 | wedhorn | um, local1 wouldn't enter the dialplan |
| 06:11.19 | wedhorn | again, all speculation, haven't looked at the code or tried any of this, but |
| 06:11.34 | wedhorn | skinny -> sip - cfwd |
| 06:11.50 | wedhorn | masq sip -> local1 |
| 06:12.10 | wedhorn | enter dialplan with local2 to fwd'd num |
| 06:13.51 | wedhorn | simple test, make a call and do core show channels before answering |
| 06:16.20 | snuff-work | i have 4 |
| 06:17.11 | wedhorn | so redir_to is probably the 3rd |
| 06:17.31 | wedhorn | you want connected(redir_to) |
| 06:18.31 | wedhorn | ie 1 is connected to 2, 3 is connected to 4 and local passes on messages between 2 and 3 |
| 06:19.37 | snuff-work | still interesting though.. on 'ringing'.. we have skinny(ringing) to 5018.. local(mob num) (down) .. local (mobnum) (ring).. sip/aapt (ring) |
| 06:21.08 | wedhorn | gotta love the whole masq thing ... |
| 06:24.48 | snuff-work | mm.. |
| 06:25.09 | wedhorn | waits in anticipation |
| 06:25.53 | snuff-work | looking at chan variables.. what i'm doing now is just fine |
| 06:26.09 | snuff-work | aka would be 00410xx.. |
| 06:26.37 | snuff-work | the only place u see without the extra '0' is the dialedpeer.. variable |
| 06:27.08 | snuff-work | because there's no exten without the 0 |
| 06:27.13 | snuff-work | extra 0. |
| 06:30.52 | wedhorn | i would have thought you'd string the extra zero before dialing the sip channel |
| 06:30.58 | wedhorn | strip* |
| 06:31.31 | snuff-work | got another funny thing going on.. |
| 06:31.39 | snuff-work | i have changed that bit now.. |
| 06:31.41 | snuff-work | but.. |
| 06:31.45 | wedhorn | one thing at a time ;) |
| 06:32.47 | snuff-work | if i do.. dial(sip/5018,20)... then it redirects to a external number.. dial(sip/0410xxxx,60).. |
| 06:33.33 | snuff-work | it only keeps the call alive for 20 sec even though the secondary dial is 60 sec length |
| 06:34.50 | wedhorn | cool, that'd be dial or sip. |
| 06:35.19 | wedhorn | but makes sense from a technical aspect seeing as your first dial ends up being dial local1 |
| 06:35.20 | snuff-work | basically seems that local / sip.. does not want to do the final update of the clid once connected.. |
| 06:35.53 | snuff-work | if it did.. would have correct values |
| 06:35.59 | snuff-work | like skinny does |
| 06:36.05 | wedhorn | have you tried talking to connected(redirected) |
| 06:36.16 | snuff-work | i think that will just blow up in my face |
| 06:36.49 | wedhorn | need a bit of excitement occasionally :o |
| 06:37.09 | snuff-work | soon.. taking a quick review of chan_sip belly |
| 06:41.00 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 06:41.00 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 06:55.53 | *** join/#asterisk-dev oej (~Adium@212.214.188.18) |
| 06:55.53 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:14.03 | snuff-work | lol.. |
| 07:17.21 | snuff-work | did a transfer via sip.. rather than a 302.. didn't look good.. testing without my patch |
| 07:18.49 | wedhorn | had a look at chan_int_api and it looks *difficult* to get the final chan info |
| 07:20.05 | snuff-work | interesting looking call when u transfer from jitsi.. |
| 07:20.06 | wedhorn | arguably you could get around it by setting callerid minus the extra zero (as per your stuff yesterday). Not sure on the impact of other stuff |
| 07:21.13 | snuff-work | so.. skinny -> sip answer ( then a 183/181 transfer) -> sip (mob number) -> trash.. in connected/effective line id name |
| 07:22.01 | wedhorn | maybe some testing to see if redir is valid |
| 07:22.15 | wedhorn | are you getting the redir indications in your log? |
| 07:22.19 | snuff-work | gotta run.. cutting too close |
| 07:22.23 | wedhorn | okay |
| 07:43.40 | *** join/#asterisk-dev sergee (~serg@195.112.98.167) |
| 07:46.49 | sergee | Hello everybody (if any one awake :)) A little question i've been struggling with: i have a call from SIP/voipgw to SIP/123, then SIP/123 redirects call (302 moved temp), to 456, so Asterisk spawns channel Local/456@context - and this channel goes to my app, |
| 07:47.50 | sergee | is there any way to get original channel that sent redirect (SIP/123 in my case) throug ast_channel structure of Local/456@context? Thank you in advance |
| 07:51.21 | *** join/#asterisk-dev bulkorok (~bulkorok@85.183.36.36) |
| 07:54.18 | *** join/#asterisk-dev oej (~Adium@195-67-63-194.customer.telia.com) |
| 07:54.18 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:08.27 | *** part/#asterisk-dev sergee (~serg@195.112.98.167) |
| 08:08.42 | *** join/#asterisk-dev sergee (~serg@195.112.98.167) |
| 09:56.59 | *** join/#asterisk-dev oron_laptop (~oron_lapt@local.xorcom.com) |
| 10:00.41 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 10:00.41 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 11:18.35 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 12:14.42 | Greenlight | Should "ast_verbose" print to the CLI under any level of verbosity other than 0 ? |
| 12:17.25 | file | erm is configure broken in 11 for anyone else? |
| 12:18.54 | file | Greenlight, it takes the verbosity level specified in the log message into account - better to use ast_verb though |
| 12:56.38 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 12:56.38 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:30.02 | *** part/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 13:55.23 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-zpcgsfdvufcpiums) |
| 14:08.46 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 14:08.46 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 14:45.03 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-vumstxmldqqlvcdh) |
| 14:45.03 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:10.41 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:10.41 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:13.59 | *** join/#asterisk-dev serafie1 (~erin@nat/digium/x-gvdieivftmbjahjx) |
| 15:27.12 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:27.12 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:33.19 | *** join/#asterisk-dev coreyf1513 (~cfarrell@ws2.cfware.com) |
| 16:01.53 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 16:01.53 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 16:03.07 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-hygefshlumrfmjbw) |
| 16:08.32 | *** join/#asterisk-dev AllThumbs (~hughjanus@173.10.248.1) |
| 16:16.02 | *** join/#asterisk-dev AllThumbs (~hughjanus@173.10.248.1) |
| 16:16.49 | *** join/#asterisk-dev AllThumbs (~hughjanus@173.10.248.1) |
| 16:36.56 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 16:42.44 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 17:13.13 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 17:13.13 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 18:49.27 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 18:59.03 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 18:59.04 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:18.34 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 19:18.34 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 19:45.54 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 19:45.54 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:04.06 | *** part/#asterisk-dev sergee (~serg@195.112.98.167) |
| 20:25.39 | *** join/#asterisk-dev dpilon (~dpilon@c-50-138-178-238.hsd1.ct.comcast.net) |
| 20:50.37 | wedhorn | snuff-work: Here's a start on the callinfo during sip to sip fwd https://issues.asterisk.org/jira/browse/ASTERISK-21177 |
| 21:47.13 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 21:47.14 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 22:10.39 | *** join/#asterisk-dev oron_laptop (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 22:25.41 | snuff-work | wow.. that's lot less callinfo spam :) |
| 22:36.15 | snuff-work | mm.. any1 compile trunk recently and have no xml doco within * ? |
| 22:39.52 | mjordan | file: putnopvut: do we want to support Remote-Party-ID still? |
| 22:39.59 | mjordan | in chan_gulp, I mean. chan_sip is a lost cause. |
| 22:40.02 | file | yes |
| 22:40.10 | file | (imo) |
| 22:40.21 | snuff-work | u can't take a feature away.. blasphemy :) |
| 22:40.28 | putnopvut | mjordan: yes here as well. |
| 22:40.51 | mjordan | drat. |
| 22:40.54 | putnopvut | We'll just want to default to using P-Asserted-Identity because that's more standard |
| 22:40.58 | mjordan | snuff-work: a feature without an RFC |
| 22:41.12 | snuff-work | ah.. so its not 'offical' |
| 22:41.12 | putnopvut | *coug* Diversion *cough* |
| 22:42.02 | snuff-work | any1 on my XML doc question? |
| 22:42.36 | snuff-work | i've recompiled few times lately.. and my * console no longer shows up doco when doing 'core show function callerid' etc |
| 22:42.44 | mjordan | snuff-work: hm. |
| 22:42.58 | mjordan | snuff-work: are you getting any validation errors? |
| 22:43.21 | snuff-work | i haven't installed xmlint etc.. so haven't checked |
| 22:43.51 | mjordan | you could try a 'make full' as well. That's more quirky, so if there is an error it's more likely to blow up. |
| 22:44.09 | mjordan | is checking now |
| 22:44.19 | mjordan | usually the test suite will explode if there's an XML documentation error |
| 22:45.08 | snuff-work | i've had xml doc errors since 25th feb |
| 22:45.42 | snuff-work | but my messages file for * doesn't go back any further |
| 22:47.45 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 22:47.45 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 22:49.24 | mjordan | snuff-work: http://pastebin.com/KyMEySUp |
| 22:49.39 | snuff-work | :( |
| 22:49.45 | snuff-work | must be something not right on mine |
| 22:50.13 | snuff-work | mm a make full finally rebuilt doco |
| 22:51.37 | snuff-work | thanks for making sure i wasn't going nuts ;) |
| 22:51.41 | mjordan | so, awhile back a patch was added that adds XML documentation support for config options. It's possible that it messed something up, or at least might have during an svn update... but I'm not sure how |
| 22:53.11 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-vumstxmldqqlvcdh) |
| 22:53.57 | snuff-work | mm.. seems only on a 'make full'.. does it want to rebuild the doc |
| 23:40.27 | snuff-work | is not loving chan_sip transfer |
| 23:44.32 | file | nobody does |
| 23:46.04 | snuff-work | my issue.. it sets cid->name = some via crap.. and.. keeps the cid->num to itself even though its going to 'p->username' |
| 23:46.35 | snuff-work | but i'm going to hack up chan_sip for refer's.. and see if i can bend it to my will without breaking everything |
| 23:46.50 | snuff-work | aka approx line 6393 |
| 23:47.05 | snuff-work | does ur new chan_gulp handle 183's better? |