balena / elixir-sippet

An Elixir library designed to be used as SIP protocol middleware.
BSD 3-Clause "New" or "Revised" License
76 stars 22 forks source link

Simple example #22

Closed anildigital closed 9 months ago

anildigital commented 3 years ago

Hello @balena, it would be great if you put up a simple ping pong example between two SIP user agents that talk to the SIP Server.

balena commented 3 years ago

Hey @anildigital,

We'll need to enter in more details here. Unfortunately SIP doesn't have a ping/pong mechanism. The closest is OPTIONS -> 200 OK. Say you have a core like this:

defmodule MyCore do
  @behaviour Sippet.Core

  alias MyCore.Router

  @impl true
  def receive_request(_incoming_request, _server_key) do
    :not_implemented
  end

  @impl true
  def receive_response(incoming_response, client_key),
    do: Router.route(client_key, incoming_response)

  @impl true
  def receive_error(reason, client_or_server_key),
    do: Router.route(client_or_server_key, reason)
end

Do the initialization steps and register it as usual.

Then your MyCore.Router should be able to route responses and errors to running processes.

A "process" can be modeled as a high level transaction (UAC in this case). Say you create the process initializing with the OPTIONS parameters (like destination, etc), the process registers to a regular Elixir Registry, it then create the SIP OPTIONS request, pass it to Sippet to be delivered, and on return, it will be passed to your core, than gets routed back to the process that created it.

balena commented 3 years ago

The above is just a quick example/approach. Sippet is a very open library, there will be multiple ways to solve a single problem. It could be acceptable to just take the response and finalize the application instead of routing to a running process somewhere (if you wanna get extremely simple).

anildigital commented 3 years ago

Thanks, @balena that was helpful. I have still not got the hang of sippet code, here is something I want to achieve.

client A (a modeled process / UAC) would send a REGISTER request (REGISTER sip:localhost SIP/2.0) and I want the core to respond to client A with the response as SIP/2.0 200 OK, considering the transaction is maintained. I think this use case involves 2 transactions, First is a client transaction for sending the request, second is a server transaction for sending a response.

Also in which use case, the core would receive receive_response?

balena commented 9 months ago

Circling back here, I'm closing this issue due to inactivity. Please open a new issue if your problem persists.