| 00:32.21 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 00:32.21 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 00:47.40 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 00:47.40 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 01:06.05 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 01:06.05 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 01:28.53 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-aonzcochuwopjifn) |
| 02:33.05 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 02:33.05 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 03:03.50 | *** join/#asterisk-dev solitude88 (~solitude8@wsip-24-234-107-73.lv.lv.cox.net) |
| 05:42.12 | wedhorn | snuff-work: you get a chance to look at the 14a messages? |
| 05:44.29 | snuff-work | not much today.. i thought u had made an initial patch with it? |
| 05:44.51 | wedhorn | no, my patch was for 144 and 145 |
| 05:45.37 | snuff-work | i had started putting something together.. but had other 'real work' related things to look over |
| 05:46.07 | wedhorn | know what you mean, it's annoying when work gets in the way ... |
| 06:04.01 | snuff-work | sent u pm |
| 06:05.45 | snuff-work | mm.. now i'm not so sure.. bout parts of my struct.. looked at another msg of 0x14a |
| 06:05.46 | wedhorn | seems you're missing the first uint32 which I'd guess is instance |
| 06:06.11 | wedhorn | callid I'm trying to use callreference |
| 06:06.54 | wedhorn | yeah, I'm getting the callerid as 4 null terminated strings |
| 06:07.18 | wedhorn | then a gap |
| 06:07.28 | wedhorn | and 4 null terminated callnames |
| 06:08.43 | snuff-work | callid = call ref.. seems true.. |
| 06:09.11 | wedhorn | yeah, just find callid a bit confusing with callerid |
| 06:09.37 | snuff-work | mm.. we do need a cleanup of var names between structs :) |
| 06:09.59 | wedhorn | yep, chan skinny uses both callid and callreference interchangeably |
| 06:10.24 | snuff-work | well.. also.. callReference / reference |
| 06:11.35 | wedhorn | yeah yeah |
| 06:11.53 | wedhorn | issue being if you clean up trunk it makes it harder to merge stuff from 11 |
| 06:12.10 | snuff-work | true |
| 06:12.59 | snuff-work | oh u also wanted a outbound call |
| 06:13.16 | snuff-work | i will do a quick pcap of outbound see the 14a packet for that |
| 06:16.49 | wedhorn | also, I assume calltype is calldirection |
| 06:17.00 | snuff-work | yer |
| 06:19.06 | wedhorn | sure? it's 3 in your pastebin, only 1 and 2 are used in old callinfo (in=1 out=2) |
| 06:19.49 | snuff-work | ok.. in that 1.. its forward call (3) |
| 06:20.25 | snuff-work | when i answer it goes to callstate (1) |
| 06:21.09 | wedhorn | okay, then that may explain some of the other callerid/names (probably original called party and last redirecting party) |
| 06:22.18 | wedhorn | were the other pcaps you sent me forwarded as well? |
| 06:22.55 | snuff-work | if u have soft-callid2.. |
| 06:23.02 | snuff-work | u have the call i'm pasting from |
| 06:23.26 | snuff-work | outgoing call is a bit diff.. |
| 06:23.31 | snuff-work | unfortunately |
| 06:23.57 | wedhorn | how different? |
| 06:24.30 | snuff-work | will send u nother paste |
| 06:29.10 | snuff-work | i don't believe i have set a 'callerid name' on that phone |
| 06:29.47 | snuff-work | actually.. i think that's the 'test1' |
| 06:31.54 | wedhorn | it looks pretty similar, just a lot of nulls at the end for no name of the number 0410etc |
| 06:32.10 | snuff-work | mm |
| 06:32.12 | wedhorn | structurally anyway |
| 06:32.45 | wedhorn | couple of the vars at the beginning have different values, pretty sure everything else is the same |
| 06:33.04 | snuff-work | seems so |
| 06:33.39 | snuff-work | linename probably is callerid name in my 2nd paste |
| 06:33.43 | wedhorn | problem is the null terminated strings and callerid's rather than fixed width in the original message type |
| 06:34.07 | snuff-work | why is it such an issue? |
| 06:34.24 | snuff-work | u calc length via sizeof ? |
| 06:34.27 | wedhorn | yeah, none of your fixed char arrays will work |
| 06:35.08 | snuff-work | i just used a fixed array cause it seemed little 'clearer' to type |
| 06:35.33 | snuff-work | as u can tell the numbers are just random cept for the nulls.. |
| 06:35.46 | wedhorn | yep, but we need a single big space to put the 4 callerids null terminated, padded to mod4, 4 nulls, 4 callernames null terminated, padded to mod 4 |
| 06:36.10 | wedhorn | okay, appreciate that |
| 06:38.20 | wedhorn | if you have a look at line 50 of your last pastebin, offset 8 is null |
| 06:38.42 | wedhorn | that would appear to indicate that the callername for callerid 3209 is null |
| 06:39.00 | wedhorn | and that test1 is actually the callername in respect of the mobile no |
| 06:39.26 | wedhorn | but let me compare to other pcaps |
| 06:39.28 | snuff-work | test1 is not the name of the mobile.. ccm has no idea |
| 06:41.30 | snuff-work | confirmed via ccm.. |
| 06:42.13 | snuff-work | test 1 = callerid name / alertingname / description.. directory number is 3209 |
| 06:42.45 | snuff-work | the line is called 'line 1' on phone so that def doesn't have anything to do with it.. and was noise on my part :( |
| 06:43.00 | wedhorn | Test1 shows up in your prior pcap at the same place |
| 06:43.20 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 06:43.20 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 06:45.23 | wedhorn | actually, think i'm wrong about the padding, it appears to be a constant 4nulls (on top of the null terminating the prev str) |
| 06:45.33 | snuff-work | yes is is 4.. |
| 06:45.37 | snuff-work | *it is |
| 06:45.58 | snuff-work | i think i was wrong about some extra int in there.. |
| 06:45.59 | wedhorn | and it can show up at any offset (not only mod 4) |
| 06:47.17 | wedhorn | so that mean in the last pastebin that Test1 is in respect of 3209 |
| 06:47.27 | snuff-work | yes |
| 06:47.58 | wedhorn | so I guess the structure general operation is pretty similar to callinfov1, being fromcaller, tocaller, etc |
| 06:48.57 | snuff-work | lol.. a cat beat pro stock traders and some school students.. |
| 06:51.02 | wedhorn | on the stockmarket? in the shortrun it's just gambling |
| 06:52.41 | snuff-work | yep :) |
| 06:56.17 | *** join/#asterisk-dev schmidts (~schmidts@vie-086-059-105-021.dsl.sil.at) |
| 06:56.19 | schmidts | good morning |
| 07:06.52 | wedhorn | snuff-work: http://pastebin.com/ETz3gzdd |
| 07:09.46 | snuff-work | looks promising |
| 07:12.42 | snuff-work | looks like its.. clid num / xx /xx/ xx / 4 nulls / clid name / xx / xx /xx |
| 07:14.58 | wedhorn | for the chars yep |
| 07:17.32 | snuff-work | thought of another fun cleanup we can do later.. 'constify' function args :) |
| 07:21.35 | snuff-work | well i gotta go.. leave me a msg if u do some more.. |
| 07:24.23 | snuff-work | have 1 more pcap to look at later on |
| 07:49.46 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:347a:47af:5f65:4e1) |
| 08:05.20 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 09:05.24 | *** join/#asterisk-dev bombev (~bombev@PPPoE-Static-40-132.UnicsBG.Net) |
| 09:17.20 | *** join/#asterisk-dev alsuren (~dlaban@80.169.133.251) |
| 09:21.01 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 09:21.01 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 09:32.25 | *** join/#asterisk-dev alsuren (~dlaban@80.169.133.251) |
| 10:17.00 | wedhorn | snuff-home: sent you a 14a patch that seems to work |
| 11:04.10 | *** join/#asterisk-dev sustav (~vpp@76.73.166.16) |
| 11:09.18 | *** join/#asterisk-dev sustav (~vpp@76.73.166.16) |
| 12:06.08 | *** join/#asterisk-dev caio1982 (~caio1982@177.143.186.152) |
| 12:19.22 | *** join/#asterisk-dev caio1982 (~caio1982@189.125.242.3) |
| 12:50.55 | *** join/#asterisk-dev caio1982 (~caio1982@177.143.186.152) |
| 12:59.29 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 13:14.57 | *** join/#asterisk-dev solitude88 (~solitude8@wsip-24-234-107-73.lv.lv.cox.net) |
| 13:22.21 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-bstuiedhqlctgjwp) |
| 13:22.21 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:27.29 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 13:32.24 | mjordan | file: for chan_gulp, how are you planning on handling data passing between Asterisk and a SIP session? |
| 13:32.51 | file | queued tasks, but that hasn't been written yet |
| 13:32.56 | mjordan | ah |
| 13:32.59 | mjordan | yay! |
| 13:33.02 | file | well - there's stubs |
| 13:33.20 | mjordan | would really like to avoid the locking morass |
| 13:34.13 | file | shouldn't really be much locking at our level |
| 13:36.00 | mjordan | only when getting things off of a queue and putting things on it |
| 13:36.09 | file | right |
| 13:36.16 | mjordan | it may be worthwhile writing a queue wrapper around the AST_LIST macros |
| 13:37.05 | mjordan | for single producer/consumer, and have consumers block on obtaining an item off the queue until a producer puts something on it for them |
| 13:37.25 | mjordan | well; single consumer, multi producer |
| 13:38.42 | file | put it in your evening to-do list :P lol |
| 13:39.50 | mjordan | I will |
| 13:39.59 | mjordan | along with chan_mobile, apparently |
| 13:40.22 | file | that's a dangerous module to go into |
| 13:41.29 | mjordan | I'm holding my breath |
| 13:41.58 | file | you'll pass out! |
| 13:46.45 | *** join/#asterisk-dev solitude88 (~solitude8@wsip-24-234-107-73.lv.lv.cox.net) |
| 13:55.43 | *** join/#asterisk-dev sustav (~vpp@nat/digium/x-jswiicriymojxcac) |
| 13:55.45 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-nfqzyybmskarzztl) |
| 14:00.27 | leifmadsen | mjordan: why the masochism? |
| 14:00.41 | leifmadsen | I did notice a change towards SMS stuff last night |
| 14:01.42 | mjordan | community service |
| 14:02.02 | mjordan | was going through extended support issues and found a number with patches that people had tested and claimed fix problems. Some were one liners. |
| 14:04.10 | leifmadsen | nice |
| 14:04.12 | leifmadsen | well played sir |
| 14:32.54 | *** join/#asterisk-dev Tim_Toady (~fuzzy@194.50.55.245) |
| 14:36.01 | mjordan | file: phooey. I think we may be declining media incorrectly. |
| 14:36.13 | file | how so? |
| 14:36.30 | mjordan | I'm fairly sure you have to include at least one media attribute in a declined stream |
| 14:36.57 | file | I don't think so |
| 14:37.08 | leifmadsen | fight! fight! |
| 14:37.24 | leifmadsen | puts 10 pence on file |
| 14:37.54 | file | leifmadsen, I wouldn't! |
| 14:38.06 | leifmadsen | don't worry, it's a long shot bet .... odds are crazy |
| 14:38.08 | mjordan | "To reject an offered stream, the port number in the corresponding stream in the answer MUST be set to zero. Any media formats listed are ignored. At least one MUST be present, as specified by SDP." |
| 14:39.01 | file | but... an image stream doesn't have media formats |
| 14:39.19 | mjordan | it has attributes however. Not sure if it considers that equivalent or not. |
| 14:39.33 | file | I would hope not as they are vastly different |
| 14:39.35 | mjordan | fairly sure we don't put a media format in when we reject an audio/video stream either. |
| 14:40.30 | file | according to LE CODE we do |
| 14:42.30 | file | actually t38 is the media format for an image stream |
| 14:44.21 | mjordan | hm hm hm. I see us formatting the declined media stream, but add_sdp doesn't appear to add any attribute lines. I could be missing it however. |
| 14:44.55 | file | it doesn't add any attribute lines but media formats are specified in the m= line |
| 14:47.31 | mjordan | ah. |
| 14:47.35 | mjordan | phew. |
| 14:48.01 | mjordan | so... yeah. that should be fine then. |
| 14:56.41 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-uciqswblhddgykqe) |
| 15:25.53 | file | UAC, UAS, UAC, UAS, UAC, UAS |
| 15:30.19 | saghul | mjordan FWIW we remove everything from a declined stream (other than the m line) and have not ran into interop issues so far |
| 15:30.24 | saghul | knocks on wood |
| 15:30.51 | mjordan | I'm fairly sure that's what we used to do too. |
| 15:30.53 | file | yeah removing attributes is optional |
| 15:31.01 | mjordan | er, nm |
| 15:31.05 | mjordan | that is what we do :-P |
| 15:31.31 | mjordan | my brain kept on turning "media format" into "a=" lines for some reason. |
| 15:31.39 | mjordan | I blame lack of coffee. |
| 15:31.52 | file | offers saghul a session-initiate packet |
| 15:32.24 | saghul | kindly ignores it, for now :-) |
| 15:33.01 | file | apparently offering you that packet angered my connection to the Digium XMPP server |
| 15:33.32 | saghul | haha |
| 15:45.52 | file | Wednesday. |
| 15:48.58 | mjordan | indeed. |
| 16:24.43 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:28.56 | dwayne | putnopvut, nice work on the threadpool stuff |
| 16:31.06 | putnopvut | dwayne: thanks |
| 16:31.35 | Qwell | putnopvut: That's a "Ship it!" if I've ever seen one. |
| 16:31.43 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:31.44 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:56.25 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 16:56.25 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 17:12.59 | mjordan | Qwell: are there any modifications we've done to mxml that we still need for Asterisk? |
| 17:16.56 | Qwell | There has been 1 change to a .c file in its entire history, and some build system changes. |
| 17:18.07 | mjordan | hm. |
| 17:18.16 | mjordan | wonder if we could just remove it entirely |
| 17:19.16 | Qwell | I doubt it's packaged. |
| 17:20.24 | mjordan | http://rpmfind.net/linux/rpm2html/search.php?query=mxml-devel? |
| 17:20.28 | mjordan | http://rpmfind.net/linux/rpm2html/search.php?query=mxml-devel ? |
| 17:20.40 | *** join/#asterisk-dev solitude88 (~solitude8@wsip-24-234-107-73.lv.lv.cox.net) |
| 17:21.55 | mjordan | hm.. |
| 17:22.48 | Qwell | if anything, I'd say we just switch to libxml2 |
| 17:22.51 | mjordan | agreed. |
| 17:23.09 | Qwell | that's a later on thing though, IMO |
| 17:23.22 | Qwell | As far as tarballs are concerned, nothing will change right now. |
| 17:26.32 | mjordan | yup |
| 17:33.52 | *** join/#asterisk-dev caio1982 (~caio1982@177.143.186.152) |
| 17:38.09 | pabelanger | Y U NO LIKE ME AMI |
| 17:44.07 | leifmadsen | you smell |
| 17:49.28 | mjordan | pabelanger: ? |
| 17:52.04 | pabelanger | I use QueueMemeberRemove and asterisk removed the member, however asterisk then sends me an additional QueueMemberStatus about that member, from the queue they have just been removed from |
| 17:52.05 | pabelanger | http://pastebin.com/9ybdHAXD |
| 17:54.10 | Qwell | pabelanger: The latter timestamp is lower. |
| 17:54.36 | pabelanger | Qwell, Nice catch |
| 17:54.39 | pabelanger | just noticed that |
| 17:55.15 | tzanger | curses voip.ms |
| 17:55.39 | pabelanger | 5 points to gryffindor |
| 17:56.15 | tzanger | "so like your gateway indicates ring, doesn't actually ring the PSTN then after a second returns 503. Why?" <dumb look> "Set up your asterisk machine as per our web page." "It is." "Hmm." |
| 18:04.33 | pabelanger | Heh, network issues |
| 18:04.48 | pabelanger | which is odd, because both instances are local to each other on the same switch |
| 18:30.47 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 18:30.47 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 18:55.37 | file | putnopvut, I think for testing an endpoint identifier which just returns the same endpoint all the time is in order! |
| 19:00.35 | putnopvut | That sounds like an idea! |
| 19:30.17 | mjordan | file: but is it alice, or is it bob? |
| 19:30.26 | file | albob |
| 19:42.30 | file | res_sip_sdp_audio is coming along niiiiiiiiiice |
| 19:58.23 | *** join/#asterisk-dev rdegges (rdegges@ec2-54-242-122-21.compute-1.amazonaws.com) |
| 19:59.19 | rdegges | Yo dudes. |
| 20:16.12 | mjordan | file: resource module just for SDP audio? |
| 20:16.24 | file | mjordan, for now! it may move around |
| 20:16.34 | file | but I sorta wanted to show just how module this is :P |
| 20:16.41 | mjordan | awesome |
| 20:16.48 | file | or modular |
| 20:16.57 | leifmadsen | more mods! |
| 20:17.06 | file | so that if someone wanted to write a module for, oh I dunno, T.38 SDP handling that kept it completely self contained... |
| 20:17.12 | file | well it would be evident how |
| 20:17.46 | leifmadsen | module for every codec! |
| 20:17.55 | leifmadsen | module for every connection! |
| 20:18.05 | leifmadsen | dynamically create and load modules per channel! |
| 20:18.06 | file | leifmadsen, have you been drinking? |
| 20:18.11 | leifmadsen | file: ooooooooooooooh I wish |
| 20:44.43 | saghul | thinks about res_sip_sdp_msrp |
| 20:52.20 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 20:52.20 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 21:06.46 | *** join/#asterisk-dev solitude88 (~solitude8@wsip-24-234-107-73.lv.lv.cox.net) |
| 21:15.21 | Qwell | There. No more installing 50 lua packages. |
| 21:25.44 | mjordan | huzzah |
| 21:51.23 | pabelanger | Qwell, What was the reason for mxml and menuselect being externals again? Just because more then one project used it? |
| 21:51.44 | Qwell | It was used in at least 3 places, when it was created. |
| 22:21.00 | snuff-work | mm.. didn't know there was an install_prereq option |
| 22:27.06 | *** join/#asterisk-dev solitude88 (~solitude8@wsip-24-234-107-73.lv.lv.cox.net) |
| 22:31.15 | leifmadsen | yay no lua |
| 22:31.56 | leifmadsen | I'd recommend usage of install_prereq in the book if it wasn't so debian centric :) |
| 22:32.12 | mjordan | oh snap |
| 22:32.31 | leifmadsen | snaps with a sideways head bob |
| 22:32.58 | file | is that a... problem? |
| 22:45.07 | Qwell | leifmadsen: err? It works on RH too |
| 22:45.18 | Qwell | hell, it works on OpenBSD |
| 22:53.37 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 23:21.34 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-bstuiedhqlctgjwp) |