| 00:10.23 | *** part/#asterisk kharwell (kharwell@nat/digium/x-tbsqtspdnbjotuol) |
| 00:12.28 | *** join/#asterisk rpifan_ (~rpifan@ipb218f0be.dynamic.kabel-deutschland.de) |
| 00:21.00 | *** join/#asterisk overyander (~jeff@209.141.208.197) |
| 00:23.42 | *** join/#asterisk rpifan_ (~rpifan@178.24.240.223) |
| 00:27.14 | *** join/#asterisk paulgrmn_ (~paulgrmn@c-68-34-113-42.hsd1.mi.comcast.net) |
| 00:32.22 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-128-59.satx.res.rr.com) |
| 00:39.02 | *** join/#asterisk mhache (~mhache_@vps1.mhache.name) |
| 00:40.37 | *** join/#asterisk shootbird (~quassel@beepbeep.serverpit.com) |
| 01:35.39 | life_of_e | When a video enabled endpoint calls another, my understanding is that Asterisk is supposed to just pass through the video related SIP data so that the direct video media link is established, correct? Is there a way within the dial plan (or external to the dial plan but triggered by it) to snag that video related data? |
| 01:36.58 | life_of_e | The idea being a video doorbell that autodials. I wanted to trigger an external viewer application if the doorbell rang. |
| 01:40.20 | Samot | As far as I know, video is pass-thru. It doesn't touch it. |
| 01:40.38 | Samot | Nothing to originate a video call. |
| 01:40.52 | Samot | Because it would need to come from a local channel. |
| 01:42.11 | Samot | life_of_e: Might be possible to originate the call to one endpoint and when it answers, dial the other and have them set to start video after answer... |
| 01:42.19 | Samot | Or that may be how it works now.. |
| 01:42.43 | Samot | So you might be able to do it with a regular call and let the endpoints switch to video after established. |
| 01:43.46 | life_of_e | Ok, the hope was to detect that the endpoint was a video unit so that I could fire up a viewer like VLC elsewhere (not necessarily on a video enabled receiving endpoint) |
| 01:45.08 | life_of_e | I guess the other way to do it is to detect which endpoint is calling and just maintain the ID of the video enabled devices within the dialplan (global variables) then trigger on a match. |
| 01:45.59 | life_of_e | I was aiming for the semi-automatic approach if it existed ("hey, there's video in this call") |
| 01:46.51 | life_of_e | None of my phones do video, only the doorbell |
| 01:53.24 | *** join/#asterisk Janos (~Janos@201.204.94.76) |
| 02:07.14 | *** join/#asterisk JonathanD (~JonathanD@freenode/staff/jonathand) |
| 03:20.15 | *** join/#asterisk t1k3 (~t1k3@pool-71-112-160-141.pitbpa.fios.verizon.net) |
| 04:01.15 | *** join/#asterisk t1k3 (~t1k3@pool-71-112-160-141.pitbpa.fios.verizon.net) |
| 04:37.30 | *** join/#asterisk t1k3 (~t1k3@pool-71-112-160-141.pitbpa.fios.verizon.net) |
| 05:02.03 | *** join/#asterisk duo_kali (b61e88f0@gateway/web/freenode/ip.182.30.136.240) |
| 05:49.15 | *** join/#asterisk Da-Geek (~Da-Geek@176.203.79.135) |
| 06:07.27 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 06:42.26 | *** join/#asterisk gugaua (~gugaua@unaffiliated/gugaua) |
| 07:29.04 | *** join/#asterisk pchero_work (~pchero@87.213.240.121) |
| 07:37.27 | *** join/#asterisk Janos (~Janos@201.204.94.76) |
| 08:00.49 | *** join/#asterisk Da-Geek_ (~Da-Geek@176.203.79.135) |
| 08:01.00 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
| 09:00.34 | *** join/#asterisk miralin (~Thunderbi@81.177.57.153) |
| 09:52.05 | *** join/#asterisk pchero_work (~pchero@51.247.195.35.bc.googleusercontent.com) |
| 10:41.45 | *** join/#asterisk [J]oules (uid223833@gateway/web/irccloud.com/x-bebkfvgmpbgfmcmt) |
| 10:53.22 | *** join/#asterisk pchero_work (~pchero@87.213.240.121) |
| 11:03.47 | *** join/#asterisk Chainsaw (~chainsaw@gentoo/developer/chainsaw) |
| 11:46.59 | *** join/#asterisk lankanmon (~LKNnet@CPE64777d632383-CM64777d632380.cpe.net.cable.rogers.com) |
| 12:01.35 | *** join/#asterisk jkroon (~jkroon@196-210-6-134.dynamic.isadsl.co.za) |
| 12:07.05 | *** join/#asterisk K0HAX (~michael@gateway/tor-sasl/k0hax) |
| 12:12.10 | *** join/#asterisk pchero_work (~pchero@87.213.240.121) |
| 12:14.50 | *** join/#asterisk K0HAX (~michael@gateway/tor-sasl/k0hax) |
| 12:34.03 | *** join/#asterisk _0x5eb_ (~seb@seb-hpws2.w1.tele.crt1.net) |
| 12:35.37 | *** join/#asterisk guerby (~guerby@april/board/guerby) |
| 12:37.39 | *** join/#asterisk pchero_work (~pchero@51.247.195.35.bc.googleusercontent.com) |
| 12:46.34 | *** join/#asterisk TECFALL (~dschuett@38.121.113.66) |
| 13:03.53 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-128-59.satx.res.rr.com) |
| 13:10.23 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 13:33.04 | *** join/#asterisk rpifan (~rpifan@178.24.241.243) |
| 13:37.47 | TECFALL | Why do all my outbound calls log my external 10 digit number instead of the users' extensions? Example: https://pastebin.com/ZpTzFyZb |
| 13:38.27 | TECFALL | This is the only location that does this? Running asterisk 13.17.2. |
| 13:39.03 | *** join/#asterisk rpifan (~rpifan@178.24.240.130) |
| 13:41.54 | Samot | The callerid= setting only uses that CallerID if there is no CallerID present. |
| 13:42.51 | TECFALL | Samot: Right, but I'm not sure why it logs the correct information on all my other 5+ locations. |
| 13:43.06 | TECFALL | I would expect it to log the internal extension when making outbound calls. |
| 13:43.08 | Samot | Have you looked at a call? |
| 13:43.54 | TECFALL | Samot: not in depth with debug. Just in the console. |
| 13:44.04 | Samot | You're not showing anything. |
| 13:44.13 | Samot | You're saying it is doing things but you're not showing. |
| 13:45.42 | TECFALL | Samot: what is the command to set debug on a specific ext? |
| 13:45.48 | TECFALL | I can never remember |
| 13:46.02 | Samot | Just run the verbose commmand\ |
| 13:46.12 | Samot | This is about the dialplan not working so show what the dialplan is doing. |
| 13:46.31 | TECFALL | k, just one second |
| 13:59.06 | TECFALL | Samot: okay, weird. I must have been nuts the other day. All locations are doing the same thing except on an old asterisk 1.8 box. |
| 13:59.25 | Samot | I still don't see a debug. |
| 13:59.40 | Samot | It's been 10 minutes. |
| 13:59.43 | TECFALL | I don't know if there is one... |
| 13:59.44 | TECFALL | haha |
| 13:59.49 | Samot | You can't call? |
| 13:59.55 | Samot | You can't make a test call to make one? |
| 14:01.57 | TECFALL | Samot: https://pastebin.com/91bhbjYP |
| 14:02.27 | TECFALL | My guess is that this is what is causing it to log with the external number: CALLERID(num)=40241XXXXX") |
| 14:03.25 | Samot | So this is an outbound call, why shouldn't it have proper outbound CallerID? |
| 14:03.55 | TECFALL | It should, this is just for logging in the cdr to be able to identify what extension made the outbound call. |
| 14:04.06 | Samot | But you're not doing that. |
| 14:04.20 | TECFALL | Right, but I can't NOT set the correct outbound DID. |
| 14:04.32 | Samot | Why not?\ |
| 14:04.41 | Samot | You're running a script to set it.. |
| 14:04.42 | TECFALL | Samot: how would i go about that? |
| 14:04.49 | Samot | So why isn't the script pulling the proper details? |
| 14:05.30 | TECFALL | I don't believe setting caller id to an internal extension when I am dialing an outside number will work. |
| 14:05.39 | Samot | "CALLERID(num)=40241XXXXX" <-- That is the CallerID set. |
| 14:05.46 | *** join/#asterisk MLC (~MLC@63.249.40.11) |
| 14:05.57 | Samot | Why would you set the external CallerID to a local extension? |
| 14:06.06 | *** join/#asterisk Mr_Pleb_Mgoo (~jakeb@103.46.212.49) |
| 14:06.37 | file | you probably want to use an accountcode instead of relying on callerid... |
| 14:06.52 | Samot | He's not writing any extra stuff to CDRs. |
| 14:07.01 | Samot | He's not setting CDR(cnam=) |
| 14:07.14 | Samot | Or CDR(cnum)= |
| 14:07.15 | TECFALL | I think we are just having a misunderstanding. I want the callerID to show up on the end users' phones as it is... however for cdr logging purposes, it would be nice if it logged the src as the internal extension instead of the external CID. |
| 14:07.35 | Samot | Then you NEED to do that. |
| 14:07.39 | Samot | Which you are NOT. |
| 14:07.48 | Samot | I don't see any dialplan commands here to write CDR data. |
| 14:07.53 | Samot | Or set those fields. |
| 14:08.30 | TECFALL | Samot: I wasn't aware you could force set CDR fields in the dialplan. I will look into that |
| 14:08.37 | Samot | What? |
| 14:09.03 | file | you can set arbitrary ones, and you can set a few select built in ones, otherwise they are automatically set based on the channel and events that occur |
| 14:09.49 | TECFALL | file: do you know if you can set the src field? |
| 14:09.56 | file | you can't |
| 14:10.00 | Samot | exten => 1,n,Set(CDR(cnam)=My Name) |
| 14:10.23 | Samot | exten => n,Set(CDR(cnum)=785) |
| 14:10.41 | TECFALL | Samot: what fields do those set? |
| 14:10.47 | Samot | Uhm.\ |
| 14:10.50 | Samot | Wow. |
| 14:10.54 | TECFALL | Or are those fields? |
| 14:10.55 | Samot | Those set the cnam and cnum fields. |
| 14:10.56 | file | those are custom CDR variables |
| 14:11.00 | Samot | ^^^^ |
| 14:11.08 | TECFALL | I don't see them in my table |
| 14:11.12 | Samot | You may have to modify your CDR table to store the values you want. |
| 14:11.14 | Samot | Welcome to Aterisk. |
| 14:11.17 | Samot | Welcome to Asterisk. |
| 14:11.31 | TECFALL | Okay, so those are fields that I need to add. Got it. |
| 14:11.33 | file | or just use accountcode >_> |
| 14:11.39 | Samot | Or that. |
| 14:11.41 | TECFALL | okay |
| 14:12.05 | file | the purpose of accountcode is to have a value that the call is "billed" to in a way |
| 14:12.53 | file | setvar=CHANNEL(accountcode)=blah in sip.conf you can probably do |
| 14:12.55 | TECFALL | file: thanks. What is the userfield intended use? |
| 14:13.00 | file | whatever you want. |
| 14:13.08 | Samot | wiki.asterisk.org |
| 14:13.08 | file | it's an arbitrary opaque field for whatever you fancy |
| 14:13.16 | Samot | Now this is just getting to be "what is this" |
| 14:15.35 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
| 14:16.29 | TECFALL | Samot: sorry for being a inconvenience. |
| 14:19.20 | Samot | This isn't about my inconvenience. |
| 14:19.26 | Samot | This is about yours and your end users. |
| 14:19.44 | Samot | You just said you're running a half dozen boxes and these are very basic questions to be asking at this point. |
| 14:20.26 | TECFALL | file: I appreciate your help! |
| 14:21.45 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 14:23.39 | jkroon | does anybody know if there is a way in asterisk to deal with a call specially if a re-INVITE contains multiple codecs, specifically, G729, PCMA and udptl t38? It's a fax call (which obviously starts out as voice). |
| 14:24.34 | file | that's two streams |
| 14:24.43 | file | if it's within the same reinvite. |
| 14:24.44 | jkroon | normally if I detect fax tones (Set(FAXOPT(faxdetect)=yes)) it'll go to the fax extension from where I can pick up the fax, but if we get that on a reINVITE ... |
| 14:25.08 | jkroon | I really am starting to dislike broadsoft more and more. |
| 14:26.10 | Samot | Well you can't really do T38 over G729. |
| 14:26.13 | Samot | So that's just bad. |
| 14:26.21 | jkroon | i agree. |
| 14:26.30 | Samot | PCMA is fine. |
| 14:26.44 | jkroon | so we do detect fax tones in g729 and then switch to t38. broadsoft isn't playing ball on this. |
| 14:26.49 | Samot | So you don't want the call to negotiate g729 at all if you want to do fax. |
| 14:27.00 | jkroon | and in this case the far invite is initiating the re-invite before we can. |
| 14:27.03 | Samot | That's not how T38 works |
| 14:27.06 | Samot | At all. |
| 14:27.18 | Samot | It encapsulates the media packets. |
| 14:27.21 | Samot | It's not a codec. |
| 14:27.25 | jkroon | i know. |
| 14:27.35 | Samot | OK so then using G279 is the uderlying codec. |
| 14:27.39 | Samot | underlying |
| 14:27.45 | Samot | Which _does not work_ |
| 14:27.53 | jkroon | the call starts as a voice call. Once it's detected to be a fax, it drops the voice stream, and switches to udptl (t38). |
| 14:28.02 | Samot | It needs to switch CODECS |
| 14:28.24 | Samot | g729 is not correct. |
| 14:28.27 | Samot | It won't work |
| 14:28.35 | Samot | This is why Broadsoft isn't playing ball. |
| 14:28.39 | Samot | Because they are doing things properly. |
| 14:29.17 | jkroon | ok, so what you're saying is that if there is ANY chance of a call being fax to begin with you have to use G711 (pcma/pcmu)? |
| 14:29.25 | Samot | Since the start. |
| 14:29.26 | Samot | Yes. |
| 14:29.54 | Samot | Standard FAX lines are 64Kbps. |
| 14:29.58 | jkroon | is that because asterisk can't decode g729 to listen in for fax tones in order to initiate the switch to t38? |
| 14:30.13 | Samot | Because g729 is TOO compressed for T38 |
| 14:30.19 | Samot | Because faxes don't go that low. |
| 14:30.26 | Samot | Standard POTS lines are 64Kbps. |
| 14:30.26 | *** join/#asterisk cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:30.26 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 14:32.27 | Samot | g729 will compress your bandwidth. |
| 14:32.33 | Samot | In 2019 that's really not a need anymore |
| 14:32.58 | Samot | But g729 compresses the data beyond that of a standard analog line and thus reduces the abilities |
| 14:33.58 | Samot | This is a codec that had its hayday when 1.5Mbps/384Kbps DSL was still consider a "ultra fast" connection. |
| 14:34.31 | Samot | And T38 never worked over it. |
| 14:34.34 | Samot | Ever. |
| 14:38.02 | file | jkroon: it can't decode it reliably to detect such a thing - yes... so the originator instead sometimes does the T.38 switch... but it's messy, depends on the equipment in use, and I don't know what stuff is like these days |
| 14:41.32 | Chainsaw | jkroon: You lose the "CNG" tone in any compressed signal. |
| 14:41.44 | Chainsaw | jkroon: That's the signal it needs to start T.38 bypass. |
| 14:42.00 | Samot | Also T.38 is decided by the other side. |
| 14:42.05 | sibiria | if you're starved on bandwidth, really, use Opus instead |
| 14:42.09 | sibiria | g.729 is a nightmare |
| 14:42.13 | Samot | The outbound call is never T.38 to start with. |
| 14:42.13 | sibiria | a robotic nightmare |
| 14:42.16 | Samot | STOP |
| 14:42.18 | Samot | JFC. |
| 14:42.21 | Samot | It's about the compression. |
| 14:42.37 | Samot | If Opus does compression beyond a certain point it you're in the same boat. |
| 14:42.55 | Samot | You are compressing the data beyond what standard Analog Lines use. |
| 14:43.03 | Chainsaw | jkroon: I had T.38 working with Patton gateways, but I remember it being a right pig. |
| 14:43.08 | sibiria | my point is about the awful sound quality of g.729 |
| 14:43.11 | jkroon | Samot, the 64Kbps vs 8Kbps is exactly WHY it needs to switch. G.729 is OK for at least detecting it. |
| 14:43.34 | jkroon | @Chainsaw, I remember. I used one too at a point, but I can't pass 200+ concurrent calls through a patton device just to detect if there is faxes in there. |
| 14:43.38 | Samot | jkroon: Are these inbound faxes? |
| 14:43.48 | Samot | Or outbound faxes?\ |
| 14:44.04 | jkroon | Samot, normally it's voice calls. there are only a few where we detect the fax tones and then initiate a switch to t38. |
| 14:44.14 | Samot | So these are inbound faxes. |
| 14:44.21 | jkroon | inbound all of them, outbound is not an issue, we simply initiate the call with t38 to begin with. |
| 14:44.26 | sibiria | because g.729 is not suitable for transmitting that reliably |
| 14:44.28 | Samot | You don't but ok. |
| 14:44.28 | sibiria | just like it's not for DTMF |
| 14:44.36 | Chainsaw | Yeah, inbound faxes are exciting. Outbound is simple. |
| 14:44.38 | Samot | So show a full debug of a fax that doesn't get detected right. |
| 14:45.07 | Samot | 9:44:30 AM <sibiria> just like it's not for DTMF <-- because it can't do inband. |
| 14:45.30 | sibiria | this bears repeating: g.729 is not suited for transmitting fax tones or in-audio DTMF |
| 14:45.30 | jkroon | Samot, before we can detect the remote side is trying to switch, but offers g729 along with g711 (pcma specifically) and t38 in the same request, asterisk then sends back 603. I'll have to set up another test to get more details than that. |
| 14:45.40 | jkroon | sibiria, I AGREE. |
| 14:45.53 | jkroon | i've stated that, which is exactly why reINVITE is required. |
| 14:45.54 | Samot | Because they are probably expecting a T.38 with G711 fallback.\ |
| 14:46.01 | Samot | Like any normal system would for fax. |
| 14:47.08 | TECFALL | So I created a cnum and cname field in my cdr table and I am using exten => s,n,Set(CDR(cnam)=${CALLERID(name)}) to set the field, but it is not working. The console shows: Set("SIP/230-00018684", "CDR(cnam)=John Doe"), however the fields are not populated. |
| 14:47.31 | Samot | Did you reload things? |
| 14:47.38 | Samot | So that Asterisk can pickup the changes? |
| 14:47.39 | TECFALL | Samot: yes. |
| 14:48.05 | TECFALL | I can see it in the console as well, so I know the changes have taken affect. |
| 14:49.07 | *** join/#asterisk Janos (~Janos@201.204.94.76) |
| 14:50.10 | Samot | 9:45:55 AM <jkroon> i've stated that, which is exactly why reINVITE is required. <-- T.38 is also triggered by the receiving side. So the receiving side should also trigger a re-invite. What happens when you don't use g729? |
| 14:50.12 | Samot | Seriously? |
| 14:56.21 | *** join/#asterisk adhawkins (~adhawkins@musicbrainz/user/adhawkins) |
| 15:03.29 | *** join/#asterisk aness (~aness@cm-84.209.49.44.getinternet.no) |
| 15:03.36 | *** join/#asterisk adhawkins (~adhawkins@musicbrainz/user/adhawkins) |
| 15:06.00 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
| 15:13.30 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-128-59.satx.res.rr.com) |
| 15:29.24 | *** join/#asterisk kharwell (kharwell@nat/digium/x-qtgswmynvnqxeksf) |
| 15:29.24 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 15:49.30 | jkroon | Samot, nothing, initial call only comes with g729 offer. |
| 15:49.45 | Samot | I'm not seeing anything. |
| 15:50.11 | Samot | I'm not seeing this transaction of the INVITEs, what is being sent back and negotiated... |
| 15:50.48 | jkroon | when we detect the fax first the reINVITE works. if the initiating side sends reINVITE before we detect fax, it drops due to the 603. I'll have to rig a test to get you the additional data, the only variant i've got currently is a screen capture which one of the techs took which needs to be anonymized which I can't do in an image sensibly. |
| 15:50.59 | jkroon | so i'll revert once I've got appropriate information. |
| 15:51.30 | Samot | Why would the other side send a re-INVITE? |
| 16:42.07 | *** join/#asterisk Ai9zO5AP (~BQcdf9eiZ@91.240.67.45) |
| 16:49.14 | *** join/#asterisk clarjon1 (~clarjon1@unaffiliated/clarjon1) |
| 17:05.45 | *** join/#asterisk jkroon (~jkroon@165.16.204.42) |
| 17:08.51 | *** join/#asterisk rpifan_ (~rpifan@ipb218f082.dynamic.kabel-deutschland.de) |
| 17:20.17 | *** join/#asterisk clarjon1 (~clarjon1@unaffiliated/clarjon1) |
| 17:22.39 | *** join/#asterisk JonathanD (~JonathanD@freenode/staff/jonathand) |
| 18:15.33 | *** join/#asterisk tripleslash (~triplesla@unaffiliated/imsaguy) |
| 18:16.11 | *** join/#asterisk tripleslash (~triplesla@unaffiliated/imsaguy) |
| 18:38.05 | *** join/#asterisk remote (~remote@50.116.54.131) |
| 19:01.20 | *** join/#asterisk gugaua (~gugaua@unaffiliated/gugaua) |
| 19:06.12 | *** join/#asterisk Hyper_Eye (~mwoodj@pdpc/sponsor/digium/hyper-eye) |
| 19:21.52 | *** join/#asterisk rpifan (~rpifan@ipb218f082.dynamic.kabel-deutschland.de) |
| 19:34.16 | Samot | Hey @file, Asterisk still sets its own To/From headers despite the SIPAddHeader(From: something) or the PJSIP_HEADER command, correct? |
| 19:34.27 | file | yes |
| 19:34.32 | file | it has to, as there are tags and such |
| 19:34.39 | Samot | That's what I thought. |
| 19:34.49 | Samot | So it basically ignores anything set by SIPAddHeader |
| 19:35.06 | file | yes |
| 19:35.53 | Samot | But will accept the overrides for the peer such as from_header or the SIP dial string settings.... |
| 19:36.15 | Samot | So yeah, this guy is claiming he can set the From Header to what ever he wants using SIPAddHeader() and it works on 80 boxes. |
| 19:36.25 | Samot | So it's not working how he thinks it's working. |
| 19:36.45 | file | I don't remember chan_sip, it may be silly enough that it puts it in there - and then remote sides ignore it because of the placement |
| 19:39.21 | Samot | Probably. |
| 19:39.43 | Samot | Since that's how SIP headers work. |
| 19:40.17 | Samot | That would be From[1] basically and I can see that being dropped because they are looking only at From[0] or the top most entry. |
| 19:41.19 | *** join/#asterisk Posterdati (~Posterdat@95.239.219.102) |
| 19:41.21 | Posterdati | hi |
| 19:49.24 | *** join/#asterisk defsdoor (~Andrew@cpc120600-sutt6-2-0-cust232.19-1.cable.virginm.net) |
| 19:56.02 | wyoung | hi |
| 20:34.48 | Posterdati | please is there anyone know how to configure asterisk for italian TIM fibra VoIP, thanks! |
| 20:41.53 | *** join/#asterisk Jesterboxboy (~Thunderbi@89-26-27-17.stmi.voip.cablelink.at) |
| 20:51.52 | [TK]D-Fender | Posterdati, don't bet on anyone here knowing them specifically. |
| 20:52.18 | [TK]D-Fender | Posterdati, Have you tried doing the basics that other providers have given instructions on filling out? |
| 20:53.35 | Posterdati | no, I looked for specific instructions for TIM, but they are not working |
| 20:54.02 | [TK]D-Fender | what isn't working? |
| 20:54.19 | [TK]D-Fender | Your provider should tell you what their requirements are |
| 20:54.37 | Posterdati | the problem is that I have a gigaset a540-ip which do not allow > 32 chars registration password, so I decided to put asterisk in the lan |
| 20:55.03 | Posterdati | I (badly) configured asterisk and it cannot register to the VoIP service |
| 20:55.41 | Posterdati | I disabled SIP ALG and natted ports 5004 to 5020 inside the lan where the phone is |
| 20:56.55 | [TK]D-Fender | This hasn't described what you specifically configured or the errors in the comms. |
| 20:57.07 | [TK]D-Fender | If you are hoping for support you have show what's actually happening |
| 20:57.20 | [TK]D-Fender | And share the instructions that your provider should have given you |
| 20:57.21 | Posterdati | I configured the sip.conf file |
| 20:57.25 | Posterdati | with a general |
| 20:57.36 | Posterdati | and a [telecomitalia] entry |
| 21:00.07 | [TK]D-Fender | Show us the actual debug |
| 21:04.33 | Posterdati | ok |
| 21:04.57 | Posterdati | Feb 21 21:58:51] NOTICE[-1]: chan_sip.c:15906 sip_reg_timeout: -- Registration for '+39xxxx@telecomitalia.it' timed out, trying again (Attempt #39) |
| 21:05.02 | Posterdati | repeated |
| 21:06.17 | [TK]D-Fender | "sip set debug on" <- |
| 21:06.28 | [TK]D-Fender | You aren't looking at the full packets as you should be |
| 21:06.29 | [TK]D-Fender | ~pb |
| 21:06.30 | infobot | i heard pastebin is a web-based service where you should paste anything over 3 lines so you don't flood the channel. Here are links to a few: http://pastebin.ca, http://channels.debian.net/paste, http://paste.lisp.org, http://bin.cakephp.org/; or install pastebinit with yum or aptitude. |
| 21:06.31 | [TK]D-Fender | ^^^ |
| 21:11.55 | Posterdati | Retransmitting #4 (no NAT) to 156.54.82.96:5060: |
| 21:13.15 | [TK]D-Fender | PASTEBIN <----------------- |
| 21:13.23 | [TK]D-Fender | that single line is not "sip debug" |
| 21:13.32 | Posterdati | ok |
| 21:44.55 | *** join/#asterisk rpifan (~rpifan@ipb218f08e.dynamic.kabel-deutschland.de) |
| 21:53.10 | Posterdati | done! |
| 22:14.55 | *** join/#asterisk Kobaz (~kobaz@its.kobaz.net) |
| 22:18.14 | *** join/#asterisk kharwell (kharwell@nat/digium/x-piemeembtnrqztmy) |
| 22:18.14 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 22:19.18 | *** join/#asterisk as3ty (uid332392@gateway/web/irccloud.com/x-jboskyyydwryyfln) |
| 23:10.18 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |