Kamailio - Dispatcher determine availability via http? - sip

We are currently using the dispatcher module in kamailio to get the availability of gateways via the dispatch list.
It uses a health check based on if it can talk to the gateway via SIP by default. However, I would like to know if we can make the check better by also checking via a http health check?
The reason for this is because when the gateway on the other end is in courtesy shutdown the dispatcher still sends calls to it even though we would like the box to shutdown. This leads to the gateway always staying up.
Alternatively there might be a better way of handling this by sending a message back in the sip packet to kamailio.
I have read through the documentation but I can't seem to find anything like what I am looking for.

The Dispatcher module has Event Routes that can be called when a SIP destination goes down / up. There are no Event Routes for HTTP as it's not constantly queried in it's own thread by Dispatcher.
Alternatively there might be a better way of handling this by sending a message back in the sip packet to kamailio.
You can however set the dispatcher state using the ds_mark_dst([state]) function. Through this you could add a custom header in any SIP message from your box that's shutting down to tell Kamailio's Dispatcher to not use it as a destination in the future.
If we added an imaginary header called "X-SetState" with the value "Shutdown" and send it from our box that's shutting down to Kamailio in a SIP message we could pick it up with something like this:
is_present_hf("X-SetState"){ //If custom header is present
xlog("Received state change request ($ru) with value $hdr(X-SetState)")
if($hdr(X-SetState) == "Shutdown"){ //If value of header is Shutdown
ds_mark_dst("dp"); //Mark destatination as disabled & probing
}
}
Obviously you'd need to add your own code to select the right dispatcher to mark inactive and ensure that the X-SetState header was only parsed if it came from your internal boxes you want to mark as down but you get the idea.
However, I would like to know if we can make the check better by also checking via a http health check?
Dispatcher at the moment has no support for monitoring HTTP state, but adding it wouldn't be that difficult to implement, if you're handy at C you could add support or add a feature request.
Alternatively you could write an script to monitor HTTP status of each device and the using Kamcmd / Kamctl set the dispatcher group to down if it doesn't get a response.

Related

URLSession: how to check what cookies were sent with the request?

There is no doubt that the HTTPCookie is indeed inside the HTTPCookieStorage, but I wonder if there is any way to confirm that it's being sent from programmatic standpoint?
Of course intercepting HTTP traffic via sniffers doesn't count.
There is no way to check that programmatically - the notion of HTTPCookieStorage being configured on the URLSessionConfiguration leads to it completely obscuring the Cookie-related details from the programmer. It operates like magic way out of scope of your vision.
To be honest, I couldn't even tell you that happens if you set Cookie header manually via allHTTPHeaderFields but if there were already cookies for this very same domain and path in the HTTPCookieStorage - like, do they get merged, or does your custom header get discarded...

To PUT, POST or PATCH?

I have a REST Service that can be used to control databases, I want to allow calls to Stop & Start the databases, but was wondering what would be the correct Method?
By calling the Stop or Start Operation I am changing the state of the resource so a PUT seems sort of right, but is PATCH better or even POST?
Any suggestions?
Replacing the state of a resource
REST is protocol independent and is a resource-oriented architecture. When implementing REST applications over the HTTP protocol, for example, the resource is identified by the URI and the operation over the resource is expressed by the HTTP method.
PUT is the HTTP method used to replace the state of a resource and the new state of the resource will be expressed in the request payload using, for example, JSON and/or XML.
So you could consider the following design to start/stop a database:
PUT /databases/:id/status HTTP/1.1
Content-Type: application/json
{
"value": "started"
}
PUT /databases/:id/status HTTP/1.1
Content-Type: application/json
{
"value": "stopped"
}
To obtain the state of a resource, use GET:
GET /databases/:id/status HTTP/1.1
Response status codes
You certainly will need to inform your client about the result of the operation. To do it, use the HTTP response status codes.
A few status that might be useful:
200: Use this status to indicate that the request has succeeded.
202: Use this status code to indicate the request has been accepted for processing, but the processing has not been completed.
204: Use this status code to indicate the server has successfully fulfilled the request and that there is no additional content to send in the response payload body.
409: Use this indicates that the request could not be completed due to a conflict with the current state of the target resource.
Jim Webber explains that "HTTP is the application protocol of transferring documents" The transitions of state in your application are a side effect triggered by the document transfer.
Think old fashioned paper driven business office: the boss comes along and drops a TODO message in your inbox, which says "stop the database". As a side effect, you swivel your chair around and initiate the clean shutdown procedure.
Idiomatically, therefore, the representation you are sending to the REST server is that of the TODO message, and you are sending it to either (a) a resource that represents the "inbox" -- ie, a specific collection of TODO messages -- or (b) a resource that represents the TODO document itself.
I have a REST Service that can be used to control databases, I want to allow calls to Stop & Start the databases, but was wondering what would be the correct Method?
By calling the Stop or Start Operation I am changing the state of the resource so a PUT seems sort of right, but is PATCH better or even POST?
Since you are sending a complete message, rather than trying to make a modification to a message that the REST server already knows about, PATCH is not appropriate.
DELETE is also not appropriate - delete is analogous to destroying the TODO message in the inbox.
If the media type that you are using to represent application state at the client is HTML, then the verb you use shall be POST, because HTML doesn't support PUT.
If you are delivering a representation of a single message to a resource that represents a collection, then the verb you use shall be POST, because the semantics of PUT imply "create/overwrite" of a resource, and the semantic you are expressing is append.
If you are delivering a representation of a single message to a resource that represents that message alone (ie: you are doing a create of the message resource), then PUT is preferred to POST. The key idea here is that PUT promises that any side effects on the server are idempotent -- the side effect of successfully delivering N > 0 copies of the message are equivalent to the side effect of delivering exactly 1 copy. Using PUT as the verb shares that promise, not just with the client and server, but also with all of the intermediate connectors along the way.
Your idempotent resources can also support POST, and you can document in your API that the messages received are handled idempotently so that clients will understand, but there's no standardized way to inform the other connectors of this fact.
(Example: think about a form post in a browser. The resource at the server knows that the request can be handled idempotently. You can document in the html itself that hitting the button more than once is safe, but you don't have any way to tell the browser that, so the browser throws up a message to the user saying "re-POST might not be safe, are you sure Y/N?")
In summary, you want your choices of HTTP methods to agree with the uniform interface, so that the client, the server, and all of the components acting on the messages in between have a shared understanding of what's going on.

Mobicents SIP error response handling - what's the proper way to re-proxy?

The Mobicents SIP servlet container appears to handle error responses differently to other SIP containers I've used. The situation is that:
On receipt of an INVITE, app handles and proxies (supervised) downstream (so it may receive the responses to the invite).
On receipt of an error response from the initial target, app proxies to a new destination (in a non-supervised way).
This should prevent the initial error response from propagating upstream (since the transaction has a new target). However, with the Mobicents container, even though the INVITE is indeed proxied out to the new destination, the initially received error response still propagates upstream. I believe that this is a bug in the Mobicents implementation - but how does one work around this?
Code:
public void doInvite(SipServletRequest req) {
req.getProxy().proxyTo(req.getRequestURI());
}
public void doError(SipServletResponse res) {
Proxy p = res.getProxy();
p.setSupervised(false);
p.proxyTo(...);
// request is proxied, but the error response still passes
// upstream - the retargeting of the transaction (through
// proxying to a new destination ought to prevent that).
}
Which other SIP Containers are you migrating your application from ?
Are you doing sequential or parallel proxying ?
Which error response do you receive ?
Which version of the Mobicents SIP Servlets container are you using ?
Do you have a full log available on gist.github.com or pastebin.com ?
As a pure proxying solution the Mobicents is doing the right behavior of forwarding the Error response back to the call initiator and hence the logic of sequential forking [based on the error code] has to be dealt on the caller side.
But if you want this behavior by the mobicents, you need to run the B2BUA mode for the mobicents that should give you more granular control of deciding the behavior independent on the 2 calls legs [ ingress / egress ].
Originator gets a 183 Call Progress for the INVITE [ingress leg], while the sequential retries can be handled on the egress leg with no risk of the initial timeouts happening on the Ingress.

How to handle the consume of call PUT with Mulesoft

I 'd like to know how to handle and to design the flow to consume three sequential calls type PUT with muleSoft. I 'll enter from main flow by VM Connector and I insert HTTP connector to consume PUT with data in payload. To handle the errors if the first, second and third request PUT response unsuccessful (example status code 400),Where can I handle it? Must I another flow? how can I do?
Above I have already done Flow call Request Put
Assuming that you will have the same request for all 3 outbound call that you are calling sequentially , what you can do is
just after the VM inbound save your request in a variable, then call
the first HTTP call as you are doing.
After the HTTP outbound call for first service, set the payload with your variable and call your second service using another HTTP
Same steps as step 2 you follow for your 3rd call
Regarding exception, you can check here for handling https://developer.mulesoft.com/docs/display/current/Catch+Exception+Strategy
And to control HTTP status code, if you are using Mule 3.6+ version, you can easily control HTTP status code with your http:request component as given here with Status Code Validator:- https://developer.mulesoft.com/docs/display/current/HTTP+Request+Connector

Listening for incoming SIP messages using MjSip

I'm doing a university project in which i have to communicate with an existing server using SIP messages. I have done the part where i send the message, and i see with wireshark that the server responded, but i don't know how to receive that message and interpret it.
I have created a class that composes a sip message, and then creates a UdpTransport to send the message. I fill all of the message headers manually before that.
udp_transport = new UdpTransport(0, this);
udp_transport.sendMessage(sip_message, new IpAddress(toAddress), 5060);
Now i wonder how to receive the message the server sends back.
The declaration of MjSip SipProvider class (i modeled mine after it, they both call UDPTransport) implements TransportListener and has a callback methond onReceivedMessage()
but i'm not sure how to make it listen. I need to listen on a specific port, that the user inputs in the UI before. Not really sure how this callback even works.
So, i just need something to listen for a response message, and that it calls my processReceivedMessage() method so i can extract information.