I am currently writing an application in java using the the JAIN SIP library, I've been trying for the past couple of days to implement presence using SUBSCRIBE and NOTIFY messages. I currently have NOTIFY messages which has a content type of "message/sipfrag;version=2.0", and need this to be XML and PIDF.
I'm aware I need to use an event header with "presence", and also a content type header.
Are there any places I can go to where there is information on this or are there any other specific headers or classes and/or methods needed to make this work? I already have a client which I can make calls on, but need to implement presence now.
FYI, rfc3863 only defines the basic structure/semantics of a presence document. PIDF establishes a rudimentary presence document to be a status - with optional contact info, and other info (defined per the PIDF schema). PIDF does not really prescribe presence protocol. For those you need to review [RFC3265][1] and the details of the presence event package [RFC3856][2]. If we stick to a non-IMS network, the usual call-flow involves:
SIP registration to the SIP/REGISTRAR user-agent-server (UAS) accessible to the client. This also establishes the presence-entities (presentity) AoR (Address of Record) - who you are and how you can be reached - i.e. assuming you want to be contacted.
SIP:PUBLISH - with 3 very key parts. Firstly, an 'Event' header indicating support for the presence package, the content-type appropriately set to PIDF MIME-type and the correct body.
PUBLISH sip:bob#example.org SIP/2.0
...
Event: presence
Content-type: application/pidf+xml
Content-length: xyz
open
Once you have successfully published, you can then try a SUBSCRIBE method - to try and obtain status of another presence entity (e.g. user jane#example.org). For a SIP SUBSCRIBE the minimal is defining an appropriate presentities SIP/URI and specifying the correct 'event-package'. Look closely at the indicated RFCs - 3265 / 3856 will help guide you on basic behavior.
Best of luck.
[1]: https://www.rfc-editor.org/rfc/rfc3265#section-4
[2]: https://www.rfc-editor.org/rfc/rfc3856#section-5
There is more than one way to do presence in SIP. If you are sure PIDF is used then you should just use the RFC as reference https://www.ietf.org/rfc/rfc3863.txt. JSIP will work just fine as far as the SIP headers go, it will construct and parse the SIP messages correctly. The actual SIP message content parsing/construction is responsibility of the app. Jitsi is an open source client that has presence if you want to peek at some example code, but it may be totally different from your case.
Related
REST endpoint design says: Not use verb
In an workflow-like create Employee which has multi-tab style like "Basic Details", "Educational Details", "Work Experience", etc... One first tab data is filled continue button is pushed resulting in an backend API call which just validates the detail in that tab and returns the list of validation errors if any or moves to next tab for the user to fill data. So basically this calls for validate API for each of the tabs with no intention of saving data. Now one thing that comes naturally is below:
POST /employee/basic/validate
(removing api versioning details from endpoint for simplicity)
But using validate in API means verb. How to design then?
There's a separate flow where one can just save "basic details" of employee - so its like any normal API validate and save - so POST /employee/basic/ is good for that case.
REST endpoint design says: Not use verb
That's not a REST constraint - REST doesn't care what spellings you use for your resource identifiers.
All of these URL work, exactly the way that your browser expects them to:
https://www.merriam-webster.com/dictionary/post
https://www.merriam-webster.com/dictionary/get
https://www.merriam-webster.com/dictionary/put
https://www.merriam-webster.com/dictionary/patch
https://www.merriam-webster.com/dictionary/delete
Resources are generalizations of documents; the nature of the HTTP uniform interface is that we have a large set of documents, and a small number of messages that we can send to them.
So if you want a good resource identifier, the important thing to consider is the nature of the "document" that you are targeting with the request.
For instance, the document you are using to validate user inputs might be the validation policy; or you might instead prefer to think of that document as an index into a collection of validation reports (where we have one report available for each input).
Seems that what you try to do in the end is to run your operation in dry-run mode.
My suggestion would be to add a dry-run option as request parameter for instance.
/employee/basic?dry-run=true
REST says that you should use standards like HTTP to achieve a uniform interface. There are no URL standards as far as I know, even OData says that its URL naming conventions are optional.
Another thing that the browser is a bad REST client. REST was designed for webservices and machine to machine communication, not for the communication of browsers with webapplications, which is sort of human to machine communication. It is for solving problems like automatically order from the wholesaler to fill my webshop with new items, etc. If you check in this scenario both the REST service and REST client are on servers and have nothing to do with the browser. If you want to use REST from the browser, then it might be better to use a javascript based REST client. So using the browser with HTML forms as a REST client is something extreme.
If you have a multitab form, then it is usually collected into a session in regular webapplications until it is finalized. So one solution is having a regular webapplication, which is what you actually have, since I am pretty sure you have no idea about the mandatory REST constraints described by Fielding. In this case you just do it as you want to and forget about REST.
As of naming something that does validation I would do something like POST /employee/basic/validation and return the validation result along with 200 ok. Though most validation rules like "is it a date", "is it a number", etc. can be done on the clients currently they can be done even in HTML. You can collect the input in a session on server or client side and save it in the database after finilazing the employee description.
As of the REST way I would have a hyperlink that describes all the parameters along with their validations and let the REST client make tabs and do the REST. At the end the only time it would communicate with the REST service is when the actual POST is sent. The REST client can be in browser and collect the input into a variable or cookies or localstorage with javascript, or the REST client can be on server and collect the input into a server side session for example. As of the REST service the communication with it must be stateless, so it cannot maintain server side session, only JWT for example where all the session data is sent with every request.
If you want to save each tab in the webservice before finalizing, then your problem is something like the on that is solved with the builder design pattern in programming. In that case I would do something like POST /employeeRegistrationBuilder at the first step, and which would return a new resource something like /employeeRegistrationBuilder/1. After that I can do something like PUT/POST /employeeRegistrationBuilder/1/basics, PUT/POST /employeeRegistrationBuilder/1/education, PUT/POST /employeeRegistrationBuilder/1/workExperience, etc. and finalize it with PUT/POST /employeeRegistrationBuilder/1/finished. Though you can spare the first and the last steps and create the resource with the basics and finish it automagically after the workExperience is sent. Cancelling it would be DELETE /employeeRegistrationBuilder/1, modifying previous tabs would be PUT/PATCH /employeeRegistrationBuilder/1/basics. Removing previous tabs would be DELETE /employeeRegistrationBuilder/1/basics.
A more general approach is having a sort of transaction builder and do something like this:
POST /transactions/ {type:"multistep", method: "POST", id: "/employee/"}
-> {id: "/transactions/1", links: [...]}
PATCH /transactions/1 {append: "basics", ...}
PATCH /transactions/1 {append: "education", ...}
PATCH /transactions/1 {remove: "basics", ...}
PATCH /transactions/1 {append: "workExperience", ...}
PATCH /transactions/1 {append: "basics", ...}
...
POST /employee/ {type: "transaction", id: "/transactions/1"}
-> /employee/123
With this approach you can create a new employee both in multiple steps or in a single step depending on whether you send actual input data or a transaction reference with POST /employee.
From data protection (GDPR) perspective the transaction can be the preparation of a contract, committing the transaction can be signing the contract.
I am working on receiving mails in my springboot application. In order to fetch and store the receive mails. I am using imap mail listener. There are two types of mails which I am storing. One is multipart payload type and the other is string payload type.
After receiving mail I am trying to send an auto-generated mails using java mail.
The issue which I am facing is worst case scenario of generating auto-reply from my application i.e infinite loop.
Can someone help ow can I differentiate between a normal mail received and auto-reply received in my mail box and generate auto-replies from my system only for those mails which are not auto-reply type.
It would be nice if explained via code for headers check. I came across through few headers like x-Autosubmitted. But they are returning null if I am trying to print the values in console.
The auto-submmitted markers are described below that you may find helpful:
auto-generated - Indicates that a message was generated by an automatic process, and is not a direct response to another message.
auto-replied - Indicates that a message was automatically generated as a direct response to another message.
auto-notified - Indicates that a message was generated by a Sieve notification system.
no - Indicates that a message was NOT automatically generated, but was created by a human. It is the equivalent to the absence of an Auto-Submitted header altogether.
The RFC 2822 states the following:
Though optional, every message SHOULD have a "Message-ID:" field.
Furthermore, reply messages SHOULD have "In-Reply-To:"
So, you may check for the "In-Reply-To:" value in the header.
Also you may add your own value to the outgoing email, so you may distinguish between an automatically generated reply from your system and manually created.
Him
When I inserting message into the Gmail using it's RESTFul api, I load the message from the rfc822 MimeMessage, this message contains original *"Received"*header, that for example has value Thu, 27 Feb 2014 19:57:07 -0800 (PST). When this message inserted into the Gmail, a new "Received" header is added and it has the date time stamp of the time when it was inserted and original header is not shown in the UI, it's presented in the email, but its value is not used to show when the message was inserted. Is there any way to change this behaviour ?
Thanks
Have you tried setting the "internalDateSource" query parameter to the value "dateHeader" on the insert request yet? By default it uses "receivedTime" which would cause the functionality you describe.
Here is the link for reference. The information your looking for can be found under the "Parameters" header:
https://developers.google.com/gmail/api/v1/reference/users/messages/insert
Once I changed the code to set internalDateSource = "dateHeader" the messages original date value was displayed in the user's Gmail mailbox instead of the time the server received the message. I tested by using the before: command in the search bar of the user's mailbox to make sure it worked.
Here is a list of commands:
https://support.google.com/mail/answer/7190
FWIW, I'm using the .NET Client API wrapper for the Gmail API, so I'm not making the REST calls directly. However, setting the property in .NET relating to this value seems to do the trick for me. Hopefully this works out for you.
I believe this is by design, even for mail received through normal channels.
Consider that the headers can be faked, for example, I can craft an email that shows it was sent a year ago and send it to you now. Would you want to rely on the (potentially fake or incorrect) headers, or the actual time it was received, when looking at your inbox? So what you are really asking is to change the time an email was received by Google's server, the public GMail API does not expose that functionality.
It is not so bad though, the search for old imported emails uses the sent date header and not the received date header, so you can still filter by time range.
The additional Received header is benign. What you're talking about is whether the message's internal date is based on the Date header or the current timestamp. As you noticed, presently it always uses the current time and doesn't allow using Date.
Are you using messages.insert or messages.import (or something else like messages.send)?
For messages.insert and messages.import (only to the current mailbox) allowing the internal date to be the "Date" header seems like a reasonable option. Not for something like messages.send though given the potential to forge, etc.
I'm developing a program that queries and prints out open data from the local transit authority, which is returned in the form of an XML response.
Normally, when there are buses scheduled to run in the next few hours (and in other typical situations), the XML response generated by the page is handled correctly by the java.net.URLConnection.getInputStream() function, and I am able to print the individual results afterwards.
The problem is when the buses are NOT running, or when some other problem with my queries develops after it is sent to the transit authority's web server. When the authority developed their service, they came up with their own unique error response codes, which are also sent as XMLs. For example, one of these error messages might look like this:
<Error xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<Code>3005</Code>
<Message>Sorry, no stop estimates found for given values.</Message>
</Error>
(This code and similar is all that I receive from the transit authority in such situations.)
However, it appears that URLConnection.getInputStream() and some of its siblings are unable to interpret this custom code as a "valid" response that I can handle and print out as an error message. Instead, they give me a more generic HTTP/1.1 404 Not Found error. This problem cascades into my program which then prints out a java.io.FileNotFoundException error pointing to the offending input stream.
My question is therefore two-fold:
1. Is there a way to retrieve, parse, and print a custom XML-formatted error code sent by a web service using the plugins that are available in Java?
2. If the above is not possible, what other tools should I use or develop to handle such custom codes as described?
URLConnection isn't up to the job of REST, in my opinion, and if you're using getInputStream, I'm almost certain you're not handling character encoding correctly.
Check out Spring's RestTemplate - it's really easy to use (just as easy as URLConnection), powerful and flexible. You will need to change the ResponseErrorHandler, because the default one will throw an exception on 404, but it looks like you want it to carry on and parse the XML in the response.
I have a question about ActiveMQ and the AJAX Interface concerning the life span of a message. In the AMQ web interface, I can set a TimeToLive Value for a message in milliseconds.
I've already found out, that I can use this parameter via REST:
curl -vd body="test" "http://localhost:8161/demo/message/TESTQUEUE?type=queue&JMSTimeToLive=500&JMSPersistent=-1"
This example message will live 500ms
But how can I use the AMQ Ajax Interface to set those parameters?
The JavaScript function to send a message provides only two parameters
amq.sendMessage(myDestination,myMessage);
Info: http://activemq.apache.org/ajax.html
myDestination is unfortunately not an URL, it's something like this "queue://"
Thanks four your help
Regards
Rolf
The current implementation of the AJAX client does not offer the possibility to send a message with a time to live.
The time to leave of the message is basically set in the message property (headers), via the property "JMSExpiration"
Currently if you go through the amq.js code, you see there is no API that allows you to define the headers or Time to Live.
It should be relatively easy to add this feature to the client. Check the code, you could probably just hardcode the TTL for your application. At the end, it just does a post command in the same way that you do your REST call.