I'm placing a SIP call, and the xml looks like this
<Response>
<Dial>
<Sip username="myusername" password="mypass">sip:myext#mydomain.com</Sip>
</Dial>
</Response>
When I look into the SIP packets I see, on the second INVITE
From: "+1XXXXXXXXXX" <sip:+1XXXXXXXXXX#sip.twilio.com>;tag=78774647_6772d868_43fb2951-f4f9-4c80-8377-9bb50e9458ae
And no references to myusername... it looks like Twilio is just not sending it, and using the caller id on the from, which is obviously not recognised by my server. On the Asterisk side, I just see
[Oct 17 19:22:58] NOTICE[9150]: chan_sip.c:22614 handle_request_invite: Sending fake auth rejection for device "+1XXXXXXXXXX" <sip:+1XXXXXXXXXX#sip.twilio.com>;tag=78774647_6772d868_43fb2951-f4f9-4c80-8377-9bb50e9458ae
Which kind of makes sense... on my sip.conf, I have
[myusername]
context = somecontext
type = user
secret = mypass
permit=107.21.222.153
permit=107.21.211.20
permit=107.21.231.147
permit=54.236.81.101
permit=54.236.96.128
permit=54.236.97.29
permit=54.236.97.135
permit=54.232.85.81
permit=54.232.85.82
permit=54.232.85.84
permit=54.232.85.85
permit=54.228.219.168
permit=54.228.233.229
permit=176.34.236.224
permit=176.34.236.247
permit=46.137.219.1
permit=46.137.219.3
permit=46.137.219.35
permit=46.137.219.135
permit=54.249.244.21
permit=54.249.244.24
permit=54.249.244.27
permit=54.249.244.28
I'm kind of stuck here... if anyone could give me a hint I'd really appreciate it
Ok... I figured it out. As I guess lots of people will want to integrate twilio with their Asterisks, here's what happened.
The issue is that my server wasn't recognising the user, and it seems like the user/pass is sent after this (twilio doesn't send the user on the From). So, you need to make it type=peer and then use the host=ip to identify twilio. But... they have 23 ips... so, I used templates.
But for every new ip you add you're adding a new sip device, so you should know which IP twilio is going to use to know which username you need to send. The answer is using allowguest=yes on the template... what's good about this, is that it already recognized twilio's ip, so our guest is actually twilio.
This is the xml I'm passing to twilio now
<Response>
<Dial>
<Sip>sip:myext#mydomain.com</Sip>
</Dial>
</Response>
(loving the idea of not sending my username and password on it, hating that I bought an SSL cert just to protect them) and this is how my sip.conf ended up looking
[twiliocaller](!)
context = somecontext
type = peer
qualify=no
allowguest=yes
[twilioip-1](twiliocaller)
host=107.21.222.153
[twilioip-2](twiliocaller)
host=107.21.211.20
[twilioip-3](twiliocaller)
host=107.21.231.147
[twilioip-4](twiliocaller)
host=54.236.81.101
[twilioip-5](twiliocaller)
host=54.236.96.128
[twilioip-6](twiliocaller)
host=54.236.97.29
[twilioip-7](twiliocaller)
host=54.236.97.135
[twilioip-8](twiliocaller)
host=54.232.85.81
[twilioip-9](twiliocaller)
host=54.232.85.82
[twilioip-10](twiliocaller)
host=54.232.85.84
[twilioip-11](twiliocaller)
host=54.232.85.85
[twilioip-12](twiliocaller)
host=54.228.219.168
[twilioip-13](twiliocaller)
host=54.228.233.229
[twilioip-14](twiliocaller)
host=176.34.236.224
[twilioip-15](twiliocaller)
host=176.34.236.247
[twilioip-16](twiliocaller)
host=46.137.219.1
[twilioip-17](twiliocaller)
host=46.137.219.3
[twilioip-18](twiliocaller)
host=46.137.219.35
[twilioip-19](twiliocaller)
host=46.137.219.135
[twilioip-20](twiliocaller)
host=54.249.244.21
[twilioip-21](twiliocaller)
host=54.249.244.24
[twilioip-22](twiliocaller)
host=54.249.244.27
[twilioip-23](twiliocaller)
host=54.249.244.28
Hope it saves some of your time! I also wrote a blog post about this at http://blog.gmc.uy/2013/10/asterisk-twilio-receiving-calls-from.html
Related
I want to send some "raw" RPC commands
For example;
<rpc>
<open-configuration>
<ephemeral-instance>eph1</ephemeral-instance>
</open-configuration>
</rpc>
]]>]]>
im a bit baffled on how to do that, any thoughts?
Something like
with Config(dev, mode='ephemeral', ephemeral_instance='eph1') as cu:
cu.load('set protocols mpls label-switched-path to-hastings to 192.0.2.1', format='set')
cu.commit()
check this doc link for more details
https://www.juniper.net/documentation/en_US/junos-pyez/topics/reference/general/junos-pyez-configuration-process-and-data-formats.html
i am currently trying to implement a „simple“ readonly CALDAV-interface for a system. But the synchronization protocol and the CALDAV-clients give me some headaches.
The main test client i use is the macos-calendar (sierra).
The initial handshake (DAV principle, calendar lookup) and inital load of data is working. I get some REPORT:calendar-query requests.
The issue is the incremental sync after initial load. There are two approaches:
Via WebSync-extension (REPORT:sync-collection and sync-token prop)
my main issue here is that provisioning the sync-token from the server is not trivial in my system. Changes and New data is not an issue, but physical deletion (not yet logged in the user context) and changes in the scope of group- and/or role-assignments. Maybe i need to consider to invalidate in complex cases the sync-token and let the client resetup without sync-collection?
A nasty workaround could be to retain the calendar item IDs send to the client and check on each request for their existence and responds if necessary with a not found per deleted/out of scope calendar item. But this would mean i store client-state on the server which doesnt sound right and might be error prone.
Via basic protocal synchronization (respond to REPORT:calendar-query and propfind (depth=1) requests no webdav-sync active)
this is also working already in principle for new and changed data. But the macos-calendar doesnt remove items which are not part the collection response (propfind with depth=1). According to the protocol the client should determine the deleted items and remove them, but it doesnt do it in my case. Any ideas here?
For my system currently it would be ideal to use this approach though the performance might be not the ideal one.
With ios-Calendar i face another issue:
Initial handshake is somehow working as the requests in the network are coming and are answered.
But than a MKCALENDAR request is coming (instead of a calendar-query or propfind for items) which answer with 403 as i also dont provide it in the Allow-header of the options response. the request looks like this:
MKCALENDAR /services/cal/_userid/220EDB4A-F00C-41C9-B78F-10781BBA77E4/ HTTP/1.1
Host: 127.0.0.1:8003
Content-Type: text/xml
User-Agent: iOS/10.0.1 (14A403) dataaccessd/1.0
<?xml version="1.0" encoding="UTF-8"?>
<B:mkcalendar xmlns:B="urn:ietf:params:xml:ns:caldav">
<A:set xmlns:A="DAV:">
<A:prop>
<B:calendar-free-busy-set>
<NO/>
</B:calendar-free-busy-set>
<D:calendar-order xmlns:D="http://apple.com/ns/ical/">1</D:calendar-order>
<A:displayname>Kalender</A:displayname>
<B:calendar-timezone>BEGIN:VCALENDAR
...deleted....
</B:calendar-timezone>
<B:supported-calendar-component-set>
<B:comp name="VEVENT"/>
</B:supported-calendar-component-set>
</A:prop>
</A:set>
</B:mkcalendar>
Nothing is happening afterwards.
Anyone experiencing this as well? Why ios-calendar tries to do a mkcalendar though i have a calendar-collection as resource-type?
With Thunderbird Lightning:
Initial handshake with the calendar-collection is working
A propfind-and multiget request for items is answered with iCal-Items.
But they are not displayed and in the error log i receive:
Warnung: CalDAV: Get failed: CalDAV: Error: got status 200 fetching calendar data for Debug Proxy, null
(text in german: error code: 0x80004005) Warnung: Fehler beim Lesen von Daten für Kalender: Debug Proxy. Allerdings ist dieser Fehler wahrscheinlich vernachlässigbar, daher versucht das Programm fortzufahren. Fehlercode: 0x80004005. Beschreibung: CalDAV: Error: got status 200 fetching calendar data for Debug Proxy, null
(text in german: error code: READ_FAILED) Warnung: Fehler beim Lesen von Daten für Kalender: Debug Proxy. Allerdings ist dieser Fehler wahrscheinlich vernachlässigbar, daher versucht das Programm fortzufahren. Fehlercode: READ_FAILED. Beschreibung:
http channel Listener OnDataAvailable contract violation
a similiar response is though working in macos-calendar – could it be some encoding issue?
Any hints are highly appreciated!
This is indeed a pretty broad question. But let me try to address some stuff:
Via WebSync-extension (REPORT:sync-collection and sync-token prop) my main issue here is that provisioning the sync-token from the server is not trivial in my system
Even if it is hard for you, you should really try to come up with something here. Even if this means storing some extra info on the server. Sync-collection is way more efficient.
(Idea: Maybe you can at least set a flag when something actually got deleted and only then expire the sync-token?)
Via basic protocal synchronization (respond to REPORT:calendar-query and propfind (depth=1))
Which one, calendar-range-query or PROPFIND? Completely different things ...
this is also working already in principle for new and changed data. But the macos-calendar doesnt remove items which are not part the collection response (propfind with depth=1).
If we are talking about a calendar-range-query, the client cannot proactively delete items since it doesn't know whether they just left the range (vs being deleted).
With PROPFIND it should do this. If you have proof it doesn't, maybe create another question with all the relevant details.
With ios-Calendar i face another issue: ... a MKCALENDAR request is coming ...
This probably means that it can't find the default scheduling calendar, no calendar at all, none with a proper component-type property. Or all the same for todos (Reminders app, same account). What is the payload of the MKCALENDAR?
Hard to diagnose w/o details, if you can't figure it out, ask a specific question on this with all the relevant details included (e.g. the XML you send in response to the home query).
Thunderbird Lightning
Can't say much about this, probably depends a lot on the version and what extensions you are using. AFAIK many people use the ScalableOGo Thunderbird extensions to get proper Cal/CardDAV with Thunderbird.
For Thunderbird/Lightning you may want to turn on calendar.debug.log and calendar.debug.log.verbose in the advanced config editor and restart. You can find it in Options > Advanced > General > Config Editor. This will get you more detailed http requests and information about what failed. You can also hook up the remote debugger and look at the network monitor, or set breakpoints in the code.
With Thunderbird/Lightning please note that we are using a mix of previous and current versions of the webdav-sync draft. I can't say much from the error message as is given it is very general, but it does look like there is something unexpected in the results.
Maybe it makes sense to compare the handshake between an existing server (like sabre/dav) and the client, then see where the difference between your communication and theirs is.
Also, you may be interested in the CalDAVTester from Apple, which checks server interoperability. Note however that it does contain various apple specific tests. The folks at CalConnect are working together with Apple to make it more generally usable and to split out the Apple-specific tests. Given your server is read-only, don't expect everything to work, but you can hunt for fixing specific tests.
I'm using SO_NEW_DOCUMENT_ATT_SEND_API1 function to send an email with an attachment both for a sap user and for an external email. So far, so good. I discovered that the sender of these emails is the sap user that fired the report and the function doesn't have the sender exportation parameter like the old SO_DOCUMENT_SEND_API1 has. The problem is that I need the sender to be an external email. I've been searching and couldn't make this happen. Can anyone help or give me an idea? Thanks
As I have already stated in an answer to another question of yours, stop using the old API and use the new BCS API. The documentation contains an example on how to change the sender address:
DATA: lr_send_request TYPE REF TO cl_bcs,
lr_sender TYPE REF TO cl_cam_address_bcs.
lr_sender = cl_cam_address_bcs=>create_internet_address( 'foo.bar#baz.com' ).
lr_send_request->set_sender( lr_sender ).
Just try to copy the example report BCS_EXAMPLE_1 to your local namespace and exchange the line that sets the sender (line 50 in my release, might be a different one on your system).
I'm trying to learn the XMPP spec (RFC 3920) by coding it in low-level Python. But I've been hung up for over an hour at step 4 of section 6.5, selecting an authentication mechanism. I'm sending: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='PLAIN'/>, and getting: <failure xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><incorrect-encoding/></failure> instead of a base64-encoded challenge.
The "incorrect-encoding" error is supposedly to be used for when I incorrectly base64-encode something, but there was no text to encode. I'm probably missing something really obvious. Anybody got a cluestick?
I'm using talk.google.com port 5222 as the server, if that matters. I doubt that it does; this is almost definitely due to my lack of understanding this section of the RFC. And the problem isn't likely my code, other than the way I'm sending this particular stanza, or it would be failing at the previous steps. But for what it's worth, here is the code I've got so far, and the complete log (transcript of the session). Thanks.
First off, RFC 6120 is often more clear than 3920. [updated to point to the RFC as released]
Since you're using SASL PLAIN (see RFC 4616), many servers expect you to send a SASL "initial response" in the auth element, consisting of:
base64(\x00 + utf8(saslprep(username)) + \x00 + utf8(saslprep(password)))
All together, then, your auth element needs to look like this:
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='PLAIN'>AGp1bGlldAByMG0zMG15cjBtMzA=</auth>
For the username "juliet" and the password "r0m30myr0m30".
Ok, the problem should be trivial but I can't get to the bottom of it.
I have two users A & B
Their JID's for this example will be A#123 and B#123 where 123 is the IP of the server.
I'm sending a message from A->B using the following code:
chat = chatmanager.createChat(username,
new MessageListener() {
public void processMessage(Chat chat, Message message) {}});
String sendUsername = username + "#123";
Message msgObj = new Message(sendUsername, Message.Type.chat);
msgObj.setBody(message);
chat.sendMessage(msgObj);
I've hardcoded the IP so that I'm 100% sure that I attach the "#123" at the end of the nickname so there are no incorrect JIDs.
So A#123 sends msgObj to B#123. This is how I understood XMPP messaging to work. That you can't send from A->B but it must be A#123 -> B#123.
However, my server seems to think otherwise. It continuously informs me of the following error:
2010.12.27 19:02:52 [org.jivesoftware.openfire.session.LocalOutgoingServerSession
.createOutgoingSession(LocalOutgoingServerSession.java:258)] Error trying to
connect to remote server: A(DNS lookup: A:5269)
java.net.UnknownHostException: A
In both A and B's roster on the Openfire server, they have each other as a contact with the proper JIDs (username#123).
Can anyone provide some insight? I'm lost.
Edit
I'm trying to use Wireshark to catch the XML sent to and from the Openfire server to determine if the recipient of the message is named properly (A#123 instead of A).
Upon using Wireshark, I received this as the XML being transferred:
\302\3469\223\341\3429\000\000\000\000\377\377
I have disabled SSL, I have connected un-securely. I'm not sure why I'm getting SSL type XML, is that what it is?
Turns out the answer to this problem was something that was just overlooked.
In the first line of code:
chat = chatmanager.createChat(username, new MessageListener() {
public void processMessage(Chat chat, Message message) {}
});
I didn't make the variable "username" have the proper IP extension. So it was merely "A" instead of "A#123"
Moving "sendUsername" to the top and Changing "username" to "sendUsername" makes everything work great :)
Silly mistake.
Using IP addresses is almost always more confusing than you think it is.
There's a good chance you have OpenFire misconfigured, so that the IP address isn't a valid hostname. Go into the admin console, under "System Properties", and make sure that the xmpp.domain property is set to your IP address.