| 01:25.14 | *** join/#asterisk ghoti (~paul@bras-base-ptldon0102w-grc-03-76-66-164-227.dsl.bell.ca) |
| 01:35.06 | *** join/#asterisk ghoti (~paul@bras-base-ptldon0102w-grc-03-76-66-164-28.dsl.bell.ca) |
| 01:47.00 | *** join/#asterisk ghoti (~paul@bras-base-ptldon0102w-grc-03-76-66-164-172.dsl.bell.ca) |
| 01:54.15 | *** join/#asterisk gavlee (~gav@unaffiliated/gavlee) |
| 02:37.06 | *** join/#asterisk joako (~joako@opensuse/member/joak0) |
| 02:41.19 | *** join/#asterisk ghoti (~paul@bras-base-ptldon0102w-grc-03-76-66-164-172.dsl.bell.ca) |
| 02:49.20 | *** join/#asterisk tsal_ (~tsal@i59F5F54B.versanet.de) |
| 03:04.20 | *** join/#asterisk spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 03:08.57 | *** join/#asterisk ghoti (~paul@bras-base-ptldon0102w-grc-03-76-66-164-108.dsl.bell.ca) |
| 03:18.48 | *** join/#asterisk ^MillerBoss (~biffies@gives.you.more.taste.at.only.96.calories.millerboss.com) |
| 03:18.48 | *** join/#asterisk bbhoss (sid18216@gateway/web/irccloud.com/x-zhmlrtdwecsbaxbu) |
| 03:18.48 | *** join/#asterisk jameswf (uid27319@gateway/web/irccloud.com/x-dljwvlpnlbetckqi) |
| 03:18.48 | *** mode/#asterisk [+o jameswf] by beckett.freenode.net |
| 03:28.33 | *** join/#asterisk Typhon (~Typhon@dslb-088-066-103-015.088.066.pools.vodafone-ip.de) |
| 04:28.28 | *** join/#asterisk Andee (~Andee@docker.cassidyweb.co.uk) |
| 06:12.55 | *** join/#asterisk Grommish (~quassel@dsl-74-83-125-127.fuse.net) |
| 07:29.56 | *** join/#asterisk TulaZula (TulaZula@gateway/vpn/privateinternetaccess/tulazula) |
| 08:02.00 | *** join/#asterisk opal (~wowaname@volatile/founder/wowaname) |
| 08:02.55 | *** join/#asterisk retentiveboy (~retentive@c-76-97-11-199.hsd1.ga.comcast.net) |
| 08:05.45 | *** join/#asterisk tehgooch (tehgooch@unaffiliated/tehgooch) |
| 08:06.20 | *** join/#asterisk opal (~wowaname@volatile/founder/wowaname) |
| 08:50.48 | *** join/#asterisk opal (~wowaname@volatile/founder/wowaname) |
| 08:56.52 | *** join/#asterisk gerhard7 (~gerhard7@86-87-238-48.fixed.kpn.net) |
| 09:19.19 | *** join/#asterisk g66k (~g66k@unaffiliated/g66k) |
| 09:20.30 | *** join/#asterisk g66k (c441972b@unaffiliated/g66k) |
| 09:20.35 | g66k | hello everyone |
| 09:20.43 | g66k | im trying to make call from dongle |
| 09:21.13 | g66k | the following line on extension works : exten => _+X.,1,Dial(Dongle/dongle0/+1434245235) |
| 09:21.30 | g66k | this not working exten => _+X.,1,Dial(Dongle/dongle0/${EXTEN}) |
| 09:35.15 | *** join/#asterisk Andee (~Andee@docker.cassidyweb.co.uk) |
| 09:36.39 | *** join/#asterisk gerhard7 (~gerhard7@86-87-238-48.fixed.kpn.net) |
| 10:05.45 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 10:08.49 | *** join/#asterisk mTeK (~quassel@192.151.137.68) |
| 10:38.09 | *** join/#asterisk gerhard7 (~gerhard7@86-87-238-48.fixed.kpn.net) |
| 11:56.45 | *** join/#asterisk tehgooch_ (tehgooch@unaffiliated/tehgooch) |
| 11:57.04 | *** join/#asterisk gruetze_ (~quassel@daemon.gruetzkopf.org) |
| 11:57.48 | *** join/#asterisk DanFromUK_ (sid21651@gateway/web/irccloud.com/x-ltphwrjqdqxdtbbb) |
| 11:58.07 | *** join/#asterisk guerby (~guerby@april/board/guerby) |
| 11:58.49 | *** join/#asterisk SunTsu (miyamoto@unaffiliated/suntsu) |
| 12:37.18 | *** join/#asterisk spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 13:11.29 | *** join/#asterisk gavlee (~gav@unaffiliated/gavlee) |
| 13:36.46 | *** join/#asterisk pchero (~pchero@211.178.226.108) |
| 15:07.58 | *** join/#asterisk valentin_s (25c9046f@ip-37-201-4-111.hsi13.unitymediagroup.de) |
| 15:10.18 | valentin_s | hey, i wanted to make a fax polling service using asterisk's app_SendFax(). How can I specify to use app_SendFax instead of res_SendFax? |
| 15:22.11 | *** join/#asterisk gerhard7 (~gerhard7@86-87-238-48.fixed.kpn.net) |
| 15:50.52 | *** join/#asterisk MarkSX (~MarkSX@unaffiliated/marksx) |
| 16:05.59 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 16:13.49 | *** join/#asterisk gerhard7 (~gerhard7@86-87-238-48.fixed.kpn.net) |
| 16:57.12 | *** join/#asterisk aness (~aness@2a02:fe1:3104:2600:56a:3d92:eccc:83f1) |
| 17:49.35 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 18:15.21 | valentin_s | hey, is there a way to use app_SendFax() instead of res_SendFax() when using pjsip? |
| 18:16.47 | *** join/#asterisk spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 18:32.36 | *** join/#asterisk pvoigt (~Linux@unaffiliated/pvoigt) |
| 18:44.10 | pa | does it still exist a service that offers a free voip number that can also receive sms, where one only pays for the calls that are placed, and no fixed monthly fee? |
| 18:44.26 | pa | checking on voip-info, but the resources seem very outdated |
| 18:48.14 | *** join/#asterisk DodgeThis (~DodgeThis@246.102.90.149.rev.vodafone.pt) |
| 19:31.05 | *** join/#asterisk tips (~tips@pool-173-72-12-154.cmdnnj.fios.verizon.net) |
| 19:55.21 | sibiria | free, i don't think so |
| 19:55.38 | sibiria | VLNs do after all cost money |
| 20:22.36 | *** join/#asterisk gerhard7 (~gerhard7@86-87-238-48.fixed.kpn.net) |
| 20:28.30 | *** join/#asterisk mducharme (uid303982@gateway/web/irccloud.com/x-shvqndpzdqvewzae) |
| 20:57.01 | *** join/#asterisk beta2 (~beta2@ool-4a5998c6.dyn.optonline.net) |
| 20:59.08 | beta2 | Getting 15 minute call drops; can receive calls from external (so port forwarding works); RTP works based on logs. Seems SIP reinvite coming from external is presumably sending sip packets to the wrong address or wrong port; is there an easy way to verify this? |
| 21:09.26 | vasilakisfil | hey folks, I have a question regarding rfc 3261, if anyone knows.. I have a question regarding sip transactions, specifically server transactions. When the transaction layer forwards a uac request to TU, when the TU responds back, how can the transaction layer match the TU response to the existing proceeding transaction ? |
| 21:11.28 | *** join/#asterisk pestdoktor1 (pestdoktor@gateway/shell/matrix.org/x-auvkknspnbdfgujw) |
| 21:16.43 | Samot | vasilakisfil: There are things called From Tag and To Tag, along with the callid |
| 21:20.09 | vasilakisfil | Samot in case of server transaction (uas) the transaction layer hasn't any to tag to match yet, the to tag is generated by TU |
| 21:20.27 | Samot | What do you mean? |
| 21:20.39 | Samot | If the request is sourced from the server, a from tag is generated. |
| 21:20.53 | Samot | If it is sourced from the phone/device, a from tag is still generated. |
| 21:21.11 | vasilakisfil | yeah the from tag is always generated |
| 21:21.25 | Samot | The To Tag is for when a loose route is made. |
| 21:21.33 | Samot | So it doesn't happen immediately. |
| 21:24.11 | vasilakisfil | but if you are sitting on uas end, on transaction layer, when you receive a new incoming request from a peer uac (through transport layer), that request has only From tag, branch and call id. The transaction will forward that to TU and TU will generate a To tag. When TU sends the message to Transaction (to the forward it to uac through Transport), I would like to know how will the transaction layer search and find existing transaction state (which |
| 21:24.12 | vasilakisfil | should be Proceeding and with TU response should be changed to Completed/Accepted) |
| 21:24.38 | Samot | I told you. |
| 21:24.48 | Samot | From Tag, To Tag, callid |
| 21:26.43 | vasilakisfil | hmm I am probably missing something: when the server transaction layer is on Proceeding state, it has initialized a transaction for a uac peer, but there is no known To tag. When later, the TU sends a response to transaction layer to reply to uac, the transaction layer has an incoming message with From,To and CallId, but can only use From and CallId to match, To means nothing |
| 21:27.40 | vasilakisfil | am I right ? |
| 21:30.33 | vasilakisfil | I am talking about server transaction layer, in the case of TU sending a reply through server transaction layer to reply to uac. The rfc clearly defines what you need to do when server transaction layer receives a request from uac, but seems to skip the case I am talking about. I also looked at rfc 6026 but nothing there as well. |
| 21:31.56 | Samot | OK what are you considering the TU |
| 21:31.59 | Samot | Define that for me. |
| 21:33.13 | vasilakisfil | TU is Transaction User according to RFC 3261. To be honest it's a weird name, to me it conceptually TU is the Core of a SIP server. So at lowest end you have Transport layer, then Transaction layer and then TU. |
| 21:35.59 | Samot | One sec. |
| 21:41.02 | *** join/#asterisk overyander (~overyande@209.141.208.197) |
| 21:49.19 | Samot | In the new RFC3261 the way of calculating transaction identifiers was completely changed. Instead of complicated hashing of important header fields a SIP message now includes the identifier directly. Branch parameter of Via header fields contains directly the transaction identifier. This is significant simplification, but there still exist old implementations that don't support the new way of calculating of transaction |
| 21:49.19 | Samot | identifier so even new implementations have to support the old way. They must be backwards compatible. |
| 21:53.42 | vasilakisfil | ah ok if it's only branch id to do the matching on transaction layer that is just perfect |
| 21:53.47 | vasilakisfil | thanks! |
| 21:55.33 | Samot | Well that depends on the server. |
| 21:55.53 | Samot | The RFC states that legacy method must be backwards compatible. |
| 21:59.33 | vasilakisfil | yeah legacy method is a bit tricky but doable |
| 22:07.48 | *** join/#asterisk TulaZula (TulaZula@gateway/vpn/privateinternetaccess/tulazula) |