| 00:00.52 | *** part/#asterisk kharwell (kharwell@nat/digium/x-ebdnzceimopkpsyt) |
| 00:40.22 | *** join/#asterisk infobot (ibot@rikers.org) |
| 00:40.22 | *** topic/#asterisk is #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.14.0 (2017/02/13), 11.25.1 (2016/12/08), Standard: 14.3.0 (2017/02/13); DAHDI: DAHDI-linux 2.11.1 (2016/03/01), DAHDI-tools 2.11.1 (2016/03/01); libpri 1.6.0 (2017/01/27) -=- Wiki: wiki.asterisk.org -=- Code of Conduct: bit.ly/1hH6P22 -=- Logs: bit.ly/1s4AKKu |
| 00:40.24 | Samot | The only way to have a rateful |
| 00:40.44 | Samot | Stateful connection is TCP based |
| 00:40.52 | catphish | UDP is stateless, SIP is not UDP though :) |
| 00:41.17 | Samot | SIP uses UDP by default. |
| 00:41.25 | catphish | it does |
| 00:42.01 | catphish | just understand that this doesn't make it stateless |
| 00:42.18 | Samot | Huh |
| 00:42.42 | Samot | The only thing that can be Stateful is the transport |
| 00:42.54 | Samot | Media is always stateless |
| 00:43.00 | Samot | It's always UDP |
| 00:45.34 | catphish | let me disprove this with a very simple question. if a phone receives a BYE request, how does it know which call to hang up? |
| 00:45.55 | *** join/#asterisk dakudos (~dakudos@c-73-243-248-133.hsd1.co.comcast.net) |
| 00:46.31 | Samot | It's called transactions. |
| 00:46.36 | Samot | Each call has a Call ID |
| 00:46.41 | Samot | TO and FROM tags |
| 00:46.50 | Samot | Route Routes |
| 00:46.54 | Samot | Er Record Routes |
| 00:47.02 | Samot | All of these are using to handle the transactions. |
| 00:47.28 | Samot | SIP was designed and built using UDP as the primary transport. |
| 00:47.41 | Samot | TCP/TLS/WSS were all additions as SIP matured. |
| 00:47.47 | catphish | that is true, i'm just trying to explain that using UDP doesn't make it stateless |
| 00:48.10 | Samot | The only time a SIP connection is NOT stateless is when the transport is TLS/TCP/WSS |
| 00:48.15 | [TK]D-Fender | it isn't maintained by the TCP stack |
| 00:48.23 | Samot | Even then, only the signaling is stateful. |
| 00:48.30 | Samot | The RTP/media is still STATELESS |
| 00:48.36 | [TK]D-Fender | signaling is all that it is |
| 00:48.43 | [TK]D-Fender | SIP != RTP |
| 00:48.50 | Samot | I understand. |
| 00:48.51 | catphish | there are at least 2 levels of state, transaction, and dialog, that's before you consider registration to be a state |
| 00:48.54 | [TK]D-Fender | In other news apples are not oranges |
| 00:49.08 | Samot | A transaction is a REGISTER |
| 00:49.10 | Samot | OPTION |
| 00:49.14 | Samot | INVITE |
| 00:49.15 | [TK]D-Fender | This reminds me of arguments like "layer 2 switches are routers" |
| 00:49.23 | Samot | A dialog means the call has been accepted. |
| 00:49.35 | Samot | And it's an active call. |
| 00:49.41 | catphish | Samot: i don't understand how you think sip can be stateless, a call is a pretty clear example of a state machine |
| 00:49.49 | Samot | No it is not |
| 00:49.52 | Samot | At all. |
| 00:50.11 | Samot | The only time SIP is stateful is when its TCP/TLS/WSS |
| 00:50.41 | catphish | Samot: ok, well you never answered my qustion, if a phone received a BYE request, how does it know which call to end? |
| 00:50.43 | Samot | No one sets up a SIP proxy/router and says "I need to make this stateless" |
| 00:50.53 | Samot | 8:46:34 PM S<Samot> It's called transactions. |
| 00:50.55 | [TK]D-Fender | <catphish> Samot: ok, well you never answered my qustion, if a phone received a BYE request, how does it know which call to end? <- already answered. |
| 00:51.05 | Samot | 8:46:39 PM S<Samot> Each call has a Call ID |
| 00:51.05 | Samot | 8:46:44 PM S<Samot> TO and FROM tags |
| 00:51.28 | Samot | These are used to track a TRANSACTION or an ACTIVE DIALOG |
| 00:51.33 | catphish | Samot: right, but if there's no state, what can the phone possibly do with that information? |
| 00:51.40 | Samot | By the way, BYEs are out-of-dialog requests as well. |
| 00:51.46 | [TK]D-Fender | With what information? |
| 00:52.36 | catphish | the call id, from, and to |
| 00:52.52 | [TK]D-Fender | What can it do with them? |
| 00:53.04 | [TK]D-Fender | know what to do of course. |
| 00:53.07 | Samot | How does the device know what to do with that information? |
| 00:53.11 | Samot | It's SIP |
| 00:53.21 | catphish | the answer is that it looks up the call in its state table |
| 00:53.22 | Samot | Therefore if its a SIP phone, it knows what do with a SIP message. |
| 00:53.25 | Samot | And the contents. |
| 00:53.32 | Samot | ? |
| 00:53.35 | Samot | What state table? |
| 00:54.28 | catphish | there must be a state table in a phone, it must know what calls are ongoing, i don't know how better to explain that |
| 00:54.54 | Samot | If the phone is tracking things internally |
| 00:54.58 | catphish | it's impossible for a call-id to mean anything to a device unless it has a table of calls |
| 00:55.00 | Samot | That doesn't make it a stateful connection. |
| 00:55.12 | [TK]D-Fender | SIP is APPLICATION layer, not TRANSPORT |
| 00:55.18 | catphish | yes it is |
| 00:55.21 | [TK]D-Fender | \learn your OSI\ |
| 00:55.22 | Samot | There is that. |
| 00:55.32 | Samot | Regardless of the transport.. |
| 00:55.49 | catphish | the state is in the applications, the transport isn't important |
| 00:56.04 | Samot | OK |
| 00:56.10 | [TK]D-Fender | It is when your packets DISAPPEAR |
| 00:56.10 | catphish | and for proxies, state tracking is totally optional |
| 00:56.22 | catphish | but for endpoints, its not |
| 00:56.23 | Samot | No one sets up a voip network and says "We need to make this as stateless as possible" |
| 00:56.31 | [TK]D-Fender | No magic retransmit of your UDP |
| 00:56.41 | [TK]D-Fender | no guaranteed delivery |
| 00:56.46 | Samot | ^^^ |
| 00:56.50 | Samot | No guaranteed reply |
| 00:57.06 | Samot | It why Asterisk has a qualify setting. |
| 00:57.19 | Samot | So it can keep sending messages to see if it gets a reply |
| 00:57.34 | Samot | Because registrations are not stateful |
| 00:57.36 | Samot | Even over TCP |
| 00:57.43 | [TK]D-Fender | While for call-progress sake you might consider it a state, using those terms where general networking is involved is wrong. |
| 00:57.54 | catphish | but when setting up a proxy, you have a choice of what to keep track of, there must be benefits to tracking state in proxies at times, or there's be no point in: "16.2 Stateful Proxy" |
| 00:57.59 | Samot | A device registers, drops it location to the registrar (Asterisk in this case) and it's done. |
| 00:58.10 | [TK]D-Fender | it's a grey use of the term |
| 00:58.19 | Samot | Yes. |
| 00:58.33 | [TK]D-Fender | Anyway ...... |
| 00:58.33 | catphish | asterisk it itself a stateful proxy (amongst other things) |
| 00:58.45 | [TK]D-Fender | that is not at all correct |
| 00:58.48 | Samot | No it is not. |
| 00:58.49 | [TK]D-Fender | * is NOT a proxy |
| 00:58.52 | Samot | At all. |
| 00:58.55 | [TK]D-Fender | ~b2bua |
| 00:58.55 | infobot | [b2bua] a Back 2 Back User Agent. Additional information is available on wikipedia: http://en.wikipedia.org/wiki/Back-to-back_user_agent |
| 00:58.56 | Samot | It's a telephony engine. |
| 00:58.57 | [TK]D-Fender | ^ |
| 00:59.13 | catphish | it is a b2bua i suppose |
| 00:59.13 | Samot | Asterisk is generally coupled with a proxy |
| 00:59.20 | Samot | Not suppose. It IS |
| 00:59.34 | [TK]D-Fender | <Samot> Asterisk is generally coupled with a proxy <- not even. |
| 00:59.45 | Samot | It's not a requirement |
| 00:59.52 | Samot | But depending on what you are doing... |
| 00:59.57 | catphish | most people who install asterisk for a small environment probably don't bother with a proxy |
| 01:00.05 | Samot | Nope. |
| 01:00.06 | [TK]D-Fender | "a relative FEW * users use it in a larger infrastructure including SIP proxies" |
| 01:00.29 | Samot | Well then I'm one of those few. |
| 01:00.40 | catphish | i would still argue that end-to-end, sip is stateful |
| 01:00.46 | [TK]D-Fender | Please collect a plushie from the middle shelf.... |
| 01:00.46 | Samot | No, it's not. |
| 01:01.03 | Samot | You can argue it, but it's not true. |
| 01:01.10 | Samot | SIP CAN BE stateful. |
| 01:01.20 | [TK]D-Fender | catphish> i would still argue that end-to-end, sip is stateful <- in the view of the APPLICATION maybe. Once those packets are flying through ROUTERS your point can go up in smoke |
| 01:01.47 | catphish | [TK]D-Fender: you could equally argue that TCP is stateless in the middle |
| 01:01.55 | catphish | but at each end, it needs state |
| 01:02.06 | [TK]D-Fender | Routers retransmit on their own. |
| 01:02.15 | [TK]D-Fender | it doesn't have to go back to the originating system |
| 01:02.38 | catphish | what? |
| 01:02.43 | catphish | IP routers don't |
| 01:02.57 | catphish | only endpoints retransmit IP packets |
| 01:03.08 | catphish | (and TCP and UDP packets) |
| 01:03.14 | [TK]D-Fender | Think I skipped something there... |
| 01:03.34 | Samot | I FTP to my web server. |
| 01:03.36 | Samot | TCP |
| 01:03.58 | Samot | My connection is live for the period I have set in the TIMEOUT if I'm idle. |
| 01:04.13 | Samot | Because TCP is keeping that connection open for that 30 seconds I'm not doing anything. |
| 01:04.30 | catphish | TCP is just something the endpoints layer in top of IP, routers in the middle have no idea |
| 01:04.31 | Samot | Now, I send a NOTIFY to a SIP phone. |
| 01:04.40 | Samot | There's no open connection. |
| 01:04.45 | Samot | I have an IP and a port |
| 01:04.48 | Samot | And I have to HOPE |
| 01:04.49 | catphish | if a TCP packet is lost, the end-host has to resend it |
| 01:05.00 | Samot | The otherside is still listening on that IP and port. |
| 01:05.17 | [TK]D-Fender | Sorry, the stack still takes care of it |
| 01:05.17 | Samot | If a UDP packet is lost, it's lost. |
| 01:05.26 | catphish | the only difference is in what layer handles the retransmission, in TCP the OS does it for you |
| 01:05.26 | Samot | No one resends it |
| 01:05.31 | Samot | They sent a NEW one. |
| 01:05.31 | [TK]D-Fender | as opposed to the application |
| 01:05.45 | catphish | in UDP the application has to do it, indeed |
| 01:05.51 | [TK]D-Fender | Anyway..... whatever |
| 01:06.09 | catphish | Samot: "resend" vs "send a new one" is moot |
| 01:06.15 | catphish | the result is the same |
| 01:06.23 | Samot | No it is not. |
| 01:06.29 | Samot | Because both can still get a reply |
| 01:06.30 | [TK]D-Fender | "kinda" |
| 01:06.35 | [TK]D-Fender | "ish" |
| 01:06.41 | [TK]D-Fender | WHATEVER |
| 01:06.48 | [TK]D-Fender | so moving on.... |
| 01:06.56 | catphish | TCP will disregard the duplicate, your app might do that too |
| 01:07.09 | catphish | but yeah, this is probably a waste of everyone's time, sorry |
| 01:07.17 | catphish | i think we all know how it works :) |
| 01:08.25 | catphish | what i was talking about is the difference between a proxy with no idea what's going on, vs one that tracks certain things, for example UA registrations |
| 01:08.35 | Samot | A proxy |
| 01:08.38 | Samot | Uses memory |
| 01:08.46 | Samot | Tracking a call based on the things I said. |
| 01:08.59 | catphish | i call that state tracking :( |
| 01:09.01 | catphish | but ok |
| 01:09.09 | Samot | It's a grey area in that regards |
| 01:09.20 | Samot | It "mimics" state tracking doing that stuff. |
| 01:09.36 | Samot | But the actual network traffic is not. |
| 01:09.48 | catphish | the RFC covers the difference "When stateful, a proxy is purely a SIP transaction processing engine." |
| 01:10.02 | Samot | If a transaction falls out of memory, then any messages as part of that transaction are considered "out of leg" |
| 01:10.25 | catphish | Samot: yeah, but a proxy doesn't have to track any of that at all |
| 01:10.27 | Samot | And the system has no idea what to do with them. |
| 01:10.47 | Samot | Yes, a proxy still has to track those messages. |
| 01:10.49 | catphish | it can be totally dumb, and only proxy each message on its own merts |
| 01:10.49 | Samot | Even more so |
| 01:10.57 | catphish | no, it doesn't |
| 01:10.59 | Samot | OK. |
| 01:11.13 | catphish | i feel like we just swapped points of view lol |
| 01:11.20 | Samot | The proxy doesn't have to track anything. |
| 01:11.27 | Samot | It just passes stuff through... |
| 01:11.37 | catphish | indeed, it can track, optionally |
| 01:11.49 | Samot | It doesn't need to know anything about the two points. |
| 01:12.30 | Samot | Why even have a proxy? |
| 01:12.35 | Samot | It doesn't do anything |
| 01:12.42 | Samot | It's just passing things through it.. |
| 01:13.27 | catphish | at its simplest, its probably completely pointless |
| 01:13.36 | catphish | but you can add things as needed |
| 01:14.22 | Samot | Proxies are there to do something. |
| 01:14.32 | Samot | So they deal with the SIP messages. |
| 01:14.41 | catphish | for example you might have a proxy that does nothing but watches for abuse patterns |
| 01:14.51 | Samot | It still needs to touch the SIP message |
| 01:15.04 | catphish | yes, it does need to modify the packets slightly |
| 01:15.15 | catphish | mostly just to add its Via header |
| 01:15.34 | Samot | Well it actually adds a Record Route |
| 01:15.56 | catphish | it doesn't have to, but doing so ensures that it stays in the path, which you generally want |
| 01:16.09 | Samot | If it doesnt the other side has no idea where to send the reply |
| 01:16.21 | catphish | Samot: not true, thats what via headers are for |
| 01:16.35 | catphish | via headers direct in-transaction replies |
| 01:17.15 | Samot | How do you think the VIAs get there? |
| 01:17.24 | Samot | Record Routes |
| 01:17.25 | catphish | i just said, the proxy adds them |
| 01:17.36 | catphish | no, via and record-route are separate |
| 01:17.45 | Samot | OK. |
| 01:17.55 | catphish | via is for replies, record-route is for subsequent in-dialog requests |
| 01:18.05 | catphish | similar though |
| 01:18.07 | Samot | Yes, it's for INVITEs |
| 01:18.59 | catphish | when you send an invite, you only need a Via header to make the 200 OK arrive back, but if you also want messages like BYE to go through the proxy instead of direct, you use record-route |
| 01:19.41 | catphish | as per https://tools.ietf.org/html/rfc3261#section-20.30 |
| 01:19.55 | *** join/#asterisk Y04NN (~y04nn@nayon.fr) |
| 01:20.02 | Samot | OK. |
| 01:20.16 | catphish | possibly one of the simpler paragraphs in that document :) |
| 01:20.21 | Samot | To think that a SIP proxy isn't doing anything to track things is wrong. |
| 01:20.36 | catphish | as i say, its up to the proxy, all tracking is optional |
| 01:20.56 | Samot | How does the proxy know where to send messages and replies? |
| 01:21.08 | *** join/#asterisk cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 01:21.08 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 01:21.13 | Samot | VIAs and Record Routes? |
| 01:21.17 | Samot | Then it's tracking. |
| 01:21.47 | Samot | How does it know the reply coming back from the other device is a reply? |
| 01:21.49 | Samot | It's tracking. |
| 01:21.53 | catphish | well it puts things in the packet, it doesn't store it locally, but if you consider what tracking, ok |
| 01:22.02 | Samot | It puts things in MEMORY |
| 01:22.15 | catphish | storing anything in memory is optional |
| 01:22.17 | Samot | Or even a database if someone gets that crazy. |
| 01:22.22 | Samot | OK |
| 01:22.23 | catphish | you can do this purely in the packets |
| 01:22.27 | Samot | I send a REGISTER |
| 01:22.34 | catphish | yep |
| 01:22.34 | Samot | Through the proxy to Asterisk. |
| 01:22.40 | Samot | Asterisk sends a reply.. |
| 01:22.43 | Samot | Back through the proxy |
| 01:22.47 | catphish | ok |
| 01:22.50 | Samot | How does the proxy know that is a reply? |
| 01:23.17 | catphish | it knows it's a reply because it begins "SIP/2.0" |
| 01:23.21 | Samot | No. |
| 01:23.23 | catphish | that's easy :) |
| 01:23.58 | catphish | what do you mean "no"? how do you think it identifies a reply? |
| 01:24.17 | Samot | https://www.irccloud.com/pastebin/Rd3pxUh2/ |
| 01:24.31 | Samot | That is Asterisk SENDING a NEW OPTIONs out |
| 01:24.38 | catphish | yes it is |
| 01:24.39 | Samot | SIP/2.0/UDP |
| 01:24.44 | Samot | Not a REPLY |
| 01:24.50 | catphish | does it start with "SIP/2.0"? |
| 01:25.19 | Samot | No. |
| 01:25.23 | Samot | That has nothing to do with it |
| 01:25.32 | catphish | it really does, that's how you tell them apart |
| 01:25.46 | catphish | "SIP responses are distinguished from requests by having a Status-Line as their start-line. A Status-Line consists of the protocol version followed by a numeric Status-Code" |
| 01:29.05 | catphish | the clever part is how it known which client to send the packet back to |
| 01:29.28 | Samot | Hah. |
| 01:29.40 | Samot | SIP/2.0 <- NOT A STATUS CODE |
| 01:29.59 | catphish | no, that's the protocol version |
| 01:30.06 | catphish | the next part should be a status code though |
| 01:30.08 | Samot | A status code is 180, 200, 401, 404, 406 |
| 01:30.21 | Samot | 9:23:20 PMÂ <catphish>Â it knows it's a reply because it begins "SIP/2.0" |
| 01:30.22 | Samot | ^^^^^^ |
| 01:30.31 | catphish | for example: SIP/2.0 200 |
| 01:30.49 | Samot | Right they have their status line |
| 01:30.52 | catphish | but you really don't need to go past the SIP/2.0 to identify it as a reply |
| 01:31.06 | Samot | OK. |
| 01:31.06 | catphish | a request will never begin that way |
| 01:31.43 | catphish | so the next question is "how does the proxy know what client this reply should go to" |
| 01:32.20 | catphish | and the answer is that the client already put its IP address in a "via" header when it made the request, the server echos this back, the proxy just has to read it |
| 01:33.08 | *** join/#asterisk joako (~joako@opensuse/member/joak0) |
| 01:33.32 | Samot | So I send a REGISTER to a proxy... |
| 01:34.05 | Samot | Now, understand that proxy is a "mode" for most SIP Routers/SBCs. |
| 01:34.38 | catphish | i'm talking about the case where the proxy has no memory at all |
| 01:35.25 | catphish | its probably not a state a production proxy would be in, but its the starting point before you start adding any extra features |
| 01:36.14 | Samot | So you're basically talking about a system that would never be used in an actual production system. |
| 01:36.18 | catphish | and it's useful sometimes for very minimal things like logging, or filtering invalid requests |
| 01:36.21 | Samot | Because it does nothing. |
| 01:36.34 | catphish | it doesn't have to do nothing |
| 01:36.47 | Samot | No, you're right. |
| 01:36.52 | Samot | People put in proxies for reasons. |
| 01:36.54 | catphish | there are plenty of things you can do that don't need to record any state |
| 01:36.54 | Samot | To do stuff |
| 01:36.57 | Samot | Perform tasks... |
| 01:37.01 | catphish | indeed |
| 01:37.03 | Samot | I know |
| 01:37.23 | catphish | also those tasks can change over time, you can start with a proxy that does nothing, and add to it |
| 01:38.20 | Samot | Everyone starts with a proxy that does nothing. |
| 01:38.27 | Samot | Until you tell it what to do. |
| 01:38.29 | catphish | which is what i'm actually intending to do, i'm moving from a state where everyone uses asterisk directly, to a proxy, to start with it will do nothing, over time i will add things like loadbalancing, failiver, move authentication to the proxy layer, etc |
| 01:39.01 | *** join/#asterisk Rini (uid196547@gateway/web/irccloud.com/x-kzjkwkmqjmtorvnk) |
| 01:39.43 | Samot | So you're looking at a SIP Router/SBC |
| 01:39.59 | Samot | That _can_ "proxy/passthru" messages. |
| 01:40.06 | catphish | SIP just calls it a proxy |
| 01:40.43 | catphish | but yeah, its an SBC |
| 01:40.44 | Samot | Because you are proxying through it to make calls. |
| 01:40.55 | Samot | It's a "proxy" because it's in between. |
| 01:41.01 | catphish | yep |
| 01:41.43 | catphish | my original question was how to get asterisk to send calls destined for registered phones through the proxy |
| 01:41.53 | catphish | this was answered :) |
| 01:42.11 | Samot | When the phones register with Asterisk.. |
| 01:42.19 | Samot | They'll register with the proxy IP |
| 01:42.33 | Samot | But the contact IP will be the phones WAN |
| 01:42.50 | catphish | they will send their register packet to the proxy, which will send them to asterisk |
| 01:42.56 | Samot | Right. |
| 01:43.01 | Samot | I do this already |
| 01:43.12 | Samot | Based on SIP domains |
| 01:43.15 | catphish | asterisk will record the address in the "contact" header (which the proxy will fix to be the correct WAN IP of the client) |
| 01:43.22 | Samot | I route the messages to the proper PBX |
| 01:43.38 | Samot | Right.. |
| 01:43.42 | catphish | however when asterisk then wants to make a call to that phone, it will send it directly to the phone |
| 01:43.48 | Samot | When you do a sip show peers or pjsip show enpoints |
| 01:43.53 | Samot | They'll all show as the proxy IP |
| 01:43.54 | catphish | because that's the recorded contact |
| 01:44.07 | Samot | But if you look at the endpoint directly, it's contact IP will be the phones public IP |
| 01:44.29 | catphish | so i want to send the calls to the proxy ip, not to the contact IP |
| 01:44.35 | Samot | Sigh. |
| 01:44.49 | Samot | the location IP in Asterisk will be the PROXY IP |
| 01:45.04 | Samot | But the contact IP when you do "sip show peer 100" will be the PHONE |
| 01:45.43 | catphish | "pjsip show contacts" doesn't list an IP address |
| 01:45.50 | *** join/#asterisk cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 01:45.50 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 01:46.00 | catphish | and afaik asterisk sends calls to the contact address |
| 01:46.22 | Samot | <PROTECTED> |
| 01:46.41 | Samot | Reg. Contact: <user@theirip:port> |
| 01:47.06 | catphish | Samot: oh yeah in chan_sip i see the same |
| 01:47.10 | Samot | Asterisk will send the message to Addr->IP with the contents of the message directed at Reg. Contact |
| 01:47.47 | Samot | So when it hits the proxy, the proxy goes "Oh I have a new request from Asterisk to Phone A" |
| 01:47.55 | catphish | Samot: i believe you're correct actually, at least for chan_sip |
| 01:48.00 | Samot | Yes. |
| 01:48.06 | Samot | Because I have like 400 users doing this |
| 01:48.13 | Samot | For one customer. |
| 01:48.56 | catphish | i assume you don't use pjsip then? |
| 01:49.04 | catphish | i need to check the behaviour is the same |
| 01:49.18 | Samot | I haven't fully tested PJSIP |
| 01:49.31 | catphish | the server i'm looking at has "rewrite_contact=yes" |
| 01:49.34 | Samot | With how I do things just yet. |
| 01:49.42 | catphish | so all the contacts have the proxy IP :( |
| 01:49.54 | catphish | (as their contact) |
| 01:49.56 | catphish | which is dumb |
| 01:50.37 | catphish | if pjsip can do what chan_sip does and keep the contact and the remote addr separate then it'll be fine |
| 01:51.06 | Samot | Asterisk needs to send new requests to the proxy |
| 01:51.12 | catphish | indeed |
| 01:51.37 | Samot | So the devices need their location to be the proxy. |
| 01:51.39 | catphish | ie it needs to send them to the IP the REGISTER packets came from, not the IP in the contact |
| 01:52.12 | catphish | i don't know what "location" means in this context |
| 01:52.40 | Samot | That's not how it works. |
| 01:52.51 | catphish | i thought you just said it was |
| 01:52.53 | Samot | The proxy talks to Asterisk and Asterisk talks to the proxy |
| 01:53.01 | Samot | ON BEHALF of the user. |
| 01:53.05 | catphish | yes, correct |
| 01:53.07 | Samot | phone/device. |
| 01:53.21 | Samot | So in order for Asterisk to talk to the device through the proxy |
| 01:53.28 | Samot | It must send the message to the proxy first. |
| 01:53.34 | catphish | the question is... does pjsip know to send the new INVITE to the proxy and not straight to the phone |
| 01:54.02 | catphish | chan_sip does this correctly, it has "Addr->IP" |
| 01:54.10 | catphish | but i can't see anything like this in pjsip |
| 01:54.18 | catphish | i only see the "contact" |
| 01:54.46 | Samot | I need to bring up a pjsip device.. |
| 01:54.48 | Samot | One sec. |
| 01:55.18 | catphish | it has "aor" which is the registered contact |
| 01:55.52 | catphish | the person who has configured this server has enables "rewrite_contact" so all my contacts have the proxy's IP in them |
| 01:56.17 | catphish | which is great, until the proxy receives the invites, and has no idea what to do with them |
| 01:59.52 | Samot | What does the call look like when it's sent out? |
| 02:01.10 | catphish | INVITE sip:charlietest@10.0.8.11:5066;line=96271152b97476d SIP/2.0 |
| 02:01.24 | Samot | The full message. |
| 02:01.29 | catphish | that request goes to the proxy, "10.0.8.11:5066" is the proxy address |
| 02:02.23 | catphish | http://paste.codebasehq.com/pastes/xpqzazjo6yyuwn45ro |
| 02:02.41 | catphish | its not very interesting, just an invite to the proxy's IP |
| 02:03.36 | catphish | ie exactly what's in the contact, as one would expect |
| 02:06.53 | catphish | i'll disable rewrite_contact for this peer and see what happens |
| 02:08.18 | Samot | That's what I think you need. |
| 02:10.33 | catphish | the sets the contact correctly now, but as i feared, the call is sent directly to the contact address, not to the proxy |
| 02:12.09 | Samot | OK. |
| 02:12.19 | Samot | That's what the outbound proxy is for I believe.. |
| 02:12.58 | catphish | yes, i may need to set that |
| 02:13.11 | *** join/#asterisk u0m3 (~u0m3@79.115.167.77) |
| 02:14.38 | catphish | i think that'll probably be it, i was hoping to avoid specifying the proxy address in the asterisk config, but i think this is the correct way to do it |
| 02:19.14 | catphish | Samot: that worked |
| 02:19.44 | catphish | guess i'll have to populate my pjsip phone entries with the proxy IP |
| 02:23.15 | *** join/#asterisk Kobaz (~kobaz@its.kobaz.net) |
| 02:23.16 | catphish | specifically: outbound_proxy=sip:10.0.8.11:5066\;lr |
| 02:23.20 | catphish | thanks all :) |
| 02:25.40 | catphish | its 2:30, i should probably sleep |
| 02:26.18 | *** part/#asterisk mog (~mog@fsf/member/mog) |
| 02:29.28 | Samot | Oh I hope he doesn't think that's the answer... |
| 02:31.08 | Samot | OK, so I'm not that versed on PJSIP issues.. |
| 02:31.29 | Samot | Missing route set (for tel: URI) (PJSIP_ENOROUTESET) <<- What am I missing on that? Is that actually something to worry about? |
| 02:35.50 | *** join/#asterisk NightMonkey (~NightMonk@pdpc/supporter/professional/nightmonkey) |
| 02:42.26 | *** join/#asterisk fstd_ (~fstd@unaffiliated/fisted) |
| 03:06.12 | *** join/#asterisk matrix1233 (~matrix123@41.230.26.59) |
| 03:55.36 | *** join/#asterisk chendy (~alexc@183.14.134.26) |
| 04:02.42 | *** join/#asterisk freebs (~freebs@unaffiliated/freebs) |
| 04:22.35 | *** join/#asterisk NightMonkey (~NightMonk@pdpc/supporter/professional/nightmonkey) |
| 05:46.38 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 05:46.48 | *** join/#asterisk Dovid (~dovid@static-173-63-105-210.nwrknj.fios.verizon.net) |
| 06:46.02 | *** join/#asterisk miralin (~Thunderbi@195.19.212.23) |
| 06:53.55 | *** join/#asterisk bof22 (~Thunderbi@185.13.183.107) |
| 06:56.38 | *** join/#asterisk matrix1233 (~matrix123@41.230.26.59) |
| 07:21.57 | *** join/#asterisk freebs (~freebs@unaffiliated/freebs) |
| 07:56.46 | *** join/#asterisk metanovii (~metanovii@109.226.229.65) |
| 08:01.23 | *** join/#asterisk miralin (~Thunderbi@195.19.212.23) |
| 08:15.13 | *** join/#asterisk matrix1233 (~matrix123@41.230.26.59) |
| 08:28.56 | *** join/#asterisk pchero_work (~pchero@2a00:c80:1072::3f) |
| 08:44.21 | *** join/#asterisk Y04NN (~y04nn@178.18.54.206) |
| 08:48.12 | *** join/#asterisk Y04NN_ (~y04nn@178.18.54.206) |
| 08:57.48 | *** join/#asterisk evil_gordita (robert@ip70-188-41-127.rn.hr.cox.net) |
| 09:09.53 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 09:31.11 | *** join/#asterisk bof22 (~Thunderbi@185.13.183.107) |
| 09:37.53 | *** join/#asterisk guest0990 (~bounceman@185.32.9.250) |
| 09:38.05 | guest0990 | If I set qualify=10000 under [general] block will it override peer specific settings? |
| 09:42.09 | *** join/#asterisk Chotaire (chotaire@91.134.152.20) |
| 09:43.18 | *** join/#asterisk jkroon (~jkroon@165.16.203.110) |
| 09:44.46 | *** join/#asterisk miralin (~Thunderbi@195.19.212.23) |
| 10:01.58 | guest0990 | thing is, I am using Realtime with asterisk 11 and one of our sites have some network issues now and then which causes the agent to take sometimes 3-4 seconds to reply to the OPTIONS. Asterisk then mark that agent as UNREACHABLE. |
| 10:02.10 | guest0990 | I would like to increase that time, I believe it is 2 seconds default? |
| 10:04.10 | JensV | guest0990, Afaik peers specific settings override the general block. |
| 10:05.04 | guest0990 | Ok that s**ks. Looking at the realtime table the column "qualify" is a CHAR and only allow 3 chars |
| 10:06.48 | *** join/#asterisk Kaian (~kaian@6.62-99-78.static.clientes.euskaltel.es) |
| 10:06.58 | guest0990 | Ideas on this? |
| 10:07.10 | guest0990 | What if I empty it in the database? |
| 10:07.17 | guest0990 | Will it then use [general] block settings? |
| 10:31.55 | *** join/#asterisk matrix1233 (~matrix123@41.230.26.59) |
| 10:37.41 | *** join/#asterisk chendy (~alexc@183.14.134.26) |
| 10:40.26 | *** join/#asterisk bof22 (~Thunderbi@185.13.183.107) |
| 10:47.47 | *** join/#asterisk gringo (~gringo@unaffiliated/gringo) |
| 10:55.01 | *** join/#asterisk jkroon (~jkroon@165.16.204.37) |
| 11:27.12 | *** join/#asterisk miralin (~Thunderbi@195.19.212.23) |
| 11:36.09 | *** join/#asterisk Y04NN (~y04nn@178.18.54.206) |
| 12:02.08 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 12:03.39 | *** join/#asterisk cryptic (~cryptic@67-8-35-31.res.bhn.net) |
| 12:06.02 | *** join/#asterisk boris_t (~boris_t@363103629.convex.ru) |
| 12:20.57 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 12:22.28 | *** join/#asterisk Y04NN (~y04nn@178.18.54.206) |
| 12:31.17 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
| 12:38.31 | *** join/#asterisk newtonr (RustyNewto@nat/digium/x-srycaalgogkefgbx) |
| 12:38.32 | *** mode/#asterisk [+o newtonr] by ChanServ |
| 12:43.59 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 12:43.59 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 12:46.08 | dan_j | Has anyone ever had a problem where phones behind a router don't get the RINGING signal? |
| 12:46.18 | dan_j | So they hear nothing until the phones are answered? |
| 12:49.17 | *** join/#asterisk siraskalot (~Davemar@122.53.63.31) |
| 12:58.10 | siraskalot | Hello why is one of my pjsip endpoints being associated to my public IP? how does asterisk determine the extension to IP assignment? here's a pastebin of my pjsip Log. |
| 12:58.25 | siraskalot | http://pastebin.com/mrCcauuS |
| 13:01.11 | dan_j | 192.168.22.113 is the endpoint? |
| 13:01.22 | siraskalot | yes |
| 13:01.28 | dan_j | from UDP:192.168.22.113:51649 |
| 13:01.32 | dan_j | Contact: <sip:6001@122.53.xxx.xxx:1990; |
| 13:01.44 | dan_j | The phone is sending it's public ip to asterisk |
| 13:02.00 | dan_j | Check the phones settings to see if they match the working phone |
| 13:03.30 | *** join/#asterisk jkroon_ (~jkroon@165.16.204.46) |
| 13:04.01 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
| 13:04.15 | siraskalot | its a softphone(zoiper) , what do you suggest the setting i look for on the zoiper config? |
| 13:08.47 | *** join/#asterisk sriharsha (~totakura@2001:4ca0:2001:11:226:b9ff:fe7d:84ed) |
| 13:10.26 | sekil | hello |
| 13:10.43 | sekil | is asterisk 13 a suggested version to use for new setups nowadays? |
| 13:12.30 | dan_j | sekil: latest version of 13 has a bug that causes it to crash occasionally. |
| 13:12.40 | dan_j | it's been around for a few versions. |
| 13:12.49 | dan_j | releases |
| 13:13.15 | dan_j | siraskalot: do you have stun on? |
| 13:13.18 | sekil | hm |
| 13:13.39 | sekil | dan_j: thanks |
| 13:14.08 | dan_j | sekil: https://issues.asterisk.org/jira/browse/ASTERISK-26835 |
| 13:15.10 | siraskalot | danj: no i dont have STUN on. |
| 13:19.05 | dan_j | hmm. when i use zoiper, i just leave everything on default and put in the credentials and never have an issue. |
| 13:19.56 | *** join/#asterisk dexta_ (~D3XTA@host86-181-69-9.range86-181.btcentralplus.com) |
| 13:20.43 | siraskalot | how does asterisk make a registration? |
| 13:20.50 | dan_j | siraskalot: https://www.dropbox.com/s/sf4njap3pa1ryyh/Untitled.png?dl=0 |
| 13:22.35 | *** join/#asterisk Chotaire (chotaire@oahu.chotaire.net) |
| 13:22.51 | dan_j | It's probably responding to the ip:port that it received from and ignoring the contact header. |
| 13:36.42 | *** join/#asterisk andresmujica (~andresmmu@ubuntu/member/andresmujica) |
| 13:38.03 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 13:39.59 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 14:06.23 | *** join/#asterisk tuxian_ (~tuxian@194.12.3.78) |
| 14:20.20 | *** join/#asterisk miralin (~Thunderbi@195.19.212.23) |
| 14:24.38 | *** join/#asterisk tuxian_ (~tuxian@igilmour.plus.com) |
| 14:29.56 | siraskalot | dan_j: I think i solved it by adding a transport section with the line=yes option. |
| 14:30.08 | siraskalot | thanks for your help |
| 14:31.57 | *** join/#asterisk Rini (uid196547@gateway/web/irccloud.com/x-nneemnfmrkskmwxg) |
| 14:35.31 | *** join/#asterisk miralin (~Thunderbi@195.19.212.23) |
| 14:50.27 | *** join/#asterisk rmudgett (rmudgett@nat/digium/x-mvuajiyjhnzcdsrp) |
| 14:50.27 | *** mode/#asterisk [+o rmudgett] by ChanServ |
| 14:54.24 | *** join/#asterisk mub (~jub@static-173-53-12-18.rcmdva.fios.verizon.net) |
| 14:59.34 | *** join/#asterisk kchehab (~kchehab@94.187.60.149) |
| 14:59.39 | kchehab | hi ppl , |
| 15:01.09 | kchehab | i am running asterisk on public ip address ,while trying to exec sip qualify peer Trunk1 ,no packet on network goes to trunk1 , same for Trunk2 ,... even while trying to dial directly Dial/xxx@trunk ip address |
| 15:01.17 | kchehab | please can you advise when could be the problem |
| 15:01.35 | *** join/#asterisk EnrgySmth (d8eba101@gateway/web/freenode/ip.216.235.161.1) |
| 15:01.55 | igcewieling | kchehab: do the peers show and have the correct IP when you do a "sip show peers"? |
| 15:02.03 | kchehab | yes it does |
| 15:02.25 | kchehab | even in the debug level 4 nothing weired unless , its unreachable |
| 15:02.32 | igcewieling | sounds like it could be an iptables issue. |
| 15:02.43 | kchehab | igcewieling but tshark doesnt show any packet goes to Trunk ip address |
| 15:02.45 | Samot | sip set debug on |
| 15:02.52 | Samot | Show the qualify attempts. |
| 15:03.00 | kchehab | saltsa i did iptables -F ,and ipatbles -t nat |
| 15:03.01 | Samot | From Asterisk |
| 15:03.13 | *** part/#asterisk EnrgySmth (d8eba101@gateway/web/freenode/ip.216.235.161.1) |
| 15:03.18 | Samot | ~pb |
| 15:03.18 | infobot | it has been said that 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. |
| 15:03.40 | kchehab | Samot i cant see qualify attempts in network tshark level |
| 15:03.51 | Samot | Don't want them from that level |
| 15:03.54 | Samot | asterisk -r |
| 15:03.57 | Samot | sip set debug on |
| 15:03.59 | igcewieling | kchehab: that does not matter. |
| 15:04.03 | Samot | Show Asterisk making the attempts. |
| 15:07.14 | kchehab | Samot http://pastebin.com/4anKL9W5 |
| 15:07.24 | kchehab | i replace my server ip address with xx.xx.xx.xx and my trunk ip address with yy.yy.yy.yy |
| 15:07.46 | *** join/#asterisk jkroon (~jkroon@165.16.204.44) |
| 15:08.27 | Samot | Retransmitting #1 (NAT) to yy.yy.yy.yy:5060 |
| 15:08.37 | Samot | Is that an IP that is behind NAT? |
| 15:08.51 | kchehab | Samot not its a public IP |
| 15:08.59 | Samot | So this is all local? |
| 15:09.16 | kchehab | its a public ip address |
| 15:09.25 | Samot | The trunk. |
| 15:09.33 | kchehab | trunk also public ip address |
| 15:09.35 | Samot | That you configured. |
| 15:09.43 | Samot | Is the host behind NAT? |
| 15:09.58 | kchehab | Samot no at all |
| 15:10.18 | Samot | So put nat=no in the peer to help get that out of the equation. |
| 15:10.45 | Samot | Now you're saying that packet doesn't leave the server? |
| 15:11.28 | Samot | https://www.irccloud.com/pastebin/t4LVBxiw/ |
| 15:11.46 | Samot | ^^^ You never see that packet leave the server? At all in the tcpdump traces? |
| 15:12.31 | kchehab | Reliably Transmitting (no NAT) to yy.yy.yy.yy:5060: |
| 15:12.54 | kchehab | Samot still packet is not leaving system , is disable nat in sip.conf and trunk config |
| 15:13.04 | Samot | OK.. |
| 15:13.30 | Samot | So now show a tcpdump that is running while Asterisk is sending the options. |
| 15:14.12 | kchehab | Samot i set tsharl -R sip with no outout |
| 15:14.19 | kchehab | tshark* |
| 15:14.20 | Samot | No. |
| 15:14.33 | Samot | tcpdump -nqt -s 0 -A -i eth0 port 5060 |
| 15:14.48 | Samot | eth0 <-- Change to whatever your interface name is if it's not eth0 |
| 15:14.53 | Samot | That's how it should look. |
| 15:15.37 | kchehab | Samot also nothing |
| 15:15.43 | Samot | Show it. |
| 15:15.44 | kchehab | Samot have no output |
| 15:15.51 | kchehab | listening on em1, link-type EN10MB (Ethernet), capture size 65535 bytes |
| 15:16.04 | Samot | Now SSH into another session |
| 15:16.14 | kchehab | Samot i am |
| 15:16.15 | Samot | And make sure Asterisk is sending OPTIONS |
| 15:16.45 | kchehab | Samot asterisk is sending options , Retransmitting #3 (no NAT) to yy.yy.yy.yy:5060: |
| 15:16.55 | kchehab | i replace my publix ip with yy.yy.yy.yy |
| 15:17.02 | Samot | Do: sip show settings |
| 15:17.07 | Samot | ~pb |
| 15:17.07 | infobot | [pastebin] 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. |
| 15:17.11 | Samot | ^^ show the output. |
| 15:18.05 | kchehab | Samot please find it http://pastebin.com/8uVSf4XK |
| 15:19.05 | Samot | OK, first you're using FreePBX so you should be in #freepbx asking these questions. |
| 15:19.45 | kchehab | Samot i dont use the interface , i am using the command line ,even i disable the module ,just have from it its basic config |
| 15:19.56 | Samot | No. |
| 15:20.01 | Samot | That's not how it works. |
| 15:20.18 | Samot | If you don't understand how FreePBX handles Asterisk you just can't do things via the command line. |
| 15:20.47 | kchehab | Samot i do know how free pbx hadle the code well trust me and the config |
| 15:20.52 | Samot | If this is a hosting VM in the cloud running the FreePBX distro, it should have no issues whatsoever. |
| 15:20.56 | kchehab | i am using asterisk from long time |
| 15:21.09 | Samot | Except now you're using FreePBX |
| 15:21.17 | Samot | Which OWNS the system. |
| 15:21.28 | Samot | It expects things to be done in a certain manner. |
| 15:21.41 | Samot | That's why it has a GUI. |
| 15:22.06 | kchehab | Samot hmmm got your point , but this is for testing , and i was asking here because i trust guys here :) |
| 15:22.20 | Samot | The Asterisk SIP Settings section.. |
| 15:22.28 | Samot | Does all this for you with a push of a button. |
| 15:22.47 | kchehab | Samot i try it before i switch to command line |
| 15:23.04 | kchehab | i edit chansip and i well config it based on documentation i read |
| 15:23.20 | igcewieling | kchehab: It is not practical to try to configure asterisk by editing files on a FreePBX system. |
| 15:23.36 | Samot | Go into Admin -> Asterisk SIP Settings and do the "Detect Network Settings" |
| 15:23.41 | igcewieling | kchehab: chan_sip.conf will be overwritten at any time by FreePBX. |
| 15:23.42 | kchehab | igcewieling i did |
| 15:23.52 | kchehab | igcewieling i did all these scenarios |
| 15:24.11 | igcewieling | kchehab: you had chan_sip.conf overwritten by FreePBX? |
| 15:24.25 | kchehab | igcewieling i work in the Gui for long time , when i get no luck i ask here |
| 15:24.37 | igcewieling | kchehab: of course. you are not using asterisk. |
| 15:24.57 | igcewieling | You should ask in #FreePBX because that is what you are using. |
| 15:25.08 | igcewieling | in any case, good luck. |
| 15:25.18 | Samot | Because again, FreePBX does things it's own way for this. |
| 15:25.32 | Samot | Including having multiple conf files that hold the sip configs. |
| 15:29.36 | *** join/#asterisk kchehab (~kchehab@77.42.222.179) |
| 15:29.47 | kchehab | sorry iwas DC for mny bad luck |
| 15:31.26 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 15:31.59 | *** join/#asterisk pchero (~pchero@109.70.54.56) |
| 15:38.49 | JensV | guest0990, Sorry for getting back at this so late, but yes indeed: emptying it in the table should use the [general] settings |
| 15:38.58 | guest0990 | Ok |
| 15:40.45 | *** join/#asterisk miralin (~Thunderbi@194.8.128.114) |
| 15:53.40 | *** join/#asterisk Y04NN_ (~y04nn@178.18.54.206) |
| 15:58.25 | *** join/#asterisk giesen (~ggiesen@2001:19f0:0:1019:5400:ff:fe25:bda6) |
| 16:08.16 | *** join/#asterisk putnopvut_ (putnopvut@asterisk/master-of-queues/mmichelson) |
| 16:08.16 | *** mode/#asterisk [+o putnopvut_] by ChanServ |
| 16:11.34 | igcewieling | I wonder if Asterisk will ever support tel: URIs like P-Asserted-Identity: <tel:+19082105191> |
| 16:11.40 | *** join/#asterisk Dovid (~dovid@ool-4573a525.dyn.optonline.net) |
| 16:14.19 | *** join/#asterisk chendy (~alexc@183.14.132.1) |
| 16:21.11 | Samot | In regards to SIP? |
| 16:22.07 | [TK]D-Fender | There is no other kind I can think of... |
| 16:22.38 | Samot | Just being clear since SIP is not Asterisk's only way. |
| 16:25.20 | lorsungcu | Tel: isn't a sip thing at all |
| 16:25.33 | Samot | Nope. That's why I was asking. |
| 16:25.37 | lorsungcu | It's dependent on how the application is told to handle it |
| 16:26.43 | *** join/#asterisk Y04NN (~y04nn@178.18.54.206) |
| 16:29.29 | igcewieling | correct, SIP. |
| 16:30.40 | Samot | There would be no need. |
| 16:30.45 | igcewieling | RFC 3966: "SIP can use the "tel" URI anywhere a URI is allowed, for example as a Request-URI, along with "sip" and "sips" URIs." |
| 16:31.00 | drmessano | igcewieling: Why dont you submit a patch |
| 16:31.16 | Samot | Right, so instead of using the RURI or the TO URI it would have to look for a TAG on an existing URI |
| 16:31.20 | igcewieling | *I* handle it in my scripts so I don't care, bu I'm sure others have the issue. |
| 16:31.30 | drmessano | LOL |
| 16:31.38 | igcewieling | drmessano: patches are not accepted for Asterisk 11 |
| 16:31.48 | Samot | Because it's dead. |
| 16:31.50 | Samot | they are for 13 |
| 16:31.52 | drmessano | Right |
| 16:31.57 | igcewieling | All I need to do is comment out the stupid error messsage. |
| 16:32.01 | drmessano | So submit a patch against 13+ |
| 16:32.09 | igcewieling | Samot: lets not revisit me not using Asterisk 13. |
| 16:32.19 | Samot | It's not a job for a telephony engine. |
| 16:32.25 | Samot | It's a job for a SIP router. |
| 16:33.41 | drmessano | You cant complain about something not being supported in Asterisk, offer that "I don't care, I have scripts that fix it, I just hate the errors", and not sound like part of the problem |
| 16:33.50 | *** part/#asterisk Merlin (merlin@evendata.com) |
| 16:33.58 | drmessano | Have you made a feature request? |
| 16:34.08 | drmessano | Spoken to a dev? |
| 16:34.08 | igcewieling | Not a PROBLEM, a MINOR ANNOYANCE. |
| 16:34.20 | Samot | Again.. |
| 16:34.28 | Samot | Not a job for a telephony engine. |
| 16:34.47 | Samot | SIP Router/softswitch/SBC whatever you want to call them.. |
| 16:34.50 | igcewieling | drmessano: no, because they won't listen to me because I'm not running the latest. So, lets drop and and pretend I never mentioned. |
| 16:34.51 | drmessano | Why are you yelling? |
| 16:34.52 | Samot | That's a job for them. |
| 16:35.32 | drmessano | At some point you will be running 13.. and it could even be fixed by then if you suggest a fix |
| 16:35.45 | Samot | No, he's waiting until 15. So it's OK. |
| 16:35.54 | Samot | He can submit a feature request/patch then. |
| 16:36.03 | drmessano | It wont be fixed in 15 either, unless you suggest |
| 16:36.10 | drmessano | Now is the time to do it |
| 16:36.18 | Samot | While the use of tel: URIs in SIP get less needed. |
| 16:36.30 | igcewieling | I see this, but don't now if it was put in. https://issues.asterisk.org/jira/browse/ASTERISK-17179 |
| 16:36.58 | igcewieling | ah, right at the bottom. |
| 16:37.10 | drmessano | So 13 has it resolved |
| 16:37.33 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 16:37.39 | drmessano | Do you build from source? |
| 16:37.52 | drmessano | You could always patch your builds |
| 16:39.16 | igcewieling | Of course I build from source, only idiots install from packages. 8-| |
| 16:39.45 | drmessano | Well you have everything you need to fix it now |
| 16:40.08 | igcewieling | yup, so we don't need to discuss it further. |
| 16:41.03 | *** join/#asterisk tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 16:45.38 | Samot | So someone came in here yesterday with an issue regarding PJSIP and doing a proxy... |
| 16:46.06 | Samot | He took off after we did some changes and he made 1 good call... |
| 16:46.29 | Samot | But I have my test proxy running with PJSIP and I'm finding some issues. |
| 16:47.48 | Samot | So with Chan_SIP when the user go through the proxy the Addr->IP is set to the proxy IP |
| 16:48.23 | Samot | But the Reg. Contact is set to the phone's IP. That works great. Chan_SIP sends all messages to the proxy with the contact listed as the phone. Perfect. |
| 16:49.21 | Samot | With PJSIP, if you set rewrite_contact=no nothing is storing the source IP of the REGISTER request |
| 16:50.06 | Samot | So the keepalives are going directly to the phone, the phone is sending replies to the proxy and the proxy sends them through.. |
| 16:50.09 | Samot | But.. |
| 16:50.50 | Samot | Since it's not a reply from the phone, zero impact. Eventually Asterisk tags the extension as "Unavailable" and it can't receive calls. |
| 16:51.38 | Samot | So it looks like when PJSIP stores location information it's all or nothing for the source IP and the Registration contact IP. |
| 16:51.45 | Samot | They are the same. |
| 16:52.02 | Samot | Well not the same.. |
| 16:52.19 | Samot | But it doesn't keep the source IP of the proxy in memory. |
| 16:52.38 | Samot | If rewrite_contact is set to yes... |
| 16:53.05 | Samot | Then all the messages go to the proxy but that's it.. |
| 16:53.22 | Samot | So it's looking like a "pass-thru" solution won't work with PJSIP. |
| 16:54.09 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 16:54.50 | Samot | Hey file, is that worthy of a feature request? ^^^^^ Or is this something on the list... |
| 16:55.14 | file | we don't accept feature requests, and it sounds like you were relying on the NAT behavior to make that work |
| 16:56.00 | file | there's an RFC actually for how a proxy specifies that it should be contacted for requests to something that registered |
| 16:56.05 | Samot | Well I tried setting the outbound_proxy to the proxy server.. |
| 16:56.12 | file | where? |
| 16:56.14 | Samot | The OPTIONS continue to go the phone directly. |
| 16:56.22 | Samot | One sec... |
| 16:56.35 | file | I think you'd need it on the AOR |
| 16:57.18 | Samot | OK |
| 16:57.22 | Samot | Maybe that's my issue. |
| 16:57.29 | Samot | https://www.irccloud.com/pastebin/16mJAi4P/ |
| 16:57.42 | file | that's also an invalid outbound proxy |
| 16:57.42 | Samot | I have it in endpoint. |
| 16:57.54 | Samot | Needs sip: |
| 16:57.56 | Samot | ? |
| 16:57.57 | file | you'd probably want sip:ob.blazevoice.com:5060\;lr |
| 16:57.58 | file | yes |
| 16:58.02 | Samot | Thanks. |
| 16:58.20 | file | you'd still need it on AOR too |
| 16:58.22 | Samot | I'll give that a go.. |
| 16:58.31 | Samot | And I'll put it in the AOR too.. |
| 16:59.59 | file | wanders off |
| 17:02.03 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 17:05.29 | *** join/#asterisk matrix1233 (~matrix123@197.1.47.121) |
| 17:16.26 | *** join/#asterisk skirmisha (~skirmisha@213.16.62.70) |
| 17:16.38 | skirmisha | guy, can someone help me with asterisk ss7? |
| 17:17.02 | skirmisha | in particular, do i need to run dahdi chan along with ss7 chan? |
| 17:17.45 | skirmisha | i've installed dahdi driver, cards are seen, but don't know whether i need to configure both drivers or only chan_ss7 |
| 17:21.46 | skirmisha | ??? |
| 17:31.21 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 17:38.29 | *** join/#asterisk tuxian (~tuxian@igilmour.plus.com) |
| 17:55.59 | *** join/#asterisk Auz (~Auz@50-78-106-241-static.hfc.comcastbusiness.net) |
| 17:58.33 | Auz | Hi, I have an asterisk box and remote workers who want to call people as if they are in the office. Is there an extension which would allow them to do some kind of call forwarding or proxying? I'm not sure on the right wording. |
| 18:02.55 | *** join/#asterisk mulvane (~mulvane@freebsd/user/mulvane) |
| 18:02.59 | Samot | Auz: How are the remote users making the call? |
| 18:03.18 | Samot | With an IP Phone/softphone or from their mobile phones? |
| 18:08.20 | *** join/#asterisk petris (sid19918@gateway/web/irccloud.com/x-yfqzlivjmnbqdwmd) |
| 18:10.55 | Auz | Samot: they want to use their mobile phones |
| 18:11.39 | Auz | Samot: I could do a soft SIP phone, but they aren't so tech savvy |
| 18:12.33 | *** join/#asterisk jkroon (~jkroon@uls-154-73-32-14.wall.uls.co.za) |
| 18:13.34 | Auz | is there something where they can call our office, enter an extension, then enter an external number, and have it connect the calls? |
| 18:15.16 | Samot | Yes. |
| 18:15.35 | Samot | The VoiceMail application has a feature that you can use. |
| 18:15.42 | Samot | That is an option. |
| 18:16.00 | Samot | It requires them to call into their voicemail account, access it with their PIN, go the the admin menu... |
| 18:16.09 | [TK]D-Fender | huh? |
| 18:16.16 | Samot | The voicemail app |
| 18:16.19 | Samot | From the admin menu |
| 18:16.23 | [TK]D-Fender | how does that call people? |
| 18:16.29 | Samot | You can allow an IVR to make outbound calls. |
| 18:16.33 | Samot | I was getting to it. |
| 18:16.41 | Samot | If you write the dialplan. |
| 18:17.07 | [TK]D-Fender | "core show application disa" <- |
| 18:17.12 | [TK]D-Fender | if you want to give them a tone |
| 18:17.19 | Samot | Yes. |
| 18:17.24 | [TK]D-Fender | Or just make a regular IVR to take the input |
| 18:17.29 | Samot | Yup. |
| 18:17.31 | [TK]D-Fender | Just make sure to auth them somehow |
| 18:17.41 | Samot | There are options. |
| 18:17.43 | [TK]D-Fender | either DISA auth, "vmauthenticate" against a mailbox, etc |
| 18:17.48 | igcewieling | DISA, helping phone systems to get hacked for 20 years. |
| 18:18.08 | Samot | Why I suggested the VM method. |
| 18:18.14 | Samot | Requires them to auth at least. |
| 18:19.56 | [TK]D-Fender | so does DISA |
| 18:20.26 | [TK]D-Fender | I've just never seen a VM box LEAD to dialing out by entering Voicemail itself |
| 18:20.41 | drmessano | Yeah thats kinda nutso |
| 18:20.50 | drmessano | Like some oddball PBX behavior |
| 18:20.57 | drmessano | COme to think of it |
| 18:21.01 | drmessano | I have heard of that before |
| 18:21.16 | drmessano | But I cant remember which vendor |
| 18:23.07 | *** join/#asterisk sekil (~sekil@cable-89-216-229-95.dynamic.sbb.rs) |
| 18:27.32 | Samot | <PROTECTED> |
| 18:27.51 | Samot | Context to dial out from [option 4 from mailbox's advanced menu] |
| 18:28.48 | drmessano | Thats some old school road warrior crap |
| 18:28.59 | Samot | Still valid in the voicemail.conf |
| 18:29.13 | drmessano | I think NEC had it |
| 18:29.15 | drmessano | No |
| 18:29.18 | drmessano | 3COM |
| 18:29.18 | Samot | That's how we did it like 10 years ago |
| 18:29.29 | Samot | Because it was a feature in other PBX systems. |
| 18:29.43 | drmessano | Yeah |
| 18:29.48 | Samot | Just like the "twining" requests we used to get asked about |
| 18:30.32 | [TK]D-Fender | <Samot> Context to dial out from [option 4 from mailbox's advanced menu] <- Last I checked that was only for O & A |
| 18:30.56 | Samot | O&A? |
| 18:32.58 | *** join/#asterisk TandyUK (~admin@2a02:13a0:a006:1:24c2:708a:efc0:6447) |
| 18:33.20 | [TK]D-Fender | vm opts |
| 18:33.41 | igcewieling | exten => a and exten => 0 |
| 18:33.44 | igcewieling | exten => a and exten => o |
| 18:33.46 | Samot | It's an option via the admin menu in VoiceMailMain(() |
| 18:33.58 | [TK]D-Fender | Oh, CALLBACK |
| 18:34.04 | Samot | Option 4 |
| 18:34.10 | [TK]D-Fender | got a link? |
| 18:34.20 | Samot | https://github.com/asterisk/asterisk/blob/master/configs/samples/voicemail.conf.sample |
| 18:34.32 | Samot | dialout=fromvm |
| 18:34.41 | Samot | ^^ If that is set..option 4 is exposed |
| 18:34.51 | Samot | And pushes them to [fromvm] |
| 18:35.26 | [TK]D-Fender | Ok, so it gives them a menu option to dial out any # from there? |
| 18:35.35 | Samot | callback lets them call back the VM sender |
| 18:35.38 | Samot | Yes. |
| 18:35.39 | [TK]D-Fender | never seen, and it's worded just vague enough to tick me off.... |
| 18:35.46 | Samot | Or whatever you allow in your context |
| 18:36.02 | Samot | So back in the day.. |
| 18:36.10 | Samot | You could make "remote" calls that way |
| 18:36.24 | Samot | But if you had International rights, they were restricted. |
| 18:36.37 | Samot | We only accepted 1NXXNXXXXXX |
| 18:36.54 | Samot | And pushed it out a special route so we could track those calls |
| 18:37.33 | Samot | We did the same thing with callback.. |
| 18:37.50 | Samot | But you could only do it to a NANP caller. |
| 18:38.14 | [TK]D-Fender | That's an option if you want to call your own ext to get there |
| 18:38.30 | Samot | Right. |
| 18:38.39 | [TK]D-Fender | DISA works, and could use vmauthenticate as the auth front-end to save wasting ringing time if you wanted |
| 18:38.41 | Samot | Call into your voicemail, auth with your PIN, go to advanced menu.. |
| 18:38.49 | Samot | It is a bunch of hoops. |
| 18:39.19 | [TK]D-Fender | offers more ways, but I prefer call control to be in the dialplan as long as possible and not rebranched by things like VM |
| 18:39.25 | [TK]D-Fender | but all seem to work |
| 18:39.30 | Samot | Yeah. |
| 18:39.46 | Samot | "remote calling" is something I never see people agree on. |
| 18:39.59 | Samot | In regards to the "best" or "secure" way to do it. |
| 18:40.44 | *** join/#asterisk Dovid (~dovid@ool-4573a525.dyn.optonline.net) |
| 18:48.38 | *** join/#asterisk jameswf (uid27319@gateway/web/irccloud.com/x-zkeqqyirsoklisbh) |
| 18:49.34 | [TK]D-Fender | Since there is no real failure logging with anything by DIY dialplan that'd be my preference |
| 18:49.39 | [TK]D-Fender | but* |
| 18:54.35 | *** join/#asterisk tuxian (~tuxian@igilmour.plus.com) |
| 18:58.35 | *** join/#asterisk matrix1233 (~matrix123@197.0.44.246) |
| 19:05.12 | *** join/#asterisk dan_j (sid21651@gateway/web/irccloud.com/x-ljzlrtnmiiwmghmx) |
| 19:27.11 | *** join/#asterisk Dovid (~dovid@ool-4573a525.dyn.optonline.net) |
| 19:31.27 | *** join/#asterisk matrix1233 (~matrix123@197.1.190.235) |
| 19:56.53 | *** join/#asterisk rrittgarn (~rrittgarn@75-150-221-205-Illinois.hfc.comcastbusiness.net) |
| 20:02.32 | *** join/#asterisk simplydrew (~simplydre@unaffiliated/simplydrew) |
| 20:08.51 | *** join/#asterisk DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
| 20:08.51 | *** mode/#asterisk [+o DivideBy0] by ChanServ |
| 20:23.52 | *** join/#asterisk defsdoor (~andy@cpc35-sutt4-2-0-cust184.19-1.cable.virginm.net) |
| 20:26.25 | *** join/#asterisk J0hnSteel (~J0hnSteel@92.55.116.179) |
| 20:29.04 | *** join/#asterisk Y04NN (~y04nn@nayon.fr) |
| 20:32.46 | *** join/#asterisk jfindley (~jfindley@12.68.72.66) |
| 20:33.24 | *** join/#asterisk pchero (~pchero@109.70.54.56) |
| 20:33.34 | jfindley | Anyone familiar with reasons why an RTP payload would be a bunch of FFFFFFFFFFFFfs? |
| 20:34.57 | *** join/#asterisk matrix1233 (~matrix123@197.1.190.235) |
| 20:46.36 | *** join/#asterisk matrix1233 (~matrix123@197.1.190.235) |
| 21:02.40 | *** join/#asterisk Chotaire (chotaire@91.134.152.20) |
| 21:10.24 | *** join/#asterisk Dovid (~dovid@ool-4573a525.dyn.optonline.net) |
| 21:13.55 | igcewieling | could it be transmitting silence? |
| 21:16.19 | *** join/#asterisk giesen (~ggiesen@2001:19f0:0:1019:5400:ff:fe25:bda6) |
| 21:24.09 | *** join/#asterisk matrix1233 (~matrix123@197.1.190.235) |
| 21:36.46 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 21:49.57 | *** join/#asterisk ChannelZ (channelz@burner.com) |
| 22:01.43 | *** join/#asterisk matrix1233 (~matrix123@197.1.190.235) |
| 22:04.20 | *** join/#asterisk Y04NN (~y04nn@nayon.fr) |
| 22:15.44 | jfindley | igcewieling: Sorry, just now saw your reply. I suppose it's possible but one of our carriers has sent me nearly 100 calls today where the RTP stream consists of packets with no audio data |
| 22:16.26 | jfindley | the other leg answers and frequently says 'hello? hello? I'm sorry I can't hear you, please call back" |
| 22:17.47 | drmessano | Sounds like silence |
| 22:18.18 | drmessano | You're only having a problem with that one carrier? |
| 22:39.23 | *** join/#asterisk matrix1233 (~matrix123@197.1.190.235) |
| 22:43.21 | *** join/#asterisk SSlater (~simon@mail.favour.com.au) |
| 23:17.12 | *** join/#asterisk matrix1233 (~matrix123@197.1.190.235) |
| 23:26.58 | *** join/#asterisk Inf0r (uid2810@gateway/web/irccloud.com/x-zetcgzevulfiwsmu) |
| 23:29.34 | *** join/#asterisk miralin (~Thunderbi@194.8.128.114) |
| 23:42.45 | *** join/#asterisk Oatmeal (~Suzeanne@c-68-45-50-54.hsd1.in.comcast.net) |
| 23:58.04 | *** join/#asterisk matrix1233 (~matrix123@197.1.190.235) |
