| 02:49.40 | *** join/#asterisk-dev seraphie (~erin@75.76.38.159) |
| 05:35.48 | *** join/#asterisk-dev irroot (~gregory@197.173.125.233) |
| 06:46.17 | *** join/#asterisk-dev irroot (~gregory@197.175.69.203) |
| 07:47.18 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:47.18 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:47.49 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 08:01.11 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 08:01.12 | schmidts | good morning |
| 08:12.41 | irroot | morning kind sir |
| 08:49.04 | schmidts | what do you think, if asterisk does a native bridge between two sip channels should the rtp seqno should be used from the left channel or the right? |
| 08:49.39 | schmidts | what i mean, i have one client (left side) and another asterisk server (right side) and i can see that the asterisk in the middle first sent the rtp seqno just as normal |
| 08:50.11 | schmidts | but after asterisk starts the native bridge the seqno from the left side (client) is forwarded to the right side, so i can see a change in the seqno |
| 08:50.19 | schmidts | this leads to the wrong lost counter values |
| 08:52.43 | *** join/#asterisk-dev irroot (~gregory@197.111.202.166) |
| 08:52.54 | schmidts | and maybe also to the one way audio my customers complain about sometimes |
| 08:54.18 | schmidts | with native bridge i mean local bridging |
| 08:56.20 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 09:46.20 | *** join/#asterisk-dev irroot (~gregory@197.109.50.234) |
| 09:48.21 | *** join/#asterisk-dev irroot (~gregory@197.104.137.168) |
| 10:05.03 | schmidts | i see something else what is strange, when i have rtp debug running on the server in between, i see two RTP got and two RTP send to both channels but when asterisk bridges both channels together i only see two sent rtp to both channels but no got anymore |
| 10:32.51 | *** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10) |
| 10:43.31 | *** join/#asterisk-dev fazool (~ada_has@203.130.22.202) |
| 10:43.56 | fazool | i am faceing a problem |
| 10:44.04 | fazool | <PROTECTED> |
| 10:44.27 | fazool | and i want to add blind transfer feature in queue |
| 10:45.14 | fazool | e.g Agent A recives the incomming queue call and he wants to transfer it to agent B |
| 10:45.46 | fazool | whent Agent A rungs An agent called event raised in asterisk.net library |
| 10:46.40 | fazool | but when agent A transfer call to Agent B i am not getting any event from asterisk.net 1.4 library |
| 10:46.46 | fazool | plz help me |
| 10:55.25 | *** join/#asterisk-dev irroot (~gregory@197.174.65.77) |
| 11:00.37 | schmidts | fazool its not that we dont want to help you, we are just not able to help you cause we dont know asterisk.net library |
| 11:11.36 | *** join/#asterisk-dev irroot (~gregory@197.106.254.79) |
| 11:16.28 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:16.28 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:18.06 | *** join/#asterisk-dev irroot (~gregory@197.175.29.107) |
| 11:19.21 | schmidts | Morning kpfleming |
| 11:19.47 | schmidts | there is an interesting regression in 1.8 with rtp set debug ip |
| 11:20.21 | kpfleming | morning |
| 11:20.36 | kpfleming | my brain is still trying to return to my home time zone |
| 11:20.45 | schmidts | :D |
| 11:22.29 | *** join/#asterisk-dev irroot (~gregory@197.106.242.96) |
| 11:22.47 | schmidts | the problem i have found is that rtp set debug ip also needs a port to work proberly, only the ip isnt enough any more |
| 11:23.10 | kpfleming | well, that's bad |
| 11:23.32 | schmidts | i have allready found how to fix this, but then the optional port check doesnt work anymore |
| 11:25.44 | schmidts | the problem is the ast_sockaddr_cmp function which also looks at the port. if i change this to ast_sockaddr_cmp_addr then the port is not checked anymore |
| 11:29.20 | *** join/#asterisk-dev irroot (~gregory@197.109.93.78) |
| 11:29.38 | kpfleming | so you'll have to call a different function depending on whether the optional port to be checked has been supplied or not |
| 11:30.50 | schmidts | it looks like this, yes |
| 12:12.25 | schmidts | and so its not a simple two lines changes but also not much more than 30 rows :D |
| 12:22.31 | *** join/#asterisk-dev irroot (~gregory@197.175.243.233) |
| 13:05.56 | schmidts | kpfleming maybe you can answer me this question, is it normal for asterisk when doing a local bridge to forward the seqno of the incoming rtp packet also to the other channel? |
| 13:08.07 | *** join/#asterisk-dev irroot (~gregory@197.104.63.34) |
| 13:16.51 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-cmqjppfsktgxkukl) |
| 13:16.51 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:31.02 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 14:01.50 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 14:04.19 | schmidts | wdoekes2 next version is up ;) |
| 14:07.05 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 14:07.05 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 14:20.30 | wdoekes2 | schmidts: ship-it! but don't forget to remove the else |
| 14:20.57 | schmidts | which else? |
| 14:21.27 | wdoekes2 | the else which is always ran if we didn't return early |
| 14:21.42 | wdoekes2 | s/} else {// |
| 14:22.00 | schmidts | not so good idea to do this on the whole file i guess :D |
| 14:22.08 | wdoekes2 | haha |
| 14:22.14 | schmidts | ok got it |
| 14:30.12 | schmidts | thank you wdoekes2 ;) |
| 14:39.25 | wdoekes2 | np :) thanks for fixing |
| 14:39.58 | schmidts | i was searching for my problem with changing seqnumbers in rtp streams and i have found this issue, and its something i have also noticed |
| 14:40.13 | schmidts | first i though it would be only a two rows fast fix but you know :D |
| 14:45.49 | *** join/#asterisk-dev elguero_ (42d38dae@gateway/web/freenode/ip.66.211.141.174) |
| 14:56.37 | *** join/#asterisk-dev russellb (~russellb@asterisk/contributor-and-cool-guy/russellb) |
| 14:56.37 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 14:57.02 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-cmqjppfsktgxkukl) |
| 15:02.50 | *** join/#asterisk-dev irroot (~gregory@197.105.52.203) |
| 15:03.31 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:03.31 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:19.41 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 15:19.41 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 15:24.53 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:24.53 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 15:31.24 | schmidts | which developer has the hands on rtp and mostly rtcp handling? |
| 15:32.11 | leifmadsen | oej did some work on rtcp a while ago I think |
| 15:32.25 | leifmadsen | changes are in one of his pinecrazy branches |
| 15:32.25 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 15:32.25 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:32.33 | schmidts | leifmadsen i know, i have allready talked to him but not with 1.8 :D |
| 15:32.43 | leifmadsen | right he doesn't do much past 1.4 |
| 15:33.22 | schmidts | cause when i understand RFC 3550 appendix A.1 right then asterisk sends a wrong rtcp message when a seqno changes |
| 15:33.29 | *** part/#asterisk-dev russellb (~russellb@asterisk/contributor-and-cool-guy/russellb) |
| 15:35.38 | schmidts | and this can easy happens when two channels are local bridged without any transcoding done, see issue 18455 for this |
| 15:37.53 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 15:37.53 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 15:41.23 | seanbright | if i threw a bare (no modules) AEX410 into a machine, would dahdi use the card for timing? |
| 15:43.57 | opticron | it would still bring up a span (just an empty one), so yes it should |
| 15:48.10 | seanbright | alrighty |
| 16:00.19 | sruffell | seanbright: you shouldn't need to though.... |
| 16:00.37 | sruffell | if the server keeps good wall time…it doesn't add anything really. |
| 16:02.09 | seanbright | on one machine where iax trunking results in acceptable audio, we have an analog card (aex410) |
| 16:02.31 | seanbright | dahdi_test gives us: Best: 100.000 -- Worst: 99.992 -- Average: 99.997207, Difference: 99.997537 |
| 16:03.26 | seanbright | on another (more powerful) machine with core timing (no card) and less channels, we're getting: Best: 99.614 -- Worst: 99.410 -- Average: 99.540116, Difference: 99.952930 |
| 16:03.46 | seanbright | and iax trunking doesn't work so well |
| 16:04.13 | seanbright | sounds like packets are being dropped, the 'robot' voice, etc. |
| 16:04.41 | seanbright | this is with 2.5.0.2 |
| 16:05.03 | seanbright | so we're looking for the culprit and we are leaning towards timing |
| 16:07.02 | seanbright | sruffell: red herring? |
| 16:13.09 | *** part/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 16:32.24 | *** join/#asterisk-dev moy (~moy@216.172.42.74) |
| 17:02.49 | *** join/#asterisk-dev outtolunc (~outtolunc@adsl-66-218-53-172.dslextreme.com) |
| 17:19.37 | *** join/#asterisk-dev elguero_ (42d38dae@gateway/web/freenode/ip.66.211.141.174) |
| 17:39.16 | *** join/#asterisk-dev Tim_Toady (~fuzzy@195.74.239.171.dsl.dyn.forthnet.gr) |
| 17:49.46 | *** join/#asterisk-dev Netgeeks (~chris@gw1.netgeeks.net) |
| 18:08.39 | seanbright | sruffell: any thoughts? |
| 18:08.57 | sruffell | sruffell: ahh…sorry….stepped away...reading... |
| 18:09.09 | seanbright | do the dahdi_test numbers with core timing look like what you would expect? |
| 18:10.38 | sruffell | hmm..not really. I wonder what dahdi test says when run with the -v option. |
| 18:10.51 | seanbright | 1 moment |
| 18:12.42 | seanbright | dahdi_cfg -v: http://pastebin.com/raw.php?i=BFk0PhCG |
| 18:13.12 | seanbright | kernel conf: http://pastebin.com/raw.php?i=cubRtqJU |
| 18:13.20 | sruffell | ahh..so that looks reasononable…the difference is 99.998 |
| 18:14.05 | *** join/#asterisk-dev chazzam (~chazz@173-24-236-90.client.mchsi.com) |
| 18:14.12 | sruffell | So I could be mistaken…but I would be very surprised if adding a timing card fixes whatever the problem is. |
| 18:14.23 | seanbright | that's good enough for me |
| 18:16.06 | seanbright | you should suggest to the hardware team that they add timing to the transcoder cards as an option |
| 18:16.20 | kpfleming | it's not possible. we already talked about it. |
| 18:16.24 | seanbright | damn |
| 18:17.09 | seanbright | standalone card? |
| 18:17.12 | seanbright | :-) |
| 18:18.57 | sruffell | I would be really, really surprised if a hardware only timing card provides anything the system can't if it keeps good wall time. |
| 18:18.58 | kpfleming | really? modern linux kernels can provide suitable timing on their own |
| 18:20.16 | seanbright | ok, then i'm chasing down the wrong thing |
| 18:22.00 | sruffell | seanbright: NTP is installed and the clock isn't drifting? |
| 18:22.33 | seanbright | ntp was not installed |
| 18:22.37 | seanbright | just installed it |
| 18:23.05 | kpfleming | but that won't affect timing |
| 18:23.31 | kpfleming | and with ntp installed, any hardware clock drift will be masked by ntp adjusting the wall clock time |
| 18:25.18 | sruffell | The core timer uses the call clock though to determine how many "samples" to process. So if the clock is drifting too much..there will be drops. Although it would have to be drifting by alot to really notice anything I think. |
| 18:25.34 | kpfleming | ahh... interesting |
| 18:29.50 | seanbright | ok, thanks for your help guys |
| 19:16.42 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 19:16.42 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 19:17.18 | *** join/#asterisk-dev moy (~moy@173.239.155.74) |
| 19:20.07 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 19:23.50 | *** join/#asterisk-dev joshaidan (~brianj@S0106001c1023e838.tb.shawcable.net) |
| 20:01.05 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 20:01.05 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:04.41 | *** join/#asterisk-dev ArtemMakhutov (~ArtemMakh@ip-95-223-215-71.unitymediagroup.de) |
| 20:30.11 | ArtemMakhutov | what is ast_format_append in asterisk 10 intended to be for? |
| 20:30.25 | kpfleming | is it not documented? |
| 20:32.26 | ArtemMakhutov | the documentation is litte poor |
| 20:33.00 | ArtemMakhutov | I am trying to add H264 video parameters |
| 20:34.18 | ArtemMakhutov | I set them using "ast_format_append(format, H264_ATTR_KEY_PACKETIZATION_MODE, packetization_mode, ...." and later want to retrieve them with ast_format_get_value(format, H264_ATTR_KEY_PROFILE_LEVEL_ID, &profile_level_id) ... |
| 20:35.09 | kpfleming | probably only david vossel would be able to answer that, and he's not on line at the moment (we're all in a group meeting) |
| 20:35.40 | ArtemMakhutov | but this does not return what I have set during a call but only what was set during initialization in main/format.c |
| 20:36.24 | ArtemMakhutov | ok |
| 21:08.30 | tzanger | hm |
| 21:08.53 | tzanger | would it be considered stupidly bad to use a hash of a sip peer's nonce as the peername for autocreatepeer peers? |
| 21:09.13 | tzanger | looking at the condition where sip device a uses username=phone1 and sip device b uses the same username |
| 21:09.14 | kpfleming | eh? a peer doesn't 'have' a nonce. |
| 21:09.47 | tzanger | I'm looking at register_verify |
| 21:09.53 | tzanger | just reading the doc at the top fo the function |
| 21:10.17 | kpfleming | that will change every time they register, and the nonce is generated by Asterisk, not by the peer |
| 21:10.28 | tzanger | yes, that's exactly what I"m after |
| 21:10.38 | tzanger | something unique and generated by asterisk, not the device |
| 21:10.52 | kpfleming | then just use it... there's no need to hash it again |
| 21:11.08 | tzanger | if they re-register then yeah, it's entirely acceptable to treat them as a new device |
| 21:11.47 | tzanger | hash was probably a wrong word. I meant something alphanumeric to refer to it as (similar to user=) |
| 21:12.46 | tzanger | is this a big enough problem that a patch would be considered for inclusion, or does this break the idea of autocreatepeer using the username from the device? |
| 21:13.58 | kpfleming | how would the 'stale' peers be reaped? |
| 21:14.17 | kpfleming | regardless though, i suppose a 'random peer name' option would be acceptable |
| 21:15.42 | tzanger | kpfleming: I saw something about reaping in the sip.conf example, moment... |
| 21:18.18 | tzanger | autocreatepeer with a db backend (realtime) woudl work very well for reaping |
| 21:18.34 | kpfleming | ok |
| 21:19.09 | tzanger | ahh that's already in there... rtautoclear |
| 21:19.24 | tzanger | er no that's something else. ignore me. :-) |
| 21:19.53 | tzanger | added the task to write the autocreatepeer=random patch |
| 21:24.53 | *** part/#asterisk-dev ArtemMakhutov (~ArtemMakh@ip-95-223-215-71.unitymediagroup.de) |
| 21:27.48 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-hawqurajzsytgtcc) |
| 21:27.48 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 21:45.20 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-hawqurajzsytgtcc) |
| 21:50.24 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 21:50.24 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 21:52.58 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-huehabtyugykoevd) |
| 21:52.58 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 21:57.30 | *** join/#asterisk-dev happylife (~happylife@212.92.145.7) |
| 22:18.55 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 22:18.55 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 22:56.05 | snuff-work | wedhorn: ping? |
| 23:18.24 | Corydon76-home | tzanger: Might be just me, but the deterministic part of me shudders at using random strings. Would using a hexadecimal address be better? |
| 23:18.58 | Corydon76-home | There's a nonzero chance when using random strings that you will get a collision of values. |
| 23:21.32 | tzanger | True. I was just thinking of using the nonce but it might not exist |
| 23:22.25 | tzanger | The address of the allocated struct might be nice, but is that something thats good enough across platforms and with realtime? |
| 23:32.27 | Corydon76-home | Sure, because the issue is ensuring that it's not coincident |
| 23:33.27 | Corydon76-home | I think we currently do the same thing with channel name -- the 8-char (or 16-char) suffix is the address of the channel struct. |
| 23:38.33 | tzanger | Ok, I'll keep that in mind. Thanks! |