탱이의 잡동사니 - User contributions [en]

React flow - Layouting

2024-03-06T08:04:43Z

Pchero: Created page with "== Overview == React flow 내용정리. 원문은 이곳<ref>https://reactflow.dev/learn/layouting/layouting</ref>에서 확인할 수 있다. == Layouting Libraries == We regularly get asked how to handle layouting in React Flow. While we could build some basic layouting into React Flow, we believe that you know your app's requirements best and with so many options out there we think it's better you choose the best right tool for the job (not to mention it'd be whole b..."

== Overview ==
React flow 내용정리. 원문은 이곳<ref>https://reactflow.dev/learn/layouting/layouting</ref>에서 확인할 수 있다.

== Layouting Libraries ==
We regularly get asked how to handle layouting in React Flow. While we could build some basic layouting into React Flow, we believe that you know your app's requirements best and with so many options out there we think it's better you choose the best right tool for the job (not to mention it'd be whole bunch of work for us).

To start let's put together a simple example flow that we can use as a base for testing out the different layouting options.

[[category:react]]

React flow - Customizing React Flow

2024-03-06T07:35:09Z

Pchero: /* Adding an edge label */

== Overview ==
Reactflow 정리 문서 원문은 이곳<ref>https://reactflow.dev/learn/customization/custom-nodes</ref>에서 확인할 수 있다.

== Custom Nodes ==
A powerful feature of React Flow is the ability to add custom nodes. Within your custom nodes you can render everything you want. You can define multiple source and target handles and render form inputs or charts for example. In this section we will implement a node with an input field that updates some text in another part of the application.

=== Implementing the Custom Node ===
A custom node is a React component that is wrapped to provide basic functionality like selecting or dragging. From the wrapper component we are passing props like the position or the data besides other props. Let's start to implement the TextUpdaterNode. We are using the Handle component to be able to connect our custom node with other nodes and add an input field to the node:
<pre>
import {useCallback} from 'react';
import {Handle, Position} from 'reactflow';

const handleStype = {left: 10 };

function TextUpdaterNode({data}) {
const onChange = useCallback((evt) => {
console.log(evt.target.value);
}, []);

return(
<>
<Handle type="target" position={Position.Top} />
<div>
<label htmlFor="text">Text:</label>
<input id="text" name="text" onChange={onChange} className="nodrag" />
</div>
<Handle type="source" position={Position.Botton} id="a" />
<Handle
type="source"
position={Position.Botton}
id="b"
stype={handleStyle}
</Handle>
</>
);
}
</pre>
As you see we've added the class name "nodrag" to the input. This prevents dragging within the input field and lets us select text for example.

=== Adding the Node Type ===
You can add a new node type to React Flow by adding to the nodeTypes props. It's important that the nodeTypes are memoized or defined outside of the component. Otherwise React creates a new object on every render which leads to performance issues and bugs.
<pre>
const nodeTypes = useMemo(() => ({ textUpdater: TextUpdaterNode }), []);

return <ReactFlow nodeTypes={nodeTypes} />;
</pre>

After defining your new node type, you can use it by using the type node option:
<pre>
const nodes = [
{
id: 'node-1',
type: 'textUpdater',
position: {x: 0, y: 0},
data: {value: 123},
},
];
</pre>
After putting all together and adding some basic styles we get a custom node that prints text to the console.

=== Using Multiple Handles ===
As you can see we added two source handles to the node so that it has two outputs. If you want to connect other nodes with these specific handles, the node id is not enough but you also need to pass the specific handle id. In this case one handle has the id "a" and other one "b".
Handle specific edges use the sourceHandle or targetHandle options that reference a handle within a node.
<pre>
const initialEdges = [
{id: 'edge-1', source: 'node-1', sourceHandle: 'a', target: 'node-2' },
{id: 'edge-2', source: 'node-1', sourceHandle: 'b', target: 'node-3' },
];
</pre>
In this case the source node is node-1 for both handles but the handle ids are different. One comes from handle id "a" and the other one from "b". Both edges also have different target nodes:
<pre>
const initialNodes = [
{
id: "node-1",
type: "textUpdater",
position: { x: 0, y: 0 },
data: { value: 123 },
},
{
id: "node-2",
type: "output",
targetPosition: "top",
position: { x: 0, y: 200 },
data: { label: "node 2" },
},
{
id: "node-3",
type: "output",
targetPosition: "top",
position: { x: 200, y: 200 },
data: { label: "node 3" },
},
];

</pre>
Note that if you are programmatically changing the position or number of handles in your custom node, you will need to use the useUpdateNodeInternals hook to properly notify ReactFlow of changes. From here you should be abel to build your custom nodes. In most cases we recommend to use custom nodes only. The built-in ones are just basic examples.

=== Custom edges ===
Like custom nodes, parts of a custom edge in React Flow are just React component: that means you can render anything you want along an edge!

=== A basic custom edge ===
An edge isn't much use to us if it doesn't render a path between two connected nodes. These paths are always SVG-based and are typically rendered using the <BaseEdge /> component. To calculate the actual SVG path to render, React Flow comes with some handy utility functions:
* getBezierPath
* getSimpleBezierPath
* getSmoothStepPath
* getStraightPath

To kick start out custom edge, we'll just render a straight path between the source and target.
<pre>
import {BaseEdge, getStraightPath} from 'reactflow';

export default function CustomEdge({id, sourceX, sourceY, targetX, targetY}) {
const [edgePath] = getStraightPath({
sourceX,
sourceY,
targetX,
targetY,
});

return(
<>
<BaseEdge id={id} path={edgePath} />
</>
);
}
</pre>
This gives us a straight edge that behaves the same as the default "straight" edge type. To use it, we also need to update the edgeTypes prop on the <ReactFlow /> component.

It's important to define the edgeTypes object outside of the component or to use React's useMemo hook to prevent unnecessary re-renders. React Flow will show a warning in the console if you forget to do this.
<pre>
import ReactFlow from 'reactflow'
import CustomEdge from './CustomEdge'

const edgeTypes = {
'custom-edge': CustomEdge
}

export function Flow() {
return <ReactFlow edgeTypes={edgeTypes}... />
}
</pre>
After defining the edgeTypes objects, we can use our new custom edge by setting the type field of an edge to "custom-edge".

=== Adding an edge label ===
One of the more common uses for custom edges is rendering some controls or info along an edge's path. In React Flow we call that an edge label and unlike the edge path, edge labels can be any React component!

To render a custom edge label we must wrap it in the <EdgeLabelRenderer /> component. This is necessary for performance reasons; the edge label renderer is a portal to a single container that all edge labels are rendered into.

Let's add a button to our custom edge that can be used to delete the edge it's attached to:
<pre>
import {
BaseEdge,
EdgeLabelRenderer,
getStraightPath,
useReactFlow,
} from 'reactflow';

export default function CustomEdge({id, sourceX, sourceY, targetX, target Y}) {
const {setEdge} = useReactFlow();
const [edgePath] = getStraightPath({
sourceX,
sourceY,
targetX,
targetY,
});

return(
<>
<BaseEdge id={id} path={edgePath} />
<EdgeLabelRenderer>
<button
onClick={() => setEdges((edges) => edges.filter((e) => e.id !== id))}
>
delete
</button>
</EdgeLabelRenderer>
</>
);
}
</pre>
If we try to use this edge now, we'll see that the button is rendered in the center of the flow (it might be hidden behind "Node A"). Because of the edge label portal, we'll need to do some extra work to position the button ourselves.

Fortunately, the path utils we've already seen can help us with this! Along with the SVG path to render, these functions also return the x and y coordinates of the path's midpoint. We can then use these coordinates to translate our custom edge label's into the right position!
<pre>
export default function CustomEdge({id, sourceX, sourceYm targetX, targetY}) {
const {setEdges} = useReactFlow();
const [edgePath, labelX, labelY] = getStraightPath({});

return(
...
<button
style={{
position: 'absolute',
transform: `translate(-50%, -50%) translate(${labelX}px, ${labelY}px)`,
pointerEvents: 'all',
}}
calssName="nodrag nopan"
onClick={() => {
setEdges((es) => es.filter((e) => e.id !== id));
}}
>
...
);
}
</pre>

== Theming ==
React Flow has been built with deep customization in mind. Many of our users fully transform the look and feel of React Flow to match their own brand or design system. This guide will introduce you to the different ways you can customize React Flow's appearance.

=== Default styles ===
React Flow's default styles are enough to get going with the built-in nodes. They provide some sensible defaults for styles like padding, border radius, and animated edges.

You'll typically load these default styles by importing them in you App.jsx file or other entry point
<pre>
import 'reactflow/dist/style.css';
</pre>

Without dipping into custom nodes and edges, there are three ways you can style React Flow's basic look:
* Passing inline styles through style props.
* Overriding the built-in classes with custom CSS.
* Overriding the CSS variables React Flow uses.

=== Customizing with style props ===
The easiest way to start customizing the look and feel of your flows is to use the style prop found on many of React Flow's components to inline your own CSS.
<pre>
import ReactFlow from 'reactflow'

const styles = {
background: 'red',
width: '100%',
height: 300,
};

export default function Flow() {
return <ReactFlow style={styles} nodes={[...]} edges={[...]} />
}
</pre>

[[category:react]]

React flow - Customizing React Flow

2024-03-06T07:06:35Z

Pchero: /* A basic custom edge */

React flow - Customizing React Flow

2024-03-06T06:37:16Z

Pchero: /* A basic custom edge */

React flow - Customizing React Flow

2024-03-06T06:33:44Z

Pchero: /* Using Multiple Handles */

React flow - Customizing React Flow

2024-03-06T06:19:51Z

Pchero: /* Adding the Node Type */

React flow - Customizing React Flow

2024-03-06T06:07:48Z

Pchero: Created page with "== Overview == Reactflow 정리 문서 원문은 이곳<ref>https://reactflow.dev/learn/customization/custom-nodes</ref>에서 확인할 수 있다. == Custom Nodes == A powerful feature of React Flow is the ability to add custom nodes. Within your custom nodes you can render everything you want. You can define multiple source and target handles and render form inputs or charts for example. In this section we will implement a node with an input field that updates some t..."

React flow- Getting Started

2024-03-06T04:14:54Z

Pchero: /* Handle Connections */

== Overview ==
Reactflow 정리 문서
원문은 이곳<ref>https://reactflow.dev/learn/getting-started/installation-and-requirements</ref>에서 확인할 수 있다.

== Installation ==
=== Installation and Requirements ===
The React Flow package is published under reactflow on npm and installable via:

<pre>
$ npm install reactflow
</pre>

Now you can import the React Flow component and the styles in your application:
<pre>
import ReactFlow from 'reactflow';
import 'reactflow/dist/style.css';
</pre>

=== Prior Experience Needed ===
React Flow is a React library. That means React developers will feel comfortable using it. If basic React terms and concepts like states, props, components, and hooks are unfamiliar to you, you might need to learn more about React before being able to use React Flow fully.

== Building a Flow ==
=== Getting Started ===
Let's create an empty flow with a controls panel and a background. For this we need to import the components from the reactflow package:
<pre>
import ReactFlow, { Background, Controls } from 'reactflow';
</pre>

We can now use the components to render an empty flow:
<pre>
import ReactFlow, { Controls, Background } from 'reactflow';
import 'reactflow/dist/style.css';

function Flow() {
return (
<div style={{ height: '100%' }}>
<ReactFlow>
<Background />
<Controls />
</ReactFlow>
</div>
);
}

export default Flow;
</pre>

There are three important things to keep in mind here:
* You need to import the styles. Otherwise, React Flow won't work.
* The parent container needs a width and height, because React Flow uses its parent dimensions.
* If you have multiple flows on one page, you need to pass a unique id prop to each component to make React Flow work properly.

=== Adding Nodes ===
Now that the flow is set up, let's add some nodes. To do this, you need to create an array with node objects like this:
<pre>
const nodes = [
{
id: '1', // required
position: { x: 0, y: 0}, // required
},
];
</pre>

These nodes can now be added to the flow:
<pre>
import ReactFlow, {Controls, Background} from 'reactflow';
import 'reactflow/dist/style.css';

const nodes = [
{
id: '1',
position: {x: 0, y: 0},
},
];

function Flow() {
return(
<div style={{ height: '100%' }}>
<ReactFlow nodex={nodes}>
<Background />
<Controls />
</ReactFlow>
</div>
);
}

export default Flow;
</pre>

Let's add another node, configure labels and use the node type input for the first node.
<pre>
const nodes = [
{
id: '1',
position: {x: 0, y: 0},
data: {label: 'Hello'},
type: 'input',
},
{
id: '2',
position: {x: 100, y: 100},
data: { label: 'World' },
},
];
</pre>

=== Adding an Edge ===
Now that we have two nodes, let's connect them with an edge.

To make an edge, we need to specify two attributes: the source node(where the edge begins) and the target node(where the edge ends). We use the id of the two nodes to specify this (in our example, our two nodes have ids of "1" and "2"):
<pre>
const edges = [{id: '1-2", source: '1', target: '2'}]
</pre>

Let's give this edge two properties that are built into React Flow, a label and a different type.
<pre>
const edges = [
{
id: '1-2',
source: '1',
target: '2',
label: 'to the',
type: 'step',
},
];
</pre>

== Adding Interactivity ==
Let's make it so we can select, drag, and remove nodes and edges.

<pre>
In this Getting Started tutorial, we are going to use a "controlled component", which is typically the best and most flexible way to use React Flow in your own applications. You can also use React Flow in an uncontrolled way.
</pre>

=== Handle Change Events ===
First let's import a few things. To manage the changes in React, we'll be using useState and the two helper function applyEdgeChanges and applyNodeChanges from React Flow.
<pre>
import {useState, useCallback } from 'react';
import ReactFlow, {applyEdgeChanges, applyNodeChanges} from 'reactflow';
</pre>

We're going to set up states for both the nodes and edges:
<pre>
const [nodes, setNodes] = useState(initialNodes);
const [edges, setEdges] = useState(initialEdges);
</pre>

Directly beneath that, we'll add these two functions:
<pre>
const onNodesChange = useCallback(
(changes) => setNode((nds) => applyNodeChanges(changes, ndx)),
[],
);

const onEdgesChange = useCallback(
(changes) => setEdges((eds) => applyEdgeChanges(changes, eds)),
[],
);
</pre>
When you drag or select a node, the onNodeChange handler gets called. With help of the applyNodeChanges function you can then apply those changes to your current node state.

=== Handle Connections ===
One last piece is missing: connecting nodes manually. For this we need to implement an onConnect handler and pass it to the <ReactFlow /> component as well.

<pre>
import {addEdge} from 'reactflow';

const [edges, setEdges] = useState(initialEdges);
const onConnect = useCallback(
(params) => setEdges((eds) => addEdge(params, eds)),
[],
);
</pre>

[[category:react]]

React flow- Getting Started

2024-03-06T04:14:14Z

Pchero: /* Handle Connections */

== Overview ==
Reactflow 정리 문서
원문은 이곳<ref>https://reactflow.dev/learn/getting-started/installation-and-requirements</ref>에서 확인할 수 있다.

== Installation ==
=== Installation and Requirements ===
The React Flow package is published under reactflow on npm and installable via:

<pre>
$ npm install reactflow
</pre>

Now you can import the React Flow component and the styles in your application:
<pre>
import ReactFlow from 'reactflow';
import 'reactflow/dist/style.css';
</pre>

=== Prior Experience Needed ===
React Flow is a React library. That means React developers will feel comfortable using it. If basic React terms and concepts like states, props, components, and hooks are unfamiliar to you, you might need to learn more about React before being able to use React Flow fully.

== Building a Flow ==
=== Getting Started ===
Let's create an empty flow with a controls panel and a background. For this we need to import the components from the reactflow package:
<pre>
import ReactFlow, { Background, Controls } from 'reactflow';
</pre>

We can now use the components to render an empty flow:
<pre>
import ReactFlow, { Controls, Background } from 'reactflow';
import 'reactflow/dist/style.css';

function Flow() {
return (
<div style={{ height: '100%' }}>
<ReactFlow>
<Background />
<Controls />
</ReactFlow>
</div>
);
}

export default Flow;
</pre>

There are three important things to keep in mind here:
* You need to import the styles. Otherwise, React Flow won't work.
* The parent container needs a width and height, because React Flow uses its parent dimensions.
* If you have multiple flows on one page, you need to pass a unique id prop to each component to make React Flow work properly.

=== Adding Nodes ===
Now that the flow is set up, let's add some nodes. To do this, you need to create an array with node objects like this:
<pre>
const nodes = [
{
id: '1', // required
position: { x: 0, y: 0}, // required
},
];
</pre>

These nodes can now be added to the flow:
<pre>
import ReactFlow, {Controls, Background} from 'reactflow';
import 'reactflow/dist/style.css';

const nodes = [
{
id: '1',
position: {x: 0, y: 0},
},
];

function Flow() {
return(
<div style={{ height: '100%' }}>
<ReactFlow nodex={nodes}>
<Background />
<Controls />
</ReactFlow>
</div>
);
}

export default Flow;
</pre>

Let's add another node, configure labels and use the node type input for the first node.
<pre>
const nodes = [
{
id: '1',
position: {x: 0, y: 0},
data: {label: 'Hello'},
type: 'input',
},
{
id: '2',
position: {x: 100, y: 100},
data: { label: 'World' },
},
];
</pre>

=== Adding an Edge ===
Now that we have two nodes, let's connect them with an edge.

To make an edge, we need to specify two attributes: the source node(where the edge begins) and the target node(where the edge ends). We use the id of the two nodes to specify this (in our example, our two nodes have ids of "1" and "2"):
<pre>
const edges = [{id: '1-2", source: '1', target: '2'}]
</pre>

Let's give this edge two properties that are built into React Flow, a label and a different type.
<pre>
const edges = [
{
id: '1-2',
source: '1',
target: '2',
label: 'to the',
type: 'step',
},
];
</pre>

== Adding Interactivity ==
Let's make it so we can select, drag, and remove nodes and edges.

<pre>
In this Getting Started tutorial, we are going to use a "controlled component", which is typically the best and most flexible way to use React Flow in your own applications. You can also use React Flow in an uncontrolled way.
</pre>

=== Handle Change Events ===
First let's import a few things. To manage the changes in React, we'll be using useState and the two helper function applyEdgeChanges and applyNodeChanges from React Flow.
<pre>
import {useState, useCallback } from 'react';
import ReactFlow, {applyEdgeChanges, applyNodeChanges} from 'reactflow';
</pre>

We're going to set up states for both the nodes and edges:
<pre>
const [nodes, setNodes] = useState(initialNodes);
const [edges, setEdges] = useState(initialEdges);
</pre>

Directly beneath that, we'll add these two functions:
<pre>
const onNodesChange = useCallback(
(changes) => setNode((nds) => applyNodeChanges(changes, ndx)),
[],
);

const onEdgesChange = useCallback(
(changes) => setEdges((eds) => applyEdgeChanges(changes, eds)),
[],
);
</pre>
When you drag or select a node, the onNodeChange handler gets called. With help of the applyNodeChanges function you can then apply those changes to your current node state.

=== Handle Connections ===
One last piece is missing: connecting nodes manually. For this we need to implement an onConnect handler and pass it to the <ReactFlow /> component as well.

<pre>
import {addEdge} from 'reactflow';

const onConnect = useCallback(
(params) => setEdges((eds) => addEdge(params, eds)),
[],
);
</pre>

[[category:react]]

React flow- Getting Started

2024-03-06T04:03:30Z

Pchero: /* Adding Interactivity */

React flow- Getting Started

2024-03-05T12:21:56Z

Pchero: /* Adding Interactivity */

React flow- Getting Started

2024-03-05T07:12:27Z

Pchero: /* Adding an Edge */

React flow- Getting Started

2024-03-05T06:57:47Z

Pchero: /* Adding Nodes */

React flow- Getting Started

2024-03-05T06:47:32Z

Pchero: /* Adding Nodes */

React flow- Getting Started

2024-03-05T06:44:56Z

Pchero: Created page with "== Overview == Reactflow 정리 문서 원문은 이곳<ref>https://reactflow.dev/learn/getting-started/installation-and-requirements</ref>에서 확인할 수 있다. == Installation == === Installation and Requirements === The React Flow package is published under reactflow on npm and installable via: <pre> $ npm install reactflow </pre> Now you can import the React Flow component and the styles in your application: <pre> import ReactFlow from 'reactflow'; import 'r..."

Category:React

2024-03-05T06:19:29Z

Pchero: Created page with "category:programming"

[[category:programming]]

React flow

2024-03-05T06:18:17Z

Pchero: Pchero moved page React flow to React flow - Concept

#REDIRECT [[React flow - Concept]]

React flow - Concept

2024-03-05T06:18:17Z

Pchero: Pchero moved page React flow to React flow - Concept

== Overview ==
React flow 내용 정리.
원문은 이곳<ref>https://reactflow.dev/learn</ref>에서 확인할 수 있다.

== Introduction ==
=== Key features ===
Buillt-in plugins
* The <Background /> plugin implements some basic customisable background patterns.
* The <MiniMap /> plugin displays a small version of the graph in the corner of the screen.
* The <Controls /> plugin adds controls to zoom, center, and lock the viewport.
* The <Panel /> plugin makes it easy to position content on top of the viewport.
* The <NodeToolbar /> plugin lets you render a toolbar attached to a node.
* The <NodeResizer /> plugin makes it easy to add resize functionality to your nodes.

== Definitions ==
=== Nodes ===
A node in React Flow is a React component. That means it can render anything you like. Each node has an x- and y-coordinate, which tells it where it is placed in the viewport. You can find all the options for customizing your nodes in the Node options<ref>https://reactflow.dev/api-reference/types/node</ref> documentation.

==== Custom Nodes ====
This is where the magic of React Flow happens. You can customize nodes to look and act however you would like. Much of the functionality that you might create is not built-in to React Flow. Some of the things you might do with a custom node are:
* Render form elements
* Visualize data
* Support multiple handles.

=== Handles ===
A handle(also called "port" in other libraries) is the place where an edge attaches to a node. The handle can be placed anywhere, and styled as you like. It's just a div element. By default, it appears as a grey circle on the top, bottom, left, or fight of the nodes you can has as many handles as you need in your node. More information can be found in the handle docs<ref>https://reactflow.dev/api-reference/components/handle</ref>.

=== Edges ===
An edge connects two nodes. Every edge needs a target and a source node. React Flow comes with four built-in edge typee:default(bezier), smoothstep, step and straight. An edge is SVG path that can be styled with OSS and is completely customizable. If you are using multiple handles, you can reference them individually to create multiple connections for a node.

==== Custom Edges ====
Like custom nodes, you can also customize edges. Things that people do with custom edges are:
* Add a button to remove an edge.
* Custom routing behaviour.
* Complex styling or interactions that cannot be solved with just one SVG path.

You can find more information on the custom edges api<ref>https://reactflow.dev/api-reference/types/edge-props</ref> site.

=== Connection Line ===
React Flow has built-in functionality to click-and-drag from one handle to another in order to create a new edge. While dragging, the placeholder edge is called a connection line. The connection line also comes with four types built-in and is customizable. You can find the props for configuring the connection in the props section<ref>https://reactflow.dev/api-reference/react-flow#connection-line</ref>.

=== Viewport ===
All of React Flow exists inside of the viewport. The viewport has a x, y and zoom value. When you drag the pane, you change the x and y coordinates and when you zoom in or out you alter the zoom level.

== Core Concepts ==
A flow consists of nodes and edges(or just edges). You can pass arrays of nodes and edges as props to the ReactFlow component. Hereby all node and edge ids need to be unique. A node needs a position and a label(this could be different if you using custom nodes) and an edge needs a source(node id) and a target(node id). You can read more about the options in the Node options<ref>https://reactflow.dev/api-reference/types/node</ref> and Edge options<ref>https://reactflow.dev/api-reference/types/edge</ref> sections.

=== Controlled or Uncontrolled ===
With React Flow you have two ways to setup a flow. You can either create a controlled or an uncontrolled one. We recommend to use a controlled one but for simpler use cases you can also setup an uncontrolled flow.

=== Basic Functionality ===
By default, React Flow doesn't do any internal state updates besides handling the viewport when you setup a controlled flow. As with an <input /> component you need to pass handlers to apply the changes that are triggered by React Flow to your nodes and edges. In order to select, drag and remove nodes and edges you need to implement an onNodesChange and an onEdgesChange handler.

Whenever React Flow triggers a change(node init, node drag, edge select, etc.), the onNodeChange handler gets called. The React Flow export an applyNodeChanges handler so that you don't need to handle the changes by yourself. The applyNodeChanges handler returns an updated array of nodes that is your new nodes array. It allows following kind of interactions.
* selectable nodes and edges.
* draggable nodes.
* removable nodes and edges - (press Backspace to remove a selected node or edge, can be adjusted with the deleteKeyCode prop).
* multi-selection area by pressing Shift(that's the default selectionKeyCode).
* multi-selection by pressing command(that's the default multiSelectionKeyCode).

For convenience we export the helper hooks useNodeState and useEdgeState that you can use to create the nodes and edges state:
```
const [nodes, setNodes, onNodesChange] = useNodesState(initialNodes);
const [edges, setEdges, onEdgesChange] = useEdgesState(initialEdges);
```

=== Connecting Nodes ===
<pre>
const onConnect = useCallback(
(connection) =>
setEdges((eds) => addEdge({ ...connection, animated: true }, eds)),
[setEdges],
);
</pre>

or use the defaultEdgeOptions prop:
<pre>
const defaultEdgeOptions = { animated: true };
...
<ReactFlow
nodes={nodes}
edges={edges}
onNodesChange={onNodesChange}
onEdgesChange={onEdgesChange}
onConnect={onConnect}
defaultEdgeOptions={defaultEdgeOptions}
/>;
</pre>

==The Viewport ==
=== Panning and Zooming ===
The default pan and zoom behaviour of React Flow is inspired by slippy maps. You pan by dragging and zoom by scrolling. You can customize this behaviour easily with the provided props:
* panOnDrag: default: true
* selectionOnDrag: default: false
* panOnScroll: default: false
* panOnScrollSpeed: default: 0.5
* panOnScrollMode: default: 'free'. 'free'(all directions), 'vertical'(only vertical) or 'horizontal'(only horizontal).
* zoomOnScroll: default: true
* zoomOnPinch: default: true
* zoomOnDoubleClick: default: true
* preventScrolling: default: true
* zoomActivationKeyCode: default 'Meta'
* panActivationKeyCode: default 'Space'

=== Default Viewport Control ===
Default controls are:
* pan: drag mouse
* zoom: scroll
* create selection: Shift + drag

=== Figma-like Viewport Controls ===
If you prefer figma/sketch/design tool controls you can set panOnScroll={true} and selectionOnDrag={true};
* pan: Space + drag mouse, scroll, middle or right mouse.
* zoom: pitch or cmd + scroll
* create selection: drag mouse

== Plugin Components ==
React Flow comes with several additional plugin components.

=== MiniMap ===
If your flow gets bigger, you might want to get an overview quickly. For this we have built the MiniMap component. You can easily add it to your flow by adding it as a children.

=== Controls ===
React Flow comes with a customizable controls bar, that you can use by importing the Controls component.

=== Background ===
If you want to display the pattern background, you can use the Background component.

=== Panel ===
A helper component to display content on top of the React Flow viewport.

[[category:react]]

React flow - Concept

2024-03-01T14:57:00Z

Pchero: /* Background */

React flow - Concept

2024-03-01T14:48:56Z

Pchero: /* Controls */

React flow - Concept

2024-03-01T14:46:06Z

Pchero:

React flow - Concept

2024-03-01T14:37:51Z

Pchero: /* = Panning and Zooming */

== Overview ==
React flow 내용 정리.
원문은 이곳<ref>https://reactflow.dev/learn</ref>에서 확인할 수 있다.

== Introduction ==
=== Key features ===
Buillt-in plugins
* The <Background /> plugin implements some basic customisable background patterns.
* The <MiniMap /> plugin displays a small version of the graph in the corner of the screen.
* The <Controls /> plugin adds controls to zoom, center, and lock the viewport.
* The <Panel /> plugin makes it easy to position content on top of the viewport.
* The <NodeToolbar /> plugin lets you render a toolbar attached to a node.
* The <NodeResizer /> plugin makes it easy to add resize functionality to your nodes.

== Definitions ==
=== Nodes ===
A node in React Flow is a React component. That means it can render anything you like. Each node has an x- and y-coordinate, which tells it where it is placed in the viewport. You can find all the options for customizing your nodes in the Node options<ref>https://reactflow.dev/api-reference/types/node</ref> documentation.

==== Custom Nodes ====
This is where the magic of React Flow happens. You can customize nodes to look and act however you would like. Much of the functionality that you might create is not built-in to React Flow. Some of the things you might do with a custom node are:
* Render form elements
* Visualize data
* Support multiple handles.

=== Handles ===
A handle(also called "port" in other libraries) is the place where an edge attaches to a node. The handle can be placed anywhere, and styled as you like. It's just a div element. By default, it appears as a grey circle on the top, bottom, left, or fight of the nodes you can has as many handles as you need in your node. More information can be found in the handle docs<ref>https://reactflow.dev/api-reference/components/handle</ref>.

=== Edges ===
An edge connects two nodes. Every edge needs a target and a source node. React Flow comes with four built-in edge typee:default(bezier), smoothstep, step and straight. An edge is SVG path that can be styled with OSS and is completely customizable. If you are using multiple handles, you can reference them individually to create multiple connections for a node.

==== Custom Edges ====
Like custom nodes, you can also customize edges. Things that people do with custom edges are:
* Add a button to remove an edge.
* Custom routing behaviour.
* Complex styling or interactions that cannot be solved with just one SVG path.

You can find more information on the custom edges api<ref>https://reactflow.dev/api-reference/types/edge-props</ref> site.

=== Connection Line ===
React Flow has built-in functionality to click-and-drag from one handle to another in order to create a new edge. While dragging, the placeholder edge is called a connection line. The connection line also comes with four types built-in and is customizable. You can find the props for configuring the connection in the props section<ref>https://reactflow.dev/api-reference/react-flow#connection-line</ref>.

=== Viewport ===
All of React Flow exists inside of the viewport. The viewport has a x, y and zoom value. When you drag the pane, you change the x and y coordinates and when you zoom in or out you alter the zoom level.

== Core Concepts ==
A flow consists of nodes and edges(or just edges). You can pass arrays of nodes and edges as props to the ReactFlow component. Hereby all node and edge ids need to be unique. A node needs a position and a label(this could be different if you using custom nodes) and an edge needs a source(node id) and a target(node id). You can read more about the options in the Node options<ref>https://reactflow.dev/api-reference/types/node</ref> and Edge options<ref>https://reactflow.dev/api-reference/types/edge</ref> sections.

=== Controlled or Uncontrolled ===
With React Flow you have two ways to setup a flow. You can either create a controlled or an uncontrolled one. We recommend to use a controlled one but for simpler use cases you can also setup an uncontrolled flow.

=== Basic Functionality ===
By default, React Flow doesn't do any internal state updates besides handling the viewport when you setup a controlled flow. As with an <input /> component you need to pass handlers to apply the changes that are triggered by React Flow to your nodes and edges. In order to select, drag and remove nodes and edges you need to implement an onNodesChange and an onEdgesChange handler.

Whenever React Flow triggers a change(node init, node drag, edge select, etc.), the onNodeChange handler gets called. The React Flow export an applyNodeChanges handler so that you don't need to handle the changes by yourself. The applyNodeChanges handler returns an updated array of nodes that is your new nodes array. It allows following kind of interactions.
* selectable nodes and edges.
* draggable nodes.
* removable nodes and edges - (press Backspace to remove a selected node or edge, can be adjusted with the deleteKeyCode prop).
* multi-selection area by pressing Shift(that's the default selectionKeyCode).
* multi-selection by pressing command(that's the default multiSelectionKeyCode).

For convenience we export the helper hooks useNodeState and useEdgeState that you can use to create the nodes and edges state:
```
const [nodes, setNodes, onNodesChange] = useNodesState(initialNodes);
const [edges, setEdges, onEdgesChange] = useEdgesState(initialEdges);
```

=== Connecting Nodes ===
<pre>
const onConnect = useCallback(
(connection) =>
setEdges((eds) => addEdge({ ...connection, animated: true }, eds)),
[setEdges],
);
</pre>

or use the defaultEdgeOptions prop:
<pre>
const defaultEdgeOptions = { animated: true };
...
<ReactFlow
nodes={nodes}
edges={edges}
onNodesChange={onNodesChange}
onEdgesChange={onEdgesChange}
onConnect={onConnect}
defaultEdgeOptions={defaultEdgeOptions}
/>;
</pre>

===The Viewport ===
==== Panning and Zooming ====
The default pan and zoom behaviour of React Flow is inspired by slippy maps. You pan by dragging and zoom by scrolling. You can customize this behaviour easily with the provided props:
* panOnDrag: default: true
* selectionOnDrag: default: false
* panOnScroll: default: false
* panOnScrollSpeed: default: 0.5
* panOnScrollMode: default: 'free'. 'free'(all directions), 'vertical'(only vertical) or 'horizontal'(only horizontal).
* zoomOnScroll: default: true
* zoomOnPinch: default: true
* zoomOnDoubleClick: default: true
* preventScrolling: default: true
* zoomActivationKeyCode: default 'Meta'
* panActivationKeyCode: default 'Space'

==== Default Viewport Control ====
Default controls are:
* pan: drag mouse
* zoom: scroll
* create selection: Shift + drag

==== Figma-like Viewport Controls ====
If you prefer figma/sketch/design tool controls you can set panOnScroll={true} and selectionOnDrag={true};
* pan: Space + drag mouse, scroll, middle or right mouse.
* zoom: pitch or cmd + scroll
* create selection: drag mouse

=== Plugin Components ===
React Flow comes with several additional plugin components.

==== MiniMap ====
If your flow gets bigger, you might want to get an overview quickly. For this we have built the MiniMap component. You can easily add it to your flow by adding it as a children.

[[category:react]]

React flow - Concept

2024-03-01T14:21:02Z

Pchero:

== Overview ==
React flow 내용 정리.
원문은 이곳<ref>https://reactflow.dev/learn</ref>에서 확인할 수 있다.

== Introduction ==
=== Key features ===
Buillt-in plugins
* The <Background /> plugin implements some basic customisable background patterns.
* The <MiniMap /> plugin displays a small version of the graph in the corner of the screen.
* The <Controls /> plugin adds controls to zoom, center, and lock the viewport.
* The <Panel /> plugin makes it easy to position content on top of the viewport.
* The <NodeToolbar /> plugin lets you render a toolbar attached to a node.
* The <NodeResizer /> plugin makes it easy to add resize functionality to your nodes.

== Definitions ==
=== Nodes ===
A node in React Flow is a React component. That means it can render anything you like. Each node has an x- and y-coordinate, which tells it where it is placed in the viewport. You can find all the options for customizing your nodes in the Node options<ref>https://reactflow.dev/api-reference/types/node</ref> documentation.

==== Custom Nodes ====
This is where the magic of React Flow happens. You can customize nodes to look and act however you would like. Much of the functionality that you might create is not built-in to React Flow. Some of the things you might do with a custom node are:
* Render form elements
* Visualize data
* Support multiple handles.

=== Handles ===
A handle(also called "port" in other libraries) is the place where an edge attaches to a node. The handle can be placed anywhere, and styled as you like. It's just a div element. By default, it appears as a grey circle on the top, bottom, left, or fight of the nodes you can has as many handles as you need in your node. More information can be found in the handle docs<ref>https://reactflow.dev/api-reference/components/handle</ref>.

=== Edges ===
An edge connects two nodes. Every edge needs a target and a source node. React Flow comes with four built-in edge typee:default(bezier), smoothstep, step and straight. An edge is SVG path that can be styled with OSS and is completely customizable. If you are using multiple handles, you can reference them individually to create multiple connections for a node.

==== Custom Edges ====
Like custom nodes, you can also customize edges. Things that people do with custom edges are:
* Add a button to remove an edge.
* Custom routing behaviour.
* Complex styling or interactions that cannot be solved with just one SVG path.

You can find more information on the custom edges api<ref>https://reactflow.dev/api-reference/types/edge-props</ref> site.

=== Connection Line ===
React Flow has built-in functionality to click-and-drag from one handle to another in order to create a new edge. While dragging, the placeholder edge is called a connection line. The connection line also comes with four types built-in and is customizable. You can find the props for configuring the connection in the props section<ref>https://reactflow.dev/api-reference/react-flow#connection-line</ref>.

=== Viewport ===
All of React Flow exists inside of the viewport. The viewport has a x, y and zoom value. When you drag the pane, you change the x and y coordinates and when you zoom in or out you alter the zoom level.

== Core Concepts ==
A flow consists of nodes and edges(or just edges). You can pass arrays of nodes and edges as props to the ReactFlow component. Hereby all node and edge ids need to be unique. A node needs a position and a label(this could be different if you using custom nodes) and an edge needs a source(node id) and a target(node id). You can read more about the options in the Node options<ref>https://reactflow.dev/api-reference/types/node</ref> and Edge options<ref>https://reactflow.dev/api-reference/types/edge</ref> sections.

=== Controlled or Uncontrolled ===
With React Flow you have two ways to setup a flow. You can either create a controlled or an uncontrolled one. We recommend to use a controlled one but for simpler use cases you can also setup an uncontrolled flow.

=== Basic Functionality ===
By default, React Flow doesn't do any internal state updates besides handling the viewport when you setup a controlled flow. As with an <input /> component you need to pass handlers to apply the changes that are triggered by React Flow to your nodes and edges. In order to select, drag and remove nodes and edges you need to implement an onNodesChange and an onEdgesChange handler.

Whenever React Flow triggers a change(node init, node drag, edge select, etc.), the onNodeChange handler gets called. The React Flow export an applyNodeChanges handler so that you don't need to handle the changes by yourself. The applyNodeChanges handler returns an updated array of nodes that is your new nodes array. It allows following kind of interactions.
* selectable nodes and edges.
* draggable nodes.
* removable nodes and edges - (press Backspace to remove a selected node or edge, can be adjusted with the deleteKeyCode prop).
* multi-selection area by pressing Shift(that's the default selectionKeyCode).
* multi-selection by pressing command(that's the default multiSelectionKeyCode).

For convenience we export the helper hooks useNodeState and useEdgeState that you can use to create the nodes and edges state:
```
const [nodes, setNodes, onNodesChange] = useNodesState(initialNodes);
const [edges, setEdges, onEdgesChange] = useEdgesState(initialEdges);
```

=== Connecting Nodes ===
<pre>
const onConnect = useCallback(
(connection) =>
setEdges((eds) => addEdge({ ...connection, animated: true }, eds)),
[setEdges],
);
</pre>

or use the defaultEdgeOptions prop:
<pre>
const defaultEdgeOptions = { animated: true };
...
<ReactFlow
nodes={nodes}
edges={edges}
onNodesChange={onNodesChange}
onEdgesChange={onEdgesChange}
onConnect={onConnect}
defaultEdgeOptions={defaultEdgeOptions}
/>;
</pre>

===The Viewport ===
==== Panning and Zooming ===
The default pan and zoom behaviour of React Flow is inspired by slippy maps. You pan by dragging and zoom by scrolling. You can customize this behaviour easily with the provided props:
* panOnDrag: default: true
* selectionOnDrag: default: false
* panOnScroll: default: false
* panOnScrollSpeed: default: 0.5
* panOnScrollMode: default: 'free'. 'free'(all directions), 'vertical'(only vertical) or 'horizontal'(only horizontal).
* zoomOnScroll: default: true
* zoomOnPinch: default: true
* zoomOnDoubleClick: default: true
* preventScrolling: default: true
* zoomActivationKeyCode: default 'Meta'
* panActivationKeyCode: default 'Space'

==== Default Viewport Control ====
Default controls are:
* pan: drag mouse
* zoom: scroll
* create selection: Shift + drag
[[category:react]]

React flow - Concept

2024-03-01T14:16:40Z

Pchero: /* Connecting Nodes */

React flow - Concept

2024-03-01T14:16:22Z

Pchero: /* Connecting Nodes */

== Overview ==
React flow 내용 정리.
원문은 이곳<ref>https://reactflow.dev/learn</ref>에서 확인할 수 있다.

== Introduction ==
=== Key features ===
Buillt-in plugins
* The <Background /> plugin implements some basic customisable background patterns.
* The <MiniMap /> plugin displays a small version of the graph in the corner of the screen.
* The <Controls /> plugin adds controls to zoom, center, and lock the viewport.
* The <Panel /> plugin makes it easy to position content on top of the viewport.
* The <NodeToolbar /> plugin lets you render a toolbar attached to a node.
* The <NodeResizer /> plugin makes it easy to add resize functionality to your nodes.

== Definitions ==
=== Nodes ===
A node in React Flow is a React component. That means it can render anything you like. Each node has an x- and y-coordinate, which tells it where it is placed in the viewport. You can find all the options for customizing your nodes in the Node options<ref>https://reactflow.dev/api-reference/types/node</ref> documentation.

==== Custom Nodes ====
This is where the magic of React Flow happens. You can customize nodes to look and act however you would like. Much of the functionality that you might create is not built-in to React Flow. Some of the things you might do with a custom node are:
* Render form elements
* Visualize data
* Support multiple handles.

=== Handles ===
A handle(also called "port" in other libraries) is the place where an edge attaches to a node. The handle can be placed anywhere, and styled as you like. It's just a div element. By default, it appears as a grey circle on the top, bottom, left, or fight of the nodes you can has as many handles as you need in your node. More information can be found in the handle docs<ref>https://reactflow.dev/api-reference/components/handle</ref>.

=== Edges ===
An edge connects two nodes. Every edge needs a target and a source node. React Flow comes with four built-in edge typee:default(bezier), smoothstep, step and straight. An edge is SVG path that can be styled with OSS and is completely customizable. If you are using multiple handles, you can reference them individually to create multiple connections for a node.

==== Custom Edges ====
Like custom nodes, you can also customize edges. Things that people do with custom edges are:
* Add a button to remove an edge.
* Custom routing behaviour.
* Complex styling or interactions that cannot be solved with just one SVG path.

You can find more information on the custom edges api<ref>https://reactflow.dev/api-reference/types/edge-props</ref> site.

=== Connection Line ===
React Flow has built-in functionality to click-and-drag from one handle to another in order to create a new edge. While dragging, the placeholder edge is called a connection line. The connection line also comes with four types built-in and is customizable. You can find the props for configuring the connection in the props section<ref>https://reactflow.dev/api-reference/react-flow#connection-line</ref>.

=== Viewport ===
All of React Flow exists inside of the viewport. The viewport has a x, y and zoom value. When you drag the pane, you change the x and y coordinates and when you zoom in or out you alter the zoom level.

== Core Concepts ==
A flow consists of nodes and edges(or just edges). You can pass arrays of nodes and edges as props to the ReactFlow component. Hereby all node and edge ids need to be unique. A node needs a position and a label(this could be different if you using custom nodes) and an edge needs a source(node id) and a target(node id). You can read more about the options in the Node options<ref>https://reactflow.dev/api-reference/types/node</ref> and Edge options<ref>https://reactflow.dev/api-reference/types/edge</ref> sections.

=== Controlled or Uncontrolled ===
With React Flow you have two ways to setup a flow. You can either create a controlled or an uncontrolled one. We recommend to use a controlled one but for simpler use cases you can also setup an uncontrolled flow.

=== Basic Functionality ===
By default, React Flow doesn't do any internal state updates besides handling the viewport when you setup a controlled flow. As with an <input /> component you need to pass handlers to apply the changes that are triggered by React Flow to your nodes and edges. In order to select, drag and remove nodes and edges you need to implement an onNodesChange and an onEdgesChange handler.

Whenever React Flow triggers a change(node init, node drag, edge select, etc.), the onNodeChange handler gets called. The React Flow export an applyNodeChanges handler so that you don't need to handle the changes by yourself. The applyNodeChanges handler returns an updated array of nodes that is your new nodes array. It allows following kind of interactions.
* selectable nodes and edges.
* draggable nodes.
* removable nodes and edges - (press Backspace to remove a selected node or edge, can be adjusted with the deleteKeyCode prop).
* multi-selection area by pressing Shift(that's the default selectionKeyCode).
* multi-selection by pressing command(that's the default multiSelectionKeyCode).

For convenience we export the helper hooks useNodeState and useEdgeState that you can use to create the nodes and edges state:
```
const [nodes, setNodes, onNodesChange] = useNodesState(initialNodes);
const [edges, setEdges, onEdgesChange] = useEdgesState(initialEdges);
```

=== Connecting Nodes ===
<pre>
const onConnect = useCallback(
(connection) =>
setEdges((eds) => addEdge({ ...connection, animated: true }, eds)),
[setEdges],
);
</pre>

or use the defaultEdgeOptions prop:
```
const defaultEdgeOptions = { animated: true };
...
<ReactFlow
nodes={nodes}
edges={edges}
onNodesChange={onNodesChange}
onEdgesChange={onEdgesChange}
onConnect={onConnect}
defaultEdgeOptions={defaultEdgeOptions}
/>;
```

[[category:react]]

React flow - Concept

2024-03-01T14:16:03Z

Pchero:

== Overview ==
React flow 내용 정리.
원문은 이곳<ref>https://reactflow.dev/learn</ref>에서 확인할 수 있다.

== Introduction ==
=== Key features ===
Buillt-in plugins
* The <Background /> plugin implements some basic customisable background patterns.
* The <MiniMap /> plugin displays a small version of the graph in the corner of the screen.
* The <Controls /> plugin adds controls to zoom, center, and lock the viewport.
* The <Panel /> plugin makes it easy to position content on top of the viewport.
* The <NodeToolbar /> plugin lets you render a toolbar attached to a node.
* The <NodeResizer /> plugin makes it easy to add resize functionality to your nodes.

== Definitions ==
=== Nodes ===
A node in React Flow is a React component. That means it can render anything you like. Each node has an x- and y-coordinate, which tells it where it is placed in the viewport. You can find all the options for customizing your nodes in the Node options<ref>https://reactflow.dev/api-reference/types/node</ref> documentation.

==== Custom Nodes ====
This is where the magic of React Flow happens. You can customize nodes to look and act however you would like. Much of the functionality that you might create is not built-in to React Flow. Some of the things you might do with a custom node are:
* Render form elements
* Visualize data
* Support multiple handles.

=== Handles ===
A handle(also called "port" in other libraries) is the place where an edge attaches to a node. The handle can be placed anywhere, and styled as you like. It's just a div element. By default, it appears as a grey circle on the top, bottom, left, or fight of the nodes you can has as many handles as you need in your node. More information can be found in the handle docs<ref>https://reactflow.dev/api-reference/components/handle</ref>.

=== Edges ===
An edge connects two nodes. Every edge needs a target and a source node. React Flow comes with four built-in edge typee:default(bezier), smoothstep, step and straight. An edge is SVG path that can be styled with OSS and is completely customizable. If you are using multiple handles, you can reference them individually to create multiple connections for a node.

==== Custom Edges ====
Like custom nodes, you can also customize edges. Things that people do with custom edges are:
* Add a button to remove an edge.
* Custom routing behaviour.
* Complex styling or interactions that cannot be solved with just one SVG path.

You can find more information on the custom edges api<ref>https://reactflow.dev/api-reference/types/edge-props</ref> site.

=== Connection Line ===
React Flow has built-in functionality to click-and-drag from one handle to another in order to create a new edge. While dragging, the placeholder edge is called a connection line. The connection line also comes with four types built-in and is customizable. You can find the props for configuring the connection in the props section<ref>https://reactflow.dev/api-reference/react-flow#connection-line</ref>.

=== Viewport ===
All of React Flow exists inside of the viewport. The viewport has a x, y and zoom value. When you drag the pane, you change the x and y coordinates and when you zoom in or out you alter the zoom level.

== Core Concepts ==
A flow consists of nodes and edges(or just edges). You can pass arrays of nodes and edges as props to the ReactFlow component. Hereby all node and edge ids need to be unique. A node needs a position and a label(this could be different if you using custom nodes) and an edge needs a source(node id) and a target(node id). You can read more about the options in the Node options<ref>https://reactflow.dev/api-reference/types/node</ref> and Edge options<ref>https://reactflow.dev/api-reference/types/edge</ref> sections.

=== Controlled or Uncontrolled ===
With React Flow you have two ways to setup a flow. You can either create a controlled or an uncontrolled one. We recommend to use a controlled one but for simpler use cases you can also setup an uncontrolled flow.

=== Basic Functionality ===
By default, React Flow doesn't do any internal state updates besides handling the viewport when you setup a controlled flow. As with an <input /> component you need to pass handlers to apply the changes that are triggered by React Flow to your nodes and edges. In order to select, drag and remove nodes and edges you need to implement an onNodesChange and an onEdgesChange handler.

Whenever React Flow triggers a change(node init, node drag, edge select, etc.), the onNodeChange handler gets called. The React Flow export an applyNodeChanges handler so that you don't need to handle the changes by yourself. The applyNodeChanges handler returns an updated array of nodes that is your new nodes array. It allows following kind of interactions.
* selectable nodes and edges.
* draggable nodes.
* removable nodes and edges - (press Backspace to remove a selected node or edge, can be adjusted with the deleteKeyCode prop).
* multi-selection area by pressing Shift(that's the default selectionKeyCode).
* multi-selection by pressing command(that's the default multiSelectionKeyCode).

For convenience we export the helper hooks useNodeState and useEdgeState that you can use to create the nodes and edges state:
```
const [nodes, setNodes, onNodesChange] = useNodesState(initialNodes);
const [edges, setEdges, onEdgesChange] = useEdgesState(initialEdges);
```

=== Connecting Nodes ===
```
const onConnect = useCallback(
(connection) =>
setEdges((eds) => addEdge({ ...connection, animated: true }, eds)),
[setEdges],
);
```

or use the defaultEdgeOptions prop:
```
const defaultEdgeOptions = { animated: true };
...
<ReactFlow
nodes={nodes}
edges={edges}
onNodesChange={onNodesChange}
onEdgesChange={onEdgesChange}
onConnect={onConnect}
defaultEdgeOptions={defaultEdgeOptions}
/>;
```

[[category:react]]

React flow - Concept

2024-03-01T14:15:06Z

Pchero:

== Overview ==
React flow 내용 정리.
원문은 이곳<ref>https://reactflow.dev/learn</ref>에서 확인할 수 있다.

== Introduction ==
=== Key features ===
Buillt-in plugins
* The <Background /> plugin implements some basic customisable background patterns.
* The <MiniMap /> plugin displays a small version of the graph in the corner of the screen.
* The <Controls /> plugin adds controls to zoom, center, and lock the viewport.
* The <Panel /> plugin makes it easy to position content on top of the viewport.
* The <NodeToolbar /> plugin lets you render a toolbar attached to a node.
* The <NodeResizer /> plugin makes it easy to add resize functionality to your nodes.

== Definitions ==
=== Nodes ===
A node in React Flow is a React component. That means it can render anything you like. Each node has an x- and y-coordinate, which tells it where it is placed in the viewport. You can find all the options for customizing your nodes in the Node options<ref>https://reactflow.dev/api-reference/types/node</ref> documentation.

==== Custom Nodes ====
This is where the magic of React Flow happens. You can customize nodes to look and act however you would like. Much of the functionality that you might create is not built-in to React Flow. Some of the things you might do with a custom node are:
* Render form elements
* Visualize data
* Support multiple handles.

=== Handles ===
A handle(also called "port" in other libraries) is the place where an edge attaches to a node. The handle can be placed anywhere, and styled as you like. It's just a div element. By default, it appears as a grey circle on the top, bottom, left, or fight of the nodes you can has as many handles as you need in your node. More information can be found in the handle docs<ref>https://reactflow.dev/api-reference/components/handle</ref>.

=== Edges ===
An edge connects two nodes. Every edge needs a target and a source node. React Flow comes with four built-in edge typee:default(bezier), smoothstep, step and straight. An edge is SVG path that can be styled with OSS and is completely customizable. If you are using multiple handles, you can reference them individually to create multiple connections for a node.

==== Custom Edges ====
Like custom nodes, you can also customize edges. Things that people do with custom edges are:
* Add a button to remove an edge.
* Custom routing behaviour.
* Complex styling or interactions that cannot be solved with just one SVG path.

You can find more information on the custom edges api<ref>https://reactflow.dev/api-reference/types/edge-props</ref> site.

=== Connection Line ===
React Flow has built-in functionality to click-and-drag from one handle to another in order to create a new edge. While dragging, the placeholder edge is called a connection line. The connection line also comes with four types built-in and is customizable. You can find the props for configuring the connection in the props section<ref>https://reactflow.dev/api-reference/react-flow#connection-line</ref>.

=== Viewport ===
All of React Flow exists inside of the viewport. The viewport has a x, y and zoom value. When you drag the pane, you change the x and y coordinates and when you zoom in or out you alter the zoom level.

== Core Concepts ==
A flow consists of nodes and edges(or just edges). You can pass arrays of nodes and edges as props to the ReactFlow component. Hereby all node and edge ids need to be unique. A node needs a position and a label(this could be different if you using custom nodes) and an edge needs a source(node id) and a target(node id). You can read more about the options in the Node options<ref>https://reactflow.dev/api-reference/types/node</ref> and Edge options<ref>https://reactflow.dev/api-reference/types/edge</ref> sections.

=== Controlled or Uncontrolled ===
With React Flow you have two ways to setup a flow. You can either create a controlled or an uncontrolled one. We recommend to use a controlled one but for simpler use cases you can also setup an uncontrolled flow.

=== Basic Functionality ===
By default, React Flow doesn't do any internal state updates besides handling the viewport when you setup a controlled flow. As with an <input /> component you need to pass handlers to apply the changes that are triggered by React Flow to your nodes and edges. In order to select, drag and remove nodes and edges you need to implement an onNodesChange and an onEdgesChange handler.

Whenever React Flow triggers a change(node init, node drag, edge select, etc.), the onNodeChange handler gets called. The React Flow export an applyNodeChanges handler so that you don't need to handle the changes by yourself. The applyNodeChanges handler returns an updated array of nodes that is your new nodes array. It allows following kind of interactions.
* selectable nodes and edges.
* draggable nodes.
* removable nodes and edges - (press Backspace to remove a selected node or edge, can be adjusted with the deleteKeyCode prop).
* multi-selection area by pressing Shift(that's the default selectionKeyCode).
* multi-selection by pressing command(that's the default multiSelectionKeyCode).

For convenience we export the helper hooks useNodeState and useEdgeState that you can use to create the nodes and edges state:
```
const [nodes, setNodes, onNodesChange] = useNodesState(initialNodes);
const [edges, setEdges, onEdgesChange] = useEdgesState(initialEdges);
```

=== Connecting Nodes ===
<code lang=javascript>
const onConnect = useCallback(
(connection) =>
setEdges((eds) => addEdge({ ...connection, animated: true }, eds)),
[setEdges],
);
</code>

or use the defaultEdgeOptions prop:
<code lang=javascript>
const defaultEdgeOptions = { animated: true };
...
<ReactFlow
nodes={nodes}
edges={edges}
onNodesChange={onNodesChange}
onEdgesChange={onEdgesChange}
onConnect={onConnect}
defaultEdgeOptions={defaultEdgeOptions}
/>;
</code>

[[category:react]]

React flow - Concept

2024-03-01T13:09:35Z

Pchero:

React flow - Concept

2024-03-01T12:43:03Z

Pchero:

React flow - Concept

2024-03-01T12:14:21Z

Pchero:

React flow - Concept

2024-03-01T12:03:10Z

Pchero: Created page with "== Overview == React flow 내용 정리. 원문은 이곳<ref>https://reactflow.dev/learn</ref>에서 확인할 수 있다. == Introduction == === Key features === Buillt-in plugins * The <Background /> plugin implements some basic customisable background patterns. * The <MiniMap /> plugin displays a small version of the graph in the corner of the screen. * The <Controls /> plugin adds controls to zoom, center, and lock the viewport. * The <Panel /> plugin makes it easy..."

Asterisk pjsip sip message

2023-10-04T12:53:20Z

Pchero: /* INVITE */

== Overview ==
Asterisk pjsip module's sip message 관련 내용 정리

== INVITE ==
Asterisk 에서의 모든 Inbound 채널 및 관련 세션 생성은 INVITE 메시지로부터 시작한다.

=== Caller info ===
PJSIP 모듈은 inbound 콜 수행시, INVITE 메시지로부터 채널을 생성하면서, Caller 의 정보를 설정(Parsing)한다.

Caller 정보를 설정할 때 사용하는 SIP header 는 여러가지가 있는데, 다음의 우선 순위로 파싱을 한다.
<pre>
1. P-Asserted-Identity
2. Remote-Party-ID
3. FROM
</pre>
즉, 제일 먼저 P-Asserted-Identity 를 확인하고, 설정되어 있지 않다면, Remote-Party-ID 를 확인한다. 그리고 Remote-Party-ID 가 설정되어 있지 않다면 마지막으로 FROM 헤더를 확인하다.

파싱되는 내용은 다음 과 같다.
Display name 을 파싱해서 Caller name 으로 사용하고, Username 을 파싱해서 Caller number 로 사용한다.

예를 들어 P-Asserted identity 헤더가 다음과 같이 설정 되었다고 하자.
<pre>
P-Asserted-Identity="test <1234@test.com>"
</pre>

그렇다면 다음과 같이 파싱이 된다.
<pre>
Caller name: test
Caller number: 1234
</pre>

자세한 함수는
<pre>
res/res_pjsip_caller_id.c
static int caller_id_incoming_request(struct ast_sip_session *session, pjsip_rx_data *rdata)
</pre>
에서 수행한다.
[[Category:Asterisk]]

Sipexer

2023-09-27T16:51:33Z

Pchero:

== Overview ==
sipexer - Modern and flexible SIP (RFC3261) command line tool 내용 정리.

== OPTIONS ping ==
<pre>
# /usr/local/bin/sipexer -nagios -fu heartbeat 10.75.0.42:5060

[info] [sipexer.go:1578] main.SIPExerDialogLoop(): local socket address: 10.75.0.42:36617 (udp)
[info] [sipexer.go:1579] main.SIPExerDialogLoop(): local via address: 10.75.0.42:36617
[info] [sipexer.go:1580] main.SIPExerDialogLoop(): sending to udp 10.75.0.42:5060: [[---
OPTIONS sip:10.75.0.42:5060 SIP/2.0
Via: SIP/2.0/UDP 10.75.0.42:36617;rport;branch=z9hG4bKSG.3b6e77cc-dbf8-4f58-9809-7bca9c3f9272
From: <sip:heartbeat@localhost>;tag=2d5b7fec-6f21-45e6-a20c-b2ae39535657
To: <sip:bob@localhost>
Call-ID: 9a11ff73-de7a-4a19-a0e4-38fa8757ea66
CSeq: 514429 OPTIONS
Date: Wed, 30 Aug 2023 00:40:44 UTC
User-Agent: SIPExer v1.1.0
Max-Forwards: 10
Content-Length: 0

[info] [sipexer.go:1582] main.SIPExerDialogLoop(): ---]]

[info] [sipexer.go:1633] main.SIPExerDialogLoop(): response-received: from=10.75.0.42:5060 bytes=438 data=[[---
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.75.0.42:36617;rport=36617;branch=z9hG4bKSG.3b6e77cc-dbf8-4f58-9809-7bca9c3f9272;received=10.75.0.42
From: <sip:heartbeat@localhost>;tag=2d5b7fec-6f21-45e6-a20c-b2ae39535657
To: <sip:bob@localhost>;tag=8cc31d58288b2b802886d8395a3eac46.7aa55e46
Call-ID: 9a11ff73-de7a-4a19-a0e4-38fa8757ea66
CSeq: 514429 OPTIONS
Accept: */*
Accept-Encoding:
Accept-Language: en
Supported:
Content-Length: 0

[info] [sipexer.go:1635] main.SIPExerDialogLoop(): ---]]
</pre>

== Registration ==
<pre>
$ sipexer -register -vl 3 -co -com -ex 60 -fuser alice -cb -ap "abab..." -ha1 -sd udp:sipserver.com:5060
</pre>

== See also ==
* https://github.com/miconda/sipexer

[[category:command/utility]]

Kamailio module websocket

2023-09-21T05:51:48Z

Pchero: /* Overview */

== Overview ==
Kamailio's WebSocket 모듈 내용 정리.

The WebSocket module in Kamailio implemented a WebSocket(RFC 6455) server and provides connection establishment(handshaking), management(including connection keep-alive), and framing for the SIP and MSRP WebSocket sub-protocols (RFC 7118 and RFC 7977).

== Parameters ==
=== keepalive_mechanism(integer) ===
The keep-alive mechanism to use for WebSocket connection.

:<b>Note</b>
:If nathelper is only being used for WebSocket connections then nathelper NAT pinging is not required. If nathelper is used for WebSocket connections and TCP/TLS aliasing/NAT-traversal then WebSocket keep-alives are not required.
* 0: no WebSocket keep-alives.
* 1: Ping WebSocket keep-alives.
* 2: Pong WebSocket keep-alives.

Default value is 1.
<pre>
modparam("websocket", "keepalive_mechanism", 0)
</pre>

=== keepalive_timeout(integer) ===
The time(in seconds) after which to send a keep-alive on idle WebSocket connections.
Default value is 180.
<pre>
modparam("websocket", "keepalive_timeout", 50)
</pre>

=== keepalive_processes(integer) ===
The number of processes to start to perform WebSocket connection keep-alives.

Default value is 1.
<pre>
modparam("websocket", "keepalive_processes", 2)
</pre>

=== verbose_list(integer) ===
Allows to enable/disable the printing of debug messages when getting the list of websocket connections. If enabled, it prints debug messages every second for ping operations.

Default value is 0(disabled).
<pre>
modparam("websocket", "verbose_list", 1)
</pre>

== See also ==
* https://www.kamailio.org/docs/modules/devel/modules/websocket.html

[[category:kamailio]]

Kamailio module websocket

2023-09-21T05:38:22Z

Pchero: Created page with "== Overview == Kamailio's WebSocket 모듈 내용 정리. The WebSocket module in Kamailio implemented a WebSocket(RFC 6455) server and provides connection establishment(handshaking), management(including connection keep-alive), and framing for the SIP and MSRP WebSocket sub-protocols (RFC 7118 and RFC 7977). == See also == * https://www.kamailio.org/docs/modules/devel/modules/websocket.html category:kamailio"

SIP SDP

2023-09-19T03:32:30Z

Pchero: /* Delayed(Late) Media in SDP (RFC 3959, RFC 3960) */

== Overview ==
참조 원문은 이곳<ref>http://www.nexpert.net/497</ref><ref>http://www.nexpert.net/142</ref>에서 확인할 수 있다.

SDP는 코덱 협상과 같은 Capability Exchange 를 수행하는 프로토콜로 SIP 뿐만 아니라 MGCP와 Megaco에서도 사용한다. 기술적으로는 SIP와 SDP 프로토콜을 구분해서 사용하지만, SIP를 살펴볼 때 SDP는 자연스럽게 언급된다.

== SDP 의 개요 ==
SDP는 Session Description Protocol 의 약어로 멀티미디어 세션 파라미터를 협상하는 프로토콜이다. SDP는 RFC 2327을 개정한 RFC 4566 으로 권고되었다. H.323에 대한 이해가 있다면 SDP가 H.323 프로토콜의 H.245와 비슷한 역할을 수행한다고 생각하면 된다.

SIP를 요청과 응답 모델(Request & Response Model)로 정의하였듯이 SDP는 제안과 수락 모델(Offer & Answer Model)로 정의한다. SDP의 Offer/Answer Model 로의 동작에 대해서는 RFC 33264 An Offer/Answer Model with the SDP 에서 자세히 설명되어 있다.

[[File:Sdp dialog.png]]

SDP는 Capability를 협상하기 위해 기존의 호 처리 프로토콜을 이용한다. 위의 그림에서처럼 SDP는 SIP 메시지와 함께 전달된다. SIP INVITE 메시지에 SDP Offer가 포함되거나 200 OK 응답 메시지에 SDP Answer 가 포함된다.

== SDP 메시지 분석 ==
SDP는 멀티미디어를 전달하는 RTP 프로토콜에 대한 세부적인 내용을 협상한다. SDP는 아래와 같이 SIP와 다른 메시지 포멧을 유지하지만, SIP와 같이 텍스트 기반으로 구성된다.

=== Session Description ===
<pre>
v= protocal version.
o= owner/creator and session identification.
s= session name.
i= (optional) session information.
u= (optional) URI of description.
e= (optional) email address - contact detail.
p= (optional) phone number - contact detail.
c= (optional) connection information - not required if included in media description.
b= (optional) session bandwidth information.
z= (optional) time zone adjustments.
k= (optional) encryption key.
a= (optional) zero or more session attribute lines.
</pre>
* v=<version>
: Specifies the version of Session Description Protocol. As specified in RFC 4566, up to now there is only one version, which is Version 0. No minor versions exist.

* o=<username><sess-id><sess-version><nettype><addrtype><unicast-address>
: Details about the originator and identification of the session.
: <username>: The user's login. The MUST NOT contain spaces.
: <sess-id>: A numeric string used as unique identifier for the session.
: <sess-version>: A numeric string used as version number for this session description.

=== Time description ===
<pre>
t= time the session is active.
r= (optional) repeat times.
</pre>

* Media description
<pre>
m= media name/transport address.
i= (optional) media title
c= (optional) connection information - not required if included in session description.
b= (optional) bandwidth information.
k= (optional) encryption key.
a= (optional) zero or more media attribute lines.
</pre>

=== Example ===

<pre>
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.com
s=
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
</pre>

각 라인의 의미는 다음과 같다.

* v=0 (필수)
: SDP 프로토콜의 버전을 표시한다. SDP 버전은 0이다.

* o=alice 2890844526 2890844526 IN IP4 atlanta.com (필수)
: SDP 메시지를 생성한 Owner/Creator 를 표시한다. 순서대로 Username, Session-ID, Session Version, Network Type, Address Type, Unicast Address 를 표시한다.

* s= (필수)
: 세션 이름을 표시한다.

* i=(optional)
: Session information.

* u=(optional)
: URI of description.

* e=(optional)
: Email address - contact detail.

* p=(optional)
: Phone number - contact detail.

* c=IN IP4 10.1.3.33 (optional)
: 순서대로 Network Type, Address Type, Connection-Address 를 나타내며 미디어의 주소를 정의한다.

* t=0 0 (필수)
: Timing 으로 Start-time과 End-Time을 표시한다. 0 0 은 고정 세션을 의미한다.

SDP의 Capability Exchange 를 주도하는 라인은 m= 와 a= 로 RTP가 사용할 코덱, IP 주소, 포트넘버가 자세히 명기된다. SDP를 생성하는 UA는 자신이 지원가능한 모든 코덱과 능력을 아래와 같이 명기한다.

<pre>
m=audio 16444 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=ptime:20
a=rtpmap:18 G729/8000
a=ptime:20
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
</pre>

* m= (미디어 설명)
: Media Description으로 Media, Port, Protocol, Format 을 정의한다.
: Media : audio, video, text, application, message 로 표시.
: Port : 미디어가 전송될 전송포트(Transport port) 표시.
: Protocol : UDP, RTP/AVP, RTP/SAVP로 표시하며 AVP는 Audio Video Profile의 약자이다.
: Format : 미디어의 포멧을 서브필드 (a=)로 표시함을 의미.
: Payload Type 0 8 18 의 순서는 코덱 협상의 우선순위를 나타내며, Payload Type 101은 DTMF 이벤트를 정의한다. 각 포멧에 대한 상세 설명은 a= 에 표시된다.

* a= (미디어 속성)
: 미디어 속성(attributer)을 정의한다.
: a=rtpmap : Payload type, encoding name/clock rate 를 표시
: a=ptime : Packet time으로 미디어 패킷 한 개가 포함된 시간 정보로 ms로 표시 (보통 20ms).
: a=fmtp : 미디어 포멧에 대한 파라미터를 정의

* a= (미디어의 방향)
: 미디어 속성 뿐만 아니라 미디어 방향도 표시한다. 미디어의 방향은 아래와 같이 4가지로 나타낸다.
: a=sendrecv : 단말은 미디어를 송신 및 수신할 수 있음.
: a=recvonly : 단말은 수신만을 할 수 있으며 송신하지 않음.
: a=sendonly : 단말은 송신만을 할 수 있으며 수신하지 않음.
: a=inactive : 단말은 송신 및 수신을 할 수 없음 (Hold 버튼을 누를 경우)
: 별도의 언급이 없을 경우에는 a=sendrecv 로 설정되었다고 가정한다. 미디어의 방향은 다양한 부가 서비스 구현시 유용하다.

* a= (DTMF 협상)
: DTMF 전달에 관한 협상도 진행한다.
: a=rtpmap:101 telephone-event.8000 : RFC 2833에 의한 In-band DTMF를 의미.
: a=fmtp 101 0-15 : DTMF Tone 은 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, *, #, A, B, C, D 총 15 가지를 송수신 함.

== RFC 3264의 기본 SDP 협상 (Offer / Answer Model) ==
RFC 3264 An Offer/Answer Model Session Description Protocol 권고안에 나와 있는 10.1 Basic Exchange 부분을 살펴보면서 Offer/Answer 모델의 동작 방식을 살펴보자.

=== 앨리스의 "Offer" ===
앨리스는 한개의 음성 스트림과 두 개의 영상 스트림을 제안한다.
<pre>
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
</pre>

SDP를 Owner이자 Creator인 앨리스는, 음성 스트림은 G.711 ulaw 코덱과 49170 UDP 포트를 사용하며, 영상스트림은 H.261 코덱과 51372 UDP 포트를, 또 하나의 영상 스트림은 MPEG 코덱과 53000 UDP 포트를 사용한다고 제한한다.

=== 밥의 "Answer" ===
<pre>
v=0
o=bob 2890844730 2890844730 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 49920 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
</pre>

밥은 음성 스트림에 대해 G.711 ulaw 코덱과 49920 UDP 포트를 사용하고, 첫번째 영상에 대한 미디어 속성(a=) 정의를 포함하지 않고, 두 번째 영상 스트림에 대해서만 미디어 속성을 포함하고 있다. 일반적으로 미디어 속성(a=)를 포함하지 않으면 미디어 스트림이 개방되지 않는다.

=== 밥의 협상 변경 요청 "Offer" ===
밥은 Answer 후에 협상 내용을 변경을 요청한다.

<pre>
v=0
o=bob 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 65422 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
m=audio 51434 RTP/AVP 110
a=rtpmap:110 telephone-events/8000
a=recvonly
</pre>

밥은 음성 스트림에 대한 UDP 포트 넘버를 49920에서 65422로 변경하는 것과 DTMF 수신을 위한 (receive-only) 방법을 추가하였다. 일반적으로 DTMF 이벤트 처리를 위한 RTP Payload 는 Type 110 이다.

=== 앨리스의 "Answer" ===
앨리스는 밥의 제안을 승인하고, 다음과 같이 응답한다.

<pre>
v=0
o=alice 2890844526 2890844527 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
m=audio 53122 RTP/AVP 110
a=rtpmap:110 telephone-events/8000
a=sendonly
</pre>
밥의 요청을 모두 수락한다.

== RFC 3264의 One of N Codec Selection ==
IP Phone과 Gateway는 음성이나 영상 압축을 위해 DSP (Digital Signal Processor)라는 칩을 사용한다. DSP는 다수의 코덱을 지원하지만, 한 번에 하나의 코덱만을 지원한다. SDP Offer에 다수의 코덱을 전송하더라도 Answer 에서는 하나의 코덱만을 선택할 수 있다. 다수 코덱을 제안할 경우에 선택하는 방식에 대해서 알아보자.

=== 앨리스의 "Offer" ===
Offer이자 Creator인 엘리스는 음성 스트림 하나만을 제안하면서 자신의 DSP가 지원하는 G.711 ulaw, G.723, G.729 코덱을 나역한다. G.711 ulaw 가 가장 우선 순위가 높으며, 코덱 협상 완료 전까지는 미디어를 맏아 들일 수 없으므로 미디어의 방향을 "a=inactive"로 한다.

<pre>
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 62986 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=inactive
</pre>

=== 밥의 "Answer" ===
밥은 자신의 DSP가 G.711 ulaw와 G.723 코덱만을 지원하며, G.711 ulaw를 우선적으로 선택한다.

<pre>
v=0
o=bob 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 54344 RTP/AVP 0 4
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=inactive
</pre>

=== 앨리스의 "Offer" ===
앨리스는 밥이 제안한 두 개의 코덱 모두를 지원할 수 있지만 G.723 코덱을 선택하면서 "a=sendrecv"로 양방향 통화 채널을 활성화 한다. 일반적으로 우선순위가 높은 G.711 ulaw를 선택하지만, 예제에서는 G.723을 선택하는 것을 가정한다.

<pre>
v=0
o=alice 2890844526 2890844527 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 62986 RTP/AVP 4
a=rtpmap:4 G723/8000
a=sendrecv
</pre>

=== 밥의 "Answer" ===
밥은 앨리스가 제안한 G.711 코덱을 받아 들이고 "a=sendrecv"로 양방향 통화 채널을 활성화 한다.

<pre>
v=0
o=bob 2890844730 2890844732 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 54344 RTP/AVP 4
a=rtpmap:4 G723/8000
a=sendrecv
</pre>

=== inactive to sendrecv ===
처음 inactive 상태를 sendrecv로 전환하기 위해 4번에 걸친 Offer와 Answer를 교환한다. 일반적으로는 처음부터 a=sendrecv로 교환하고, 처음 제시되는 코덱이 우선순위가 높으므로 선택된다. 위의 과정은 Offer/Answer Model을 기반으로 설명하는 것이지만, 실제로는 INVITE with SDP로 제안이 되며, 200 OK with SDP 또는 180 Ringing with SDP로 2 단계로 마무리된다.

== Early Media in SDP (RFC 3959, RFC 3960) ==
Early Media 란, 실제 통화가 이루어 지기 전 전송되는 Media 를 의미한다. 대표적인 예로 컬러링이 있다.

=== Early Media 의 개요 ===
아래 그림은 일반적인 SIP 호 설정 시나리오이다. 앨리스는 수화기를 들어 전화번호를 누르면 INVITE 메시지와 함께 Offer가 이루어진다. 밥의 전화기는 Ringing (따르릉)하게되며, 180 Ringing 메시지가 앨리스에게 전달된다. 180 Ringing을 받은 앨리스는 Local Ringback을 들으면서 밥의 전화기가 울리고 있다고 인지한다. 밥은 Ringing 소리를 듣고 전화가 왔음을 인지하게 되어 전화기로 다가가 수화기를 드는 순간 200 OK 메시지와 Answer가 앨리스에게 전달된다. 200 OK를 받은 앨리스는 ACK를 밥에게 전송하며 통화가 시작된다.

[[File:Sip early media.png]]

그런데 일반적인 SIP 통화 시나리오 상에서 다음 두 가지 문제가 발생하게 된다.

* Remote Ringback
: 180 Ringing 메시지를 전달받은 앨리스의 전화기는 자체적으로 Ringback tone을 발생시킨다. 그러나, 현실에서는 컬러링이나 Remote Ringback tone을 들을 수 있어야 한다.

* Media Clipping
: 보통 사람들은 수화기를 들면서 "여보세요"라고 말한다. 위의 시나리오는 200 OK를 보내고 ACK를 받을 때까지의 이야기는 전달할 수 없게 된다. 따라서 Media Clipping이 발생할 수 밖에 없어 밥의 "여보세요"가 앨리스에게는 "세요"라고 들릴 것이다.

이러한 문제점은 SDP의 일반적인 Offer/Answer 절차 이전에 Media가 전송되어져야 한다는 것을 의미한다. 즉, Early Media는 정규 Offer/Answer 절차 이전에 전송되는 RTP를 가리킨다. 그렇다면, Early Media의 발생시점은 INVITE의 생성에서부터 ACK 신호까지이다. ACK 이후에는 정상적인 Media가 전송된다.

=== SDP 협상의 방식 ===
기본적으로 Early Media가 동작하기 위해서는 위의 그림과 같이 INVITE with SDP로 Initial Offer 가 발생되어야 한다. 위에서 언급한 Media Clipping의 경우, Invite with SDP (offer)로 보내지는 대부분의 경우 이러한 Media Clipping은 발생되지 않는다. UAC(송신자)는 200 OK의 수신 여부와는 상관없이 Offer를 하자마자 자기 스스로 들어오는 Media에 대해 재생할 준비를 하도록 되어 있다. 그러나, 이렇게 Invite with SDP 만 있는 것이 아니다.

아래와 같이 200 OK에 밥이 먼저 Offer를 할 수도 있으며, Update 메소드를 이용하여 SDP를 교환할 수도 있다.

[[File:Sdp late offer.png]]

=== Early Media 의 두 가지 모델 ===
RFC 3960에 의하면, Early Media는 다음과 같이 두 가지 모델로 구분할 수 있다.

* Gateway Model
: 이 모델은 SIP 시그널링 상에서 Early Media에 대한 특별한 언급없이 동작한다. 180 Ringing 메시지를 받으면, Local Ringback Tone을 발생시키고, 상대방으로부터 RTP(Early Media)가 전송되면, Local Ringback Tone 발생을 중단하고, RTP를 재생한다. 이 Gateway 모델의 문제점은 Forking 및 Security 문제가 있다.

* Application Server Model
: SIP 시그널시 Early Media에 대한 Offer/Answer를 가능하게 한다. RFC 3959에 정의된 Content-Disposition 헤더에 Session 또는 Early-session의 새로운 Disposition Type을 설정하여 Early-Media가 가능하게 한다.

=== Ringback Tone 재생 정책 ===
PSTN 상에서 수신자가 Alert 메시지를 보내면 Ringback Tone은 PBX에 의해 재생된다. SIP의 경우 UAS(수신자)에 의해 Ringback 이 재생되지 않으면, UAC에서 자체적으로 Ringback tone을 재생하기로 되어 있다. 만일, Announcement 또는 Special Ringing Tone이 UAS에 재생이 되면, UAC는 자체적인 재생을 중단하고 UAS로 부터 오는 Media를 재생하는 것이 일반적이다. 그러나, UAS가 Early Media 를 전송하려는 의도 없이 Early Offer를 진행하기도 하고, Reliable Provisional Response 없이 Ealry Media를 전송하기도 하기 때문에 UAC는 쉽게 Local Ringback Tone을 재생해야할 지 말아야할 지를 결정할 수 없다.

Local Ringback Tone 재생에 관련해서 다음과 같은 정책을 구현해야 한다.
<pre>
- 180 Ringing 을 받지 않았다면, Local Ringing 을 재생하지 않는다.
- 180 Ringing 을 받았으나 수신되는 Media 패킷이 없다면, Local Ringing을 재생한다.
- 180 Ringing 을 받았으면서 Media 패킷이 수신된다면, Media를 재생하고 Local Ringing을 재생하지 않는다.
</pre>
180 Ringing은 수신측이 전화기가 울리고 있음을 의미한다.

=== Application Server Model 상에서의 Early media ===
Early Media Session 은 지금까지 이야기한 Regual Session에서 함께 처리된다. 그러나, Application Server Model은 Early Media를 위한 별도의 절차를 수행한다. 따라서, 하나의 호 시그널링에서 Early Media Session과 Regular Session 을 동시에 Offer/Answer를 수행한 후 전환한다. 이 때, Content-Disposition Header 에 Session 과 Early-session 이라고 하여 각각의 쓰임새를 구분한다.

Early session 이 Regular session 으로 전환될 때, 코덱을 변경할 필요가 없도록 하기 위하여 Early Media session 과 Media session은 같은 코덱을 사용하는 것을 권장한다. RFC 3959의 예제를 보자.

[[File:Sdp rfc 3959.png]]

앨리스는 밥에게 Contect-Disposition: session 헤더를 INVITE에 추가해서 전송한다. 이 헤더의 의미는 INVITE에 포함된 Offer는 Regular session 에 대한 것임을 표시한다.
<pre>
Content-Type: application/sdp
Content-Disposition: session

v=0
o=alice 2890844730 2890844731 IN IP4 host.sip.com
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 20000 RTP/AVP 0
</pre>

이후 밥은 183 Session Progress를 앨리스에게 전송한다. 이때, 다중 메시지가 포함되었음을 의미하는 Content-Type:multipart/mixed 라는 정보를 함께 보낸다. Content-Disposition 헤더를 보면 session과 early-session 두가지가 있는데, 첫번째 바운더리인 Content-Disposition:Session은 Regular session에 대한 것으로 기존의 INVITE with offer에 대한 answer의 내용이다. 두번째 바운더리인 Content-Disposition:early-session은 Early Media를 위한 Offer이다.
<pre>
Content-Type: multipart/mixed; boundary="boundary1"
Content-Length: 401
--boundary1
Content-Type: application/sdp
Content-Disposition: session

v=0
o=Bob 2890844725 2890844725 IN IP4 host.sip.org
s=
c=IN IP4 192.0.2.2
t=0 0
m=audio 30000 RTP/AVP 0

--boundary1
Content-Type: application/sdp
Content-Disposition: early-session

v=0
o=Bob 2890844714 2890844714 IN IP4 host.sip.org
s=
c=IN IP4 192.0.2.2
t=0 0
m=audio 30002 RTP/AVP 0

--boundary1--
</pre>

앨리스는 INVITE에 대한 200 OK (수화기를 드는 행동)를 밥으로 받기 전까지 Early-Offer에 대한 Answer를 할 수 있는 방법이 없다. 따라서 이때 PRACK 이 필요하다. 이 메소드를 통해 아래와 같이 Early Offer 에 대한 Answer 를 수행한다.
<pre>
Content-Type: application/sdp
Content-Disposition: early-session

v=0
o=alice 2890844717 2890744717 IN IP4 host.sip.com
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 20002 RTP/AVP 0
</pre>

PRACK에 대한 200 OK 를 받게 되면, Early Media를 통해 대화가 가능하다. 이미 Regular session 과 Early session 에 대한 Offer / Answer가 완료되었다.

밥이 수화기를 들어 200 OK 를 전송할 때, Early session 은 Regular session 으로 전환이 이루어진다.

== Delayed(Late) Media ==
SDP Delayed Offer 는 INVITE 메시지에 SDP OFFER 를 전달하지 않고, 180 RINGING 이나 200 OK 에 SDP OFFER 를 전달하는 방식이다.

SDP ANSWER 는 ACK 와 함께 전달한다. Delayed OFFER 는 수신자가 SDP 협상의 주도권을 가진다. CISCO 제품들은 DELAYED OFFER 를 사용한다.

== See also ==
* https://www.3cx.com/blog/voip-howto/sdp-voip/
* http://www.nexpert.net/497
* http://www.nexpert.net/142
* https://brunch.co.kr/@linecard/142

== References ==
<references />

[[category:SIP protocol]]

SIP SDP

2023-09-19T03:32:16Z

Pchero: /* See also */

== Overview ==
참조 원문은 이곳<ref>http://www.nexpert.net/497</ref><ref>http://www.nexpert.net/142</ref>에서 확인할 수 있다.

SDP는 코덱 협상과 같은 Capability Exchange 를 수행하는 프로토콜로 SIP 뿐만 아니라 MGCP와 Megaco에서도 사용한다. 기술적으로는 SIP와 SDP 프로토콜을 구분해서 사용하지만, SIP를 살펴볼 때 SDP는 자연스럽게 언급된다.

== SDP 의 개요 ==
SDP는 Session Description Protocol 의 약어로 멀티미디어 세션 파라미터를 협상하는 프로토콜이다. SDP는 RFC 2327을 개정한 RFC 4566 으로 권고되었다. H.323에 대한 이해가 있다면 SDP가 H.323 프로토콜의 H.245와 비슷한 역할을 수행한다고 생각하면 된다.

SIP를 요청과 응답 모델(Request & Response Model)로 정의하였듯이 SDP는 제안과 수락 모델(Offer & Answer Model)로 정의한다. SDP의 Offer/Answer Model 로의 동작에 대해서는 RFC 33264 An Offer/Answer Model with the SDP 에서 자세히 설명되어 있다.

[[File:Sdp dialog.png]]

SDP는 Capability를 협상하기 위해 기존의 호 처리 프로토콜을 이용한다. 위의 그림에서처럼 SDP는 SIP 메시지와 함께 전달된다. SIP INVITE 메시지에 SDP Offer가 포함되거나 200 OK 응답 메시지에 SDP Answer 가 포함된다.

== SDP 메시지 분석 ==
SDP는 멀티미디어를 전달하는 RTP 프로토콜에 대한 세부적인 내용을 협상한다. SDP는 아래와 같이 SIP와 다른 메시지 포멧을 유지하지만, SIP와 같이 텍스트 기반으로 구성된다.

=== Session Description ===
<pre>
v= protocal version.
o= owner/creator and session identification.
s= session name.
i= (optional) session information.
u= (optional) URI of description.
e= (optional) email address - contact detail.
p= (optional) phone number - contact detail.
c= (optional) connection information - not required if included in media description.
b= (optional) session bandwidth information.
z= (optional) time zone adjustments.
k= (optional) encryption key.
a= (optional) zero or more session attribute lines.
</pre>
* v=<version>
: Specifies the version of Session Description Protocol. As specified in RFC 4566, up to now there is only one version, which is Version 0. No minor versions exist.

* o=<username><sess-id><sess-version><nettype><addrtype><unicast-address>
: Details about the originator and identification of the session.
: <username>: The user's login. The MUST NOT contain spaces.
: <sess-id>: A numeric string used as unique identifier for the session.
: <sess-version>: A numeric string used as version number for this session description.

=== Time description ===
<pre>
t= time the session is active.
r= (optional) repeat times.
</pre>

* Media description
<pre>
m= media name/transport address.
i= (optional) media title
c= (optional) connection information - not required if included in session description.
b= (optional) bandwidth information.
k= (optional) encryption key.
a= (optional) zero or more media attribute lines.
</pre>

=== Example ===

<pre>
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.com
s=
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
</pre>

각 라인의 의미는 다음과 같다.

* v=0 (필수)
: SDP 프로토콜의 버전을 표시한다. SDP 버전은 0이다.

* o=alice 2890844526 2890844526 IN IP4 atlanta.com (필수)
: SDP 메시지를 생성한 Owner/Creator 를 표시한다. 순서대로 Username, Session-ID, Session Version, Network Type, Address Type, Unicast Address 를 표시한다.

* s= (필수)
: 세션 이름을 표시한다.

* i=(optional)
: Session information.

* u=(optional)
: URI of description.

* e=(optional)
: Email address - contact detail.

* p=(optional)
: Phone number - contact detail.

* c=IN IP4 10.1.3.33 (optional)
: 순서대로 Network Type, Address Type, Connection-Address 를 나타내며 미디어의 주소를 정의한다.

* t=0 0 (필수)
: Timing 으로 Start-time과 End-Time을 표시한다. 0 0 은 고정 세션을 의미한다.

SDP의 Capability Exchange 를 주도하는 라인은 m= 와 a= 로 RTP가 사용할 코덱, IP 주소, 포트넘버가 자세히 명기된다. SDP를 생성하는 UA는 자신이 지원가능한 모든 코덱과 능력을 아래와 같이 명기한다.

<pre>
m=audio 16444 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=ptime:20
a=rtpmap:18 G729/8000
a=ptime:20
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
</pre>

* m= (미디어 설명)
: Media Description으로 Media, Port, Protocol, Format 을 정의한다.
: Media : audio, video, text, application, message 로 표시.
: Port : 미디어가 전송될 전송포트(Transport port) 표시.
: Protocol : UDP, RTP/AVP, RTP/SAVP로 표시하며 AVP는 Audio Video Profile의 약자이다.
: Format : 미디어의 포멧을 서브필드 (a=)로 표시함을 의미.
: Payload Type 0 8 18 의 순서는 코덱 협상의 우선순위를 나타내며, Payload Type 101은 DTMF 이벤트를 정의한다. 각 포멧에 대한 상세 설명은 a= 에 표시된다.

* a= (미디어 속성)
: 미디어 속성(attributer)을 정의한다.
: a=rtpmap : Payload type, encoding name/clock rate 를 표시
: a=ptime : Packet time으로 미디어 패킷 한 개가 포함된 시간 정보로 ms로 표시 (보통 20ms).
: a=fmtp : 미디어 포멧에 대한 파라미터를 정의

* a= (미디어의 방향)
: 미디어 속성 뿐만 아니라 미디어 방향도 표시한다. 미디어의 방향은 아래와 같이 4가지로 나타낸다.
: a=sendrecv : 단말은 미디어를 송신 및 수신할 수 있음.
: a=recvonly : 단말은 수신만을 할 수 있으며 송신하지 않음.
: a=sendonly : 단말은 송신만을 할 수 있으며 수신하지 않음.
: a=inactive : 단말은 송신 및 수신을 할 수 없음 (Hold 버튼을 누를 경우)
: 별도의 언급이 없을 경우에는 a=sendrecv 로 설정되었다고 가정한다. 미디어의 방향은 다양한 부가 서비스 구현시 유용하다.

* a= (DTMF 협상)
: DTMF 전달에 관한 협상도 진행한다.
: a=rtpmap:101 telephone-event.8000 : RFC 2833에 의한 In-band DTMF를 의미.
: a=fmtp 101 0-15 : DTMF Tone 은 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, *, #, A, B, C, D 총 15 가지를 송수신 함.

== RFC 3264의 기본 SDP 협상 (Offer / Answer Model) ==
RFC 3264 An Offer/Answer Model Session Description Protocol 권고안에 나와 있는 10.1 Basic Exchange 부분을 살펴보면서 Offer/Answer 모델의 동작 방식을 살펴보자.

=== 앨리스의 "Offer" ===
앨리스는 한개의 음성 스트림과 두 개의 영상 스트림을 제안한다.
<pre>
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
</pre>

SDP를 Owner이자 Creator인 앨리스는, 음성 스트림은 G.711 ulaw 코덱과 49170 UDP 포트를 사용하며, 영상스트림은 H.261 코덱과 51372 UDP 포트를, 또 하나의 영상 스트림은 MPEG 코덱과 53000 UDP 포트를 사용한다고 제한한다.

=== 밥의 "Answer" ===
<pre>
v=0
o=bob 2890844730 2890844730 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 49920 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
</pre>

밥은 음성 스트림에 대해 G.711 ulaw 코덱과 49920 UDP 포트를 사용하고, 첫번째 영상에 대한 미디어 속성(a=) 정의를 포함하지 않고, 두 번째 영상 스트림에 대해서만 미디어 속성을 포함하고 있다. 일반적으로 미디어 속성(a=)를 포함하지 않으면 미디어 스트림이 개방되지 않는다.

=== 밥의 협상 변경 요청 "Offer" ===
밥은 Answer 후에 협상 내용을 변경을 요청한다.

<pre>
v=0
o=bob 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 65422 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
m=audio 51434 RTP/AVP 110
a=rtpmap:110 telephone-events/8000
a=recvonly
</pre>

밥은 음성 스트림에 대한 UDP 포트 넘버를 49920에서 65422로 변경하는 것과 DTMF 수신을 위한 (receive-only) 방법을 추가하였다. 일반적으로 DTMF 이벤트 처리를 위한 RTP Payload 는 Type 110 이다.

=== 앨리스의 "Answer" ===
앨리스는 밥의 제안을 승인하고, 다음과 같이 응답한다.

<pre>
v=0
o=alice 2890844526 2890844527 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
m=audio 53122 RTP/AVP 110
a=rtpmap:110 telephone-events/8000
a=sendonly
</pre>
밥의 요청을 모두 수락한다.

== RFC 3264의 One of N Codec Selection ==
IP Phone과 Gateway는 음성이나 영상 압축을 위해 DSP (Digital Signal Processor)라는 칩을 사용한다. DSP는 다수의 코덱을 지원하지만, 한 번에 하나의 코덱만을 지원한다. SDP Offer에 다수의 코덱을 전송하더라도 Answer 에서는 하나의 코덱만을 선택할 수 있다. 다수 코덱을 제안할 경우에 선택하는 방식에 대해서 알아보자.

=== 앨리스의 "Offer" ===
Offer이자 Creator인 엘리스는 음성 스트림 하나만을 제안하면서 자신의 DSP가 지원하는 G.711 ulaw, G.723, G.729 코덱을 나역한다. G.711 ulaw 가 가장 우선 순위가 높으며, 코덱 협상 완료 전까지는 미디어를 맏아 들일 수 없으므로 미디어의 방향을 "a=inactive"로 한다.

<pre>
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 62986 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=inactive
</pre>

=== 밥의 "Answer" ===
밥은 자신의 DSP가 G.711 ulaw와 G.723 코덱만을 지원하며, G.711 ulaw를 우선적으로 선택한다.

<pre>
v=0
o=bob 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 54344 RTP/AVP 0 4
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=inactive
</pre>

=== 앨리스의 "Offer" ===
앨리스는 밥이 제안한 두 개의 코덱 모두를 지원할 수 있지만 G.723 코덱을 선택하면서 "a=sendrecv"로 양방향 통화 채널을 활성화 한다. 일반적으로 우선순위가 높은 G.711 ulaw를 선택하지만, 예제에서는 G.723을 선택하는 것을 가정한다.

<pre>
v=0
o=alice 2890844526 2890844527 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 62986 RTP/AVP 4
a=rtpmap:4 G723/8000
a=sendrecv
</pre>

=== 밥의 "Answer" ===
밥은 앨리스가 제안한 G.711 코덱을 받아 들이고 "a=sendrecv"로 양방향 통화 채널을 활성화 한다.

<pre>
v=0
o=bob 2890844730 2890844732 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 54344 RTP/AVP 4
a=rtpmap:4 G723/8000
a=sendrecv
</pre>

=== inactive to sendrecv ===
처음 inactive 상태를 sendrecv로 전환하기 위해 4번에 걸친 Offer와 Answer를 교환한다. 일반적으로는 처음부터 a=sendrecv로 교환하고, 처음 제시되는 코덱이 우선순위가 높으므로 선택된다. 위의 과정은 Offer/Answer Model을 기반으로 설명하는 것이지만, 실제로는 INVITE with SDP로 제안이 되며, 200 OK with SDP 또는 180 Ringing with SDP로 2 단계로 마무리된다.

== Early Media in SDP (RFC 3959, RFC 3960) ==
Early Media 란, 실제 통화가 이루어 지기 전 전송되는 Media 를 의미한다. 대표적인 예로 컬러링이 있다.

=== Early Media 의 개요 ===
아래 그림은 일반적인 SIP 호 설정 시나리오이다. 앨리스는 수화기를 들어 전화번호를 누르면 INVITE 메시지와 함께 Offer가 이루어진다. 밥의 전화기는 Ringing (따르릉)하게되며, 180 Ringing 메시지가 앨리스에게 전달된다. 180 Ringing을 받은 앨리스는 Local Ringback을 들으면서 밥의 전화기가 울리고 있다고 인지한다. 밥은 Ringing 소리를 듣고 전화가 왔음을 인지하게 되어 전화기로 다가가 수화기를 드는 순간 200 OK 메시지와 Answer가 앨리스에게 전달된다. 200 OK를 받은 앨리스는 ACK를 밥에게 전송하며 통화가 시작된다.

[[File:Sip early media.png]]

그런데 일반적인 SIP 통화 시나리오 상에서 다음 두 가지 문제가 발생하게 된다.

* Remote Ringback
: 180 Ringing 메시지를 전달받은 앨리스의 전화기는 자체적으로 Ringback tone을 발생시킨다. 그러나, 현실에서는 컬러링이나 Remote Ringback tone을 들을 수 있어야 한다.

* Media Clipping
: 보통 사람들은 수화기를 들면서 "여보세요"라고 말한다. 위의 시나리오는 200 OK를 보내고 ACK를 받을 때까지의 이야기는 전달할 수 없게 된다. 따라서 Media Clipping이 발생할 수 밖에 없어 밥의 "여보세요"가 앨리스에게는 "세요"라고 들릴 것이다.

이러한 문제점은 SDP의 일반적인 Offer/Answer 절차 이전에 Media가 전송되어져야 한다는 것을 의미한다. 즉, Early Media는 정규 Offer/Answer 절차 이전에 전송되는 RTP를 가리킨다. 그렇다면, Early Media의 발생시점은 INVITE의 생성에서부터 ACK 신호까지이다. ACK 이후에는 정상적인 Media가 전송된다.

=== SDP 협상의 방식 ===
기본적으로 Early Media가 동작하기 위해서는 위의 그림과 같이 INVITE with SDP로 Initial Offer 가 발생되어야 한다. 위에서 언급한 Media Clipping의 경우, Invite with SDP (offer)로 보내지는 대부분의 경우 이러한 Media Clipping은 발생되지 않는다. UAC(송신자)는 200 OK의 수신 여부와는 상관없이 Offer를 하자마자 자기 스스로 들어오는 Media에 대해 재생할 준비를 하도록 되어 있다. 그러나, 이렇게 Invite with SDP 만 있는 것이 아니다.

아래와 같이 200 OK에 밥이 먼저 Offer를 할 수도 있으며, Update 메소드를 이용하여 SDP를 교환할 수도 있다.

[[File:Sdp late offer.png]]

=== Early Media 의 두 가지 모델 ===
RFC 3960에 의하면, Early Media는 다음과 같이 두 가지 모델로 구분할 수 있다.

* Gateway Model
: 이 모델은 SIP 시그널링 상에서 Early Media에 대한 특별한 언급없이 동작한다. 180 Ringing 메시지를 받으면, Local Ringback Tone을 발생시키고, 상대방으로부터 RTP(Early Media)가 전송되면, Local Ringback Tone 발생을 중단하고, RTP를 재생한다. 이 Gateway 모델의 문제점은 Forking 및 Security 문제가 있다.

* Application Server Model
: SIP 시그널시 Early Media에 대한 Offer/Answer를 가능하게 한다. RFC 3959에 정의된 Content-Disposition 헤더에 Session 또는 Early-session의 새로운 Disposition Type을 설정하여 Early-Media가 가능하게 한다.

=== Ringback Tone 재생 정책 ===
PSTN 상에서 수신자가 Alert 메시지를 보내면 Ringback Tone은 PBX에 의해 재생된다. SIP의 경우 UAS(수신자)에 의해 Ringback 이 재생되지 않으면, UAC에서 자체적으로 Ringback tone을 재생하기로 되어 있다. 만일, Announcement 또는 Special Ringing Tone이 UAS에 재생이 되면, UAC는 자체적인 재생을 중단하고 UAS로 부터 오는 Media를 재생하는 것이 일반적이다. 그러나, UAS가 Early Media 를 전송하려는 의도 없이 Early Offer를 진행하기도 하고, Reliable Provisional Response 없이 Ealry Media를 전송하기도 하기 때문에 UAC는 쉽게 Local Ringback Tone을 재생해야할 지 말아야할 지를 결정할 수 없다.

Local Ringback Tone 재생에 관련해서 다음과 같은 정책을 구현해야 한다.
<pre>
- 180 Ringing 을 받지 않았다면, Local Ringing 을 재생하지 않는다.
- 180 Ringing 을 받았으나 수신되는 Media 패킷이 없다면, Local Ringing을 재생한다.
- 180 Ringing 을 받았으면서 Media 패킷이 수신된다면, Media를 재생하고 Local Ringing을 재생하지 않는다.
</pre>
180 Ringing은 수신측이 전화기가 울리고 있음을 의미한다.

=== Application Server Model 상에서의 Early media ===
Early Media Session 은 지금까지 이야기한 Regual Session에서 함께 처리된다. 그러나, Application Server Model은 Early Media를 위한 별도의 절차를 수행한다. 따라서, 하나의 호 시그널링에서 Early Media Session과 Regular Session 을 동시에 Offer/Answer를 수행한 후 전환한다. 이 때, Content-Disposition Header 에 Session 과 Early-session 이라고 하여 각각의 쓰임새를 구분한다.

Early session 이 Regular session 으로 전환될 때, 코덱을 변경할 필요가 없도록 하기 위하여 Early Media session 과 Media session은 같은 코덱을 사용하는 것을 권장한다. RFC 3959의 예제를 보자.

[[File:Sdp rfc 3959.png]]

앨리스는 밥에게 Contect-Disposition: session 헤더를 INVITE에 추가해서 전송한다. 이 헤더의 의미는 INVITE에 포함된 Offer는 Regular session 에 대한 것임을 표시한다.
<pre>
Content-Type: application/sdp
Content-Disposition: session

v=0
o=alice 2890844730 2890844731 IN IP4 host.sip.com
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 20000 RTP/AVP 0
</pre>

이후 밥은 183 Session Progress를 앨리스에게 전송한다. 이때, 다중 메시지가 포함되었음을 의미하는 Content-Type:multipart/mixed 라는 정보를 함께 보낸다. Content-Disposition 헤더를 보면 session과 early-session 두가지가 있는데, 첫번째 바운더리인 Content-Disposition:Session은 Regular session에 대한 것으로 기존의 INVITE with offer에 대한 answer의 내용이다. 두번째 바운더리인 Content-Disposition:early-session은 Early Media를 위한 Offer이다.
<pre>
Content-Type: multipart/mixed; boundary="boundary1"
Content-Length: 401
--boundary1
Content-Type: application/sdp
Content-Disposition: session

v=0
o=Bob 2890844725 2890844725 IN IP4 host.sip.org
s=
c=IN IP4 192.0.2.2
t=0 0
m=audio 30000 RTP/AVP 0

--boundary1
Content-Type: application/sdp
Content-Disposition: early-session

v=0
o=Bob 2890844714 2890844714 IN IP4 host.sip.org
s=
c=IN IP4 192.0.2.2
t=0 0
m=audio 30002 RTP/AVP 0

--boundary1--
</pre>

앨리스는 INVITE에 대한 200 OK (수화기를 드는 행동)를 밥으로 받기 전까지 Early-Offer에 대한 Answer를 할 수 있는 방법이 없다. 따라서 이때 PRACK 이 필요하다. 이 메소드를 통해 아래와 같이 Early Offer 에 대한 Answer 를 수행한다.
<pre>
Content-Type: application/sdp
Content-Disposition: early-session

v=0
o=alice 2890844717 2890744717 IN IP4 host.sip.com
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 20002 RTP/AVP 0
</pre>

PRACK에 대한 200 OK 를 받게 되면, Early Media를 통해 대화가 가능하다. 이미 Regular session 과 Early session 에 대한 Offer / Answer가 완료되었다.

밥이 수화기를 들어 200 OK 를 전송할 때, Early session 은 Regular session 으로 전환이 이루어진다.

== Delayed(Late) Media in SDP (RFC 3959, RFC 3960) ==
SDP Delayed Offer 는 INVITE 메시지에 SDP OFFER 를 전달하지 않고, 180 RINGING 이나 200 OK 에 SDP OFFER 를 전달하는 방식이다.

SDP ANSWER 는 ACK 와 함께 전달한다. Delayed OFFER 는 수신자가 SDP 협상의 주도권을 가진다. CISCO 제품들은 DELAYED OFFER 를 사용한다.

== See also ==
* https://www.3cx.com/blog/voip-howto/sdp-voip/
* http://www.nexpert.net/497
* http://www.nexpert.net/142
* https://brunch.co.kr/@linecard/142

== References ==
<references />

[[category:SIP protocol]]

SIP SDP

2023-09-19T03:31:41Z

Pchero: /* Early Media in SDP (RFC 3959, RFC 3960) */

== Overview ==
참조 원문은 이곳<ref>http://www.nexpert.net/497</ref><ref>http://www.nexpert.net/142</ref>에서 확인할 수 있다.

SDP는 코덱 협상과 같은 Capability Exchange 를 수행하는 프로토콜로 SIP 뿐만 아니라 MGCP와 Megaco에서도 사용한다. 기술적으로는 SIP와 SDP 프로토콜을 구분해서 사용하지만, SIP를 살펴볼 때 SDP는 자연스럽게 언급된다.

== SDP 의 개요 ==
SDP는 Session Description Protocol 의 약어로 멀티미디어 세션 파라미터를 협상하는 프로토콜이다. SDP는 RFC 2327을 개정한 RFC 4566 으로 권고되었다. H.323에 대한 이해가 있다면 SDP가 H.323 프로토콜의 H.245와 비슷한 역할을 수행한다고 생각하면 된다.

SIP를 요청과 응답 모델(Request & Response Model)로 정의하였듯이 SDP는 제안과 수락 모델(Offer & Answer Model)로 정의한다. SDP의 Offer/Answer Model 로의 동작에 대해서는 RFC 33264 An Offer/Answer Model with the SDP 에서 자세히 설명되어 있다.

[[File:Sdp dialog.png]]

SDP는 Capability를 협상하기 위해 기존의 호 처리 프로토콜을 이용한다. 위의 그림에서처럼 SDP는 SIP 메시지와 함께 전달된다. SIP INVITE 메시지에 SDP Offer가 포함되거나 200 OK 응답 메시지에 SDP Answer 가 포함된다.

== SDP 메시지 분석 ==
SDP는 멀티미디어를 전달하는 RTP 프로토콜에 대한 세부적인 내용을 협상한다. SDP는 아래와 같이 SIP와 다른 메시지 포멧을 유지하지만, SIP와 같이 텍스트 기반으로 구성된다.

=== Session Description ===
<pre>
v= protocal version.
o= owner/creator and session identification.
s= session name.
i= (optional) session information.
u= (optional) URI of description.
e= (optional) email address - contact detail.
p= (optional) phone number - contact detail.
c= (optional) connection information - not required if included in media description.
b= (optional) session bandwidth information.
z= (optional) time zone adjustments.
k= (optional) encryption key.
a= (optional) zero or more session attribute lines.
</pre>
* v=<version>
: Specifies the version of Session Description Protocol. As specified in RFC 4566, up to now there is only one version, which is Version 0. No minor versions exist.

* o=<username><sess-id><sess-version><nettype><addrtype><unicast-address>
: Details about the originator and identification of the session.
: <username>: The user's login. The MUST NOT contain spaces.
: <sess-id>: A numeric string used as unique identifier for the session.
: <sess-version>: A numeric string used as version number for this session description.

=== Time description ===
<pre>
t= time the session is active.
r= (optional) repeat times.
</pre>

* Media description
<pre>
m= media name/transport address.
i= (optional) media title
c= (optional) connection information - not required if included in session description.
b= (optional) bandwidth information.
k= (optional) encryption key.
a= (optional) zero or more media attribute lines.
</pre>

=== Example ===

<pre>
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.com
s=
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
</pre>

각 라인의 의미는 다음과 같다.

* v=0 (필수)
: SDP 프로토콜의 버전을 표시한다. SDP 버전은 0이다.

* o=alice 2890844526 2890844526 IN IP4 atlanta.com (필수)
: SDP 메시지를 생성한 Owner/Creator 를 표시한다. 순서대로 Username, Session-ID, Session Version, Network Type, Address Type, Unicast Address 를 표시한다.

* s= (필수)
: 세션 이름을 표시한다.

* i=(optional)
: Session information.

* u=(optional)
: URI of description.

* e=(optional)
: Email address - contact detail.

* p=(optional)
: Phone number - contact detail.

* c=IN IP4 10.1.3.33 (optional)
: 순서대로 Network Type, Address Type, Connection-Address 를 나타내며 미디어의 주소를 정의한다.

* t=0 0 (필수)
: Timing 으로 Start-time과 End-Time을 표시한다. 0 0 은 고정 세션을 의미한다.

SDP의 Capability Exchange 를 주도하는 라인은 m= 와 a= 로 RTP가 사용할 코덱, IP 주소, 포트넘버가 자세히 명기된다. SDP를 생성하는 UA는 자신이 지원가능한 모든 코덱과 능력을 아래와 같이 명기한다.

<pre>
m=audio 16444 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=ptime:20
a=rtpmap:18 G729/8000
a=ptime:20
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
</pre>

* m= (미디어 설명)
: Media Description으로 Media, Port, Protocol, Format 을 정의한다.
: Media : audio, video, text, application, message 로 표시.
: Port : 미디어가 전송될 전송포트(Transport port) 표시.
: Protocol : UDP, RTP/AVP, RTP/SAVP로 표시하며 AVP는 Audio Video Profile의 약자이다.
: Format : 미디어의 포멧을 서브필드 (a=)로 표시함을 의미.
: Payload Type 0 8 18 의 순서는 코덱 협상의 우선순위를 나타내며, Payload Type 101은 DTMF 이벤트를 정의한다. 각 포멧에 대한 상세 설명은 a= 에 표시된다.

* a= (미디어 속성)
: 미디어 속성(attributer)을 정의한다.
: a=rtpmap : Payload type, encoding name/clock rate 를 표시
: a=ptime : Packet time으로 미디어 패킷 한 개가 포함된 시간 정보로 ms로 표시 (보통 20ms).
: a=fmtp : 미디어 포멧에 대한 파라미터를 정의

* a= (미디어의 방향)
: 미디어 속성 뿐만 아니라 미디어 방향도 표시한다. 미디어의 방향은 아래와 같이 4가지로 나타낸다.
: a=sendrecv : 단말은 미디어를 송신 및 수신할 수 있음.
: a=recvonly : 단말은 수신만을 할 수 있으며 송신하지 않음.
: a=sendonly : 단말은 송신만을 할 수 있으며 수신하지 않음.
: a=inactive : 단말은 송신 및 수신을 할 수 없음 (Hold 버튼을 누를 경우)
: 별도의 언급이 없을 경우에는 a=sendrecv 로 설정되었다고 가정한다. 미디어의 방향은 다양한 부가 서비스 구현시 유용하다.

* a= (DTMF 협상)
: DTMF 전달에 관한 협상도 진행한다.
: a=rtpmap:101 telephone-event.8000 : RFC 2833에 의한 In-band DTMF를 의미.
: a=fmtp 101 0-15 : DTMF Tone 은 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, *, #, A, B, C, D 총 15 가지를 송수신 함.

== RFC 3264의 기본 SDP 협상 (Offer / Answer Model) ==
RFC 3264 An Offer/Answer Model Session Description Protocol 권고안에 나와 있는 10.1 Basic Exchange 부분을 살펴보면서 Offer/Answer 모델의 동작 방식을 살펴보자.

=== 앨리스의 "Offer" ===
앨리스는 한개의 음성 스트림과 두 개의 영상 스트림을 제안한다.
<pre>
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
</pre>

SDP를 Owner이자 Creator인 앨리스는, 음성 스트림은 G.711 ulaw 코덱과 49170 UDP 포트를 사용하며, 영상스트림은 H.261 코덱과 51372 UDP 포트를, 또 하나의 영상 스트림은 MPEG 코덱과 53000 UDP 포트를 사용한다고 제한한다.

=== 밥의 "Answer" ===
<pre>
v=0
o=bob 2890844730 2890844730 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 49920 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
</pre>

밥은 음성 스트림에 대해 G.711 ulaw 코덱과 49920 UDP 포트를 사용하고, 첫번째 영상에 대한 미디어 속성(a=) 정의를 포함하지 않고, 두 번째 영상 스트림에 대해서만 미디어 속성을 포함하고 있다. 일반적으로 미디어 속성(a=)를 포함하지 않으면 미디어 스트림이 개방되지 않는다.

=== 밥의 협상 변경 요청 "Offer" ===
밥은 Answer 후에 협상 내용을 변경을 요청한다.

<pre>
v=0
o=bob 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 65422 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
m=audio 51434 RTP/AVP 110
a=rtpmap:110 telephone-events/8000
a=recvonly
</pre>

밥은 음성 스트림에 대한 UDP 포트 넘버를 49920에서 65422로 변경하는 것과 DTMF 수신을 위한 (receive-only) 방법을 추가하였다. 일반적으로 DTMF 이벤트 처리를 위한 RTP Payload 는 Type 110 이다.

=== 앨리스의 "Answer" ===
앨리스는 밥의 제안을 승인하고, 다음과 같이 응답한다.

<pre>
v=0
o=alice 2890844526 2890844527 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
m=audio 53122 RTP/AVP 110
a=rtpmap:110 telephone-events/8000
a=sendonly
</pre>
밥의 요청을 모두 수락한다.

== RFC 3264의 One of N Codec Selection ==
IP Phone과 Gateway는 음성이나 영상 압축을 위해 DSP (Digital Signal Processor)라는 칩을 사용한다. DSP는 다수의 코덱을 지원하지만, 한 번에 하나의 코덱만을 지원한다. SDP Offer에 다수의 코덱을 전송하더라도 Answer 에서는 하나의 코덱만을 선택할 수 있다. 다수 코덱을 제안할 경우에 선택하는 방식에 대해서 알아보자.

=== 앨리스의 "Offer" ===
Offer이자 Creator인 엘리스는 음성 스트림 하나만을 제안하면서 자신의 DSP가 지원하는 G.711 ulaw, G.723, G.729 코덱을 나역한다. G.711 ulaw 가 가장 우선 순위가 높으며, 코덱 협상 완료 전까지는 미디어를 맏아 들일 수 없으므로 미디어의 방향을 "a=inactive"로 한다.

<pre>
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 62986 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=inactive
</pre>

=== 밥의 "Answer" ===
밥은 자신의 DSP가 G.711 ulaw와 G.723 코덱만을 지원하며, G.711 ulaw를 우선적으로 선택한다.

<pre>
v=0
o=bob 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 54344 RTP/AVP 0 4
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=inactive
</pre>

=== 앨리스의 "Offer" ===
앨리스는 밥이 제안한 두 개의 코덱 모두를 지원할 수 있지만 G.723 코덱을 선택하면서 "a=sendrecv"로 양방향 통화 채널을 활성화 한다. 일반적으로 우선순위가 높은 G.711 ulaw를 선택하지만, 예제에서는 G.723을 선택하는 것을 가정한다.

<pre>
v=0
o=alice 2890844526 2890844527 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 62986 RTP/AVP 4
a=rtpmap:4 G723/8000
a=sendrecv
</pre>

=== 밥의 "Answer" ===
밥은 앨리스가 제안한 G.711 코덱을 받아 들이고 "a=sendrecv"로 양방향 통화 채널을 활성화 한다.

<pre>
v=0
o=bob 2890844730 2890844732 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 54344 RTP/AVP 4
a=rtpmap:4 G723/8000
a=sendrecv
</pre>

=== inactive to sendrecv ===
처음 inactive 상태를 sendrecv로 전환하기 위해 4번에 걸친 Offer와 Answer를 교환한다. 일반적으로는 처음부터 a=sendrecv로 교환하고, 처음 제시되는 코덱이 우선순위가 높으므로 선택된다. 위의 과정은 Offer/Answer Model을 기반으로 설명하는 것이지만, 실제로는 INVITE with SDP로 제안이 되며, 200 OK with SDP 또는 180 Ringing with SDP로 2 단계로 마무리된다.

== Early Media in SDP (RFC 3959, RFC 3960) ==
Early Media 란, 실제 통화가 이루어 지기 전 전송되는 Media 를 의미한다. 대표적인 예로 컬러링이 있다.

=== Early Media 의 개요 ===
아래 그림은 일반적인 SIP 호 설정 시나리오이다. 앨리스는 수화기를 들어 전화번호를 누르면 INVITE 메시지와 함께 Offer가 이루어진다. 밥의 전화기는 Ringing (따르릉)하게되며, 180 Ringing 메시지가 앨리스에게 전달된다. 180 Ringing을 받은 앨리스는 Local Ringback을 들으면서 밥의 전화기가 울리고 있다고 인지한다. 밥은 Ringing 소리를 듣고 전화가 왔음을 인지하게 되어 전화기로 다가가 수화기를 드는 순간 200 OK 메시지와 Answer가 앨리스에게 전달된다. 200 OK를 받은 앨리스는 ACK를 밥에게 전송하며 통화가 시작된다.

[[File:Sip early media.png]]

그런데 일반적인 SIP 통화 시나리오 상에서 다음 두 가지 문제가 발생하게 된다.

* Remote Ringback
: 180 Ringing 메시지를 전달받은 앨리스의 전화기는 자체적으로 Ringback tone을 발생시킨다. 그러나, 현실에서는 컬러링이나 Remote Ringback tone을 들을 수 있어야 한다.

* Media Clipping
: 보통 사람들은 수화기를 들면서 "여보세요"라고 말한다. 위의 시나리오는 200 OK를 보내고 ACK를 받을 때까지의 이야기는 전달할 수 없게 된다. 따라서 Media Clipping이 발생할 수 밖에 없어 밥의 "여보세요"가 앨리스에게는 "세요"라고 들릴 것이다.

이러한 문제점은 SDP의 일반적인 Offer/Answer 절차 이전에 Media가 전송되어져야 한다는 것을 의미한다. 즉, Early Media는 정규 Offer/Answer 절차 이전에 전송되는 RTP를 가리킨다. 그렇다면, Early Media의 발생시점은 INVITE의 생성에서부터 ACK 신호까지이다. ACK 이후에는 정상적인 Media가 전송된다.

=== SDP 협상의 방식 ===
기본적으로 Early Media가 동작하기 위해서는 위의 그림과 같이 INVITE with SDP로 Initial Offer 가 발생되어야 한다. 위에서 언급한 Media Clipping의 경우, Invite with SDP (offer)로 보내지는 대부분의 경우 이러한 Media Clipping은 발생되지 않는다. UAC(송신자)는 200 OK의 수신 여부와는 상관없이 Offer를 하자마자 자기 스스로 들어오는 Media에 대해 재생할 준비를 하도록 되어 있다. 그러나, 이렇게 Invite with SDP 만 있는 것이 아니다.

아래와 같이 200 OK에 밥이 먼저 Offer를 할 수도 있으며, Update 메소드를 이용하여 SDP를 교환할 수도 있다.

[[File:Sdp late offer.png]]

=== Early Media 의 두 가지 모델 ===
RFC 3960에 의하면, Early Media는 다음과 같이 두 가지 모델로 구분할 수 있다.

* Gateway Model
: 이 모델은 SIP 시그널링 상에서 Early Media에 대한 특별한 언급없이 동작한다. 180 Ringing 메시지를 받으면, Local Ringback Tone을 발생시키고, 상대방으로부터 RTP(Early Media)가 전송되면, Local Ringback Tone 발생을 중단하고, RTP를 재생한다. 이 Gateway 모델의 문제점은 Forking 및 Security 문제가 있다.

* Application Server Model
: SIP 시그널시 Early Media에 대한 Offer/Answer를 가능하게 한다. RFC 3959에 정의된 Content-Disposition 헤더에 Session 또는 Early-session의 새로운 Disposition Type을 설정하여 Early-Media가 가능하게 한다.

=== Ringback Tone 재생 정책 ===
PSTN 상에서 수신자가 Alert 메시지를 보내면 Ringback Tone은 PBX에 의해 재생된다. SIP의 경우 UAS(수신자)에 의해 Ringback 이 재생되지 않으면, UAC에서 자체적으로 Ringback tone을 재생하기로 되어 있다. 만일, Announcement 또는 Special Ringing Tone이 UAS에 재생이 되면, UAC는 자체적인 재생을 중단하고 UAS로 부터 오는 Media를 재생하는 것이 일반적이다. 그러나, UAS가 Early Media 를 전송하려는 의도 없이 Early Offer를 진행하기도 하고, Reliable Provisional Response 없이 Ealry Media를 전송하기도 하기 때문에 UAC는 쉽게 Local Ringback Tone을 재생해야할 지 말아야할 지를 결정할 수 없다.

Local Ringback Tone 재생에 관련해서 다음과 같은 정책을 구현해야 한다.
<pre>
- 180 Ringing 을 받지 않았다면, Local Ringing 을 재생하지 않는다.
- 180 Ringing 을 받았으나 수신되는 Media 패킷이 없다면, Local Ringing을 재생한다.
- 180 Ringing 을 받았으면서 Media 패킷이 수신된다면, Media를 재생하고 Local Ringing을 재생하지 않는다.
</pre>
180 Ringing은 수신측이 전화기가 울리고 있음을 의미한다.

=== Application Server Model 상에서의 Early media ===
Early Media Session 은 지금까지 이야기한 Regual Session에서 함께 처리된다. 그러나, Application Server Model은 Early Media를 위한 별도의 절차를 수행한다. 따라서, 하나의 호 시그널링에서 Early Media Session과 Regular Session 을 동시에 Offer/Answer를 수행한 후 전환한다. 이 때, Content-Disposition Header 에 Session 과 Early-session 이라고 하여 각각의 쓰임새를 구분한다.

Early session 이 Regular session 으로 전환될 때, 코덱을 변경할 필요가 없도록 하기 위하여 Early Media session 과 Media session은 같은 코덱을 사용하는 것을 권장한다. RFC 3959의 예제를 보자.

[[File:Sdp rfc 3959.png]]

앨리스는 밥에게 Contect-Disposition: session 헤더를 INVITE에 추가해서 전송한다. 이 헤더의 의미는 INVITE에 포함된 Offer는 Regular session 에 대한 것임을 표시한다.
<pre>
Content-Type: application/sdp
Content-Disposition: session

v=0
o=alice 2890844730 2890844731 IN IP4 host.sip.com
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 20000 RTP/AVP 0
</pre>

이후 밥은 183 Session Progress를 앨리스에게 전송한다. 이때, 다중 메시지가 포함되었음을 의미하는 Content-Type:multipart/mixed 라는 정보를 함께 보낸다. Content-Disposition 헤더를 보면 session과 early-session 두가지가 있는데, 첫번째 바운더리인 Content-Disposition:Session은 Regular session에 대한 것으로 기존의 INVITE with offer에 대한 answer의 내용이다. 두번째 바운더리인 Content-Disposition:early-session은 Early Media를 위한 Offer이다.
<pre>
Content-Type: multipart/mixed; boundary="boundary1"
Content-Length: 401
--boundary1
Content-Type: application/sdp
Content-Disposition: session

v=0
o=Bob 2890844725 2890844725 IN IP4 host.sip.org
s=
c=IN IP4 192.0.2.2
t=0 0
m=audio 30000 RTP/AVP 0

--boundary1
Content-Type: application/sdp
Content-Disposition: early-session

v=0
o=Bob 2890844714 2890844714 IN IP4 host.sip.org
s=
c=IN IP4 192.0.2.2
t=0 0
m=audio 30002 RTP/AVP 0

--boundary1--
</pre>

앨리스는 INVITE에 대한 200 OK (수화기를 드는 행동)를 밥으로 받기 전까지 Early-Offer에 대한 Answer를 할 수 있는 방법이 없다. 따라서 이때 PRACK 이 필요하다. 이 메소드를 통해 아래와 같이 Early Offer 에 대한 Answer 를 수행한다.
<pre>
Content-Type: application/sdp
Content-Disposition: early-session

v=0
o=alice 2890844717 2890744717 IN IP4 host.sip.com
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 20002 RTP/AVP 0
</pre>

PRACK에 대한 200 OK 를 받게 되면, Early Media를 통해 대화가 가능하다. 이미 Regular session 과 Early session 에 대한 Offer / Answer가 완료되었다.

밥이 수화기를 들어 200 OK 를 전송할 때, Early session 은 Regular session 으로 전환이 이루어진다.

== Delayed(Late) Media in SDP (RFC 3959, RFC 3960) ==
SDP Delayed Offer 는 INVITE 메시지에 SDP OFFER 를 전달하지 않고, 180 RINGING 이나 200 OK 에 SDP OFFER 를 전달하는 방식이다.

SDP ANSWER 는 ACK 와 함께 전달한다. Delayed OFFER 는 수신자가 SDP 협상의 주도권을 가진다. CISCO 제품들은 DELAYED OFFER 를 사용한다.

== See also ==
* https://www.3cx.com/blog/voip-howto/sdp-voip/

== References ==
<references />

[[category:SIP protocol]]

Sipexer

2023-08-30T01:21:31Z

Pchero: Created page with "== Overview == sipexer - Modern and flexible SIP (RFC3261) command line tool 내용 정리. == OPTIONS ping == <pre> # /usr/local/bin/sipexer -nagios -fu heartbeat 10.75.0.42:5060 [info] [sipexer.go:1578] main.SIPExerDialogLoop(): local socket address: 10.75.0.42:36617 (udp) [info] [sipexer.go:1579] main.SIPExerDialogLoop(): local via address: 10.75.0.42:36617 [info] [sipexer.go:1580] main.SIPExerDialogLoop(): sending to udp 10.75.0.42:5060: --- OPTIONS sip:10.75.0.4..."

== Overview ==
sipexer - Modern and flexible SIP (RFC3261) command line tool 내용 정리.

== OPTIONS ping ==
<pre>
# /usr/local/bin/sipexer -nagios -fu heartbeat 10.75.0.42:5060

[info] [sipexer.go:1578] main.SIPExerDialogLoop(): local socket address: 10.75.0.42:36617 (udp)
[info] [sipexer.go:1579] main.SIPExerDialogLoop(): local via address: 10.75.0.42:36617
[info] [sipexer.go:1580] main.SIPExerDialogLoop(): sending to udp 10.75.0.42:5060: [[---
OPTIONS sip:10.75.0.42:5060 SIP/2.0
Via: SIP/2.0/UDP 10.75.0.42:36617;rport;branch=z9hG4bKSG.3b6e77cc-dbf8-4f58-9809-7bca9c3f9272
From: <sip:heartbeat@localhost>;tag=2d5b7fec-6f21-45e6-a20c-b2ae39535657
To: <sip:bob@localhost>
Call-ID: 9a11ff73-de7a-4a19-a0e4-38fa8757ea66
CSeq: 514429 OPTIONS
Date: Wed, 30 Aug 2023 00:40:44 UTC
User-Agent: SIPExer v1.1.0
Max-Forwards: 10
Content-Length: 0

[info] [sipexer.go:1582] main.SIPExerDialogLoop(): ---]]

[info] [sipexer.go:1633] main.SIPExerDialogLoop(): response-received: from=10.75.0.42:5060 bytes=438 data=[[---
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.75.0.42:36617;rport=36617;branch=z9hG4bKSG.3b6e77cc-dbf8-4f58-9809-7bca9c3f9272;received=10.75.0.42
From: <sip:heartbeat@localhost>;tag=2d5b7fec-6f21-45e6-a20c-b2ae39535657
To: <sip:bob@localhost>;tag=8cc31d58288b2b802886d8395a3eac46.7aa55e46
Call-ID: 9a11ff73-de7a-4a19-a0e4-38fa8757ea66
CSeq: 514429 OPTIONS
Accept: */*
Accept-Encoding:
Accept-Language: en
Supported:
Content-Length: 0

[info] [sipexer.go:1635] main.SIPExerDialogLoop(): ---]]
</pre>

== See also ==
* https://github.com/miconda/sipexer

[[category:command/utility]]

Rtpengine

2023-08-09T03:43:02Z

Pchero: /* Control scripts */

== Overview ==
RTPEngine 내용 정리.

== Basic ==
RTPEngine 은 RTP media stream proxy 서버이다.

== Installation ==
Required packages
<pre>
pkg-config
GLib including GThread and GLib-JSON version 2.x
zlib
OpenSSL
PCRE library
XMLRPC-C version 1.16.08 or higher
hiredis library
gperf
libcurl version 3.x or 4.x
libevent version 2.x
libpcap
libsystemd
spandsp
MySQL or MariaDB client library (optional for media playback and call recording daemon)
libiptc library for iptables management (optional)
ffmpeg codec libraries for transcoding (optional) such as libavcodec, libavfilter, libswresample
bcg729 for full G.729 transcoding support (optional)
</pre>

추가적으로 다음의 패키지들도 필요하다.
<pre>
libconfig-tiny-perl
module-assistant
libxmlrpc-c++8-dev
linux-*-$(uname -r)
</pre>

때때로 아래와 같은 에러가 나오면서 실행이 안되는 경우가 있는데, 이럴땐, linux-*-$(uname -r) 패키지 설치 후 다시 빌드를 진행하면 해결된다.
<pre>
[1581510173.595075] ERR: FAILED TO CREATE KERNEL TABLE 0 (No such file or directory), KERNEL FORWARDING DISABLED
[1581510173.595925] CRIT: Fatal error: Failed to open UDP control connection port
</pre>

== Kernel Module ==
The kernel module supports multiple forwarding tables which are identified through their ID number. By default, up to 64 forwarding tables can be created and used, giving them the ID numbers 0 through 63.

Each forwarding table can be thought of a separated proxy instance. Each running instance of the rtpengine daemon controls one such table, and each table can only be controlled by one running instance of the daemon at any given time. In the most common setup, there will be only a single instance of the daemon running and there will be only a single forward table in use, with ID zero.

The kernel module can be loaded with the command.
<pre>
$ modprove xt_RTPENGINE
</pre>

With the module loaded, a new directory will appear in /proc, namely /proc/rtpengine/. After loading, the directory will contain only two pseudo-fils, control and list. The control file is write-only and is used to create and delete forwarding tables, while the list file is read-only and will produce a list of currently active forwarding tables. With no tables active, it will produce an empty output.

The control pseudo-file supports to commands, add and del, each followed by the forwarding table ID number. To manually create a forwarding. table with ID 42, the following command can be used.
<pre>
$ echo 'add 42' > /proc/rtpengine/control
</pre>

After this, the list pseudo-filie will produce the single line 42 as output. This will also create a directory called 42 in /proc/rtpengine/, which contains additional pseudo-files to control this particular forwarding table.

To delete this forwarding table, the command 'del 42' can be issued like above. This will only if no rtpengine daemon is currently running and controlling this table.

Each subdirectory /proc/rtpengine/$ID/ corresponding to each forwarding table contains the pseudo-files blast, control, list and status. The control file is write-only while the others are read-only. The control file will be kept open by the rtpengine daemon while it's running

== Control scripts ==
=== rtpengine-ctl ===
<pre>
$ ./rtpengine-ctl

rtpengine-ctl [ -ip <ipaddress>[:<port>] -port <port> ] <command>

Supported commands are:

list [ numsessions | maxsessions | maxopenfiles | sessions [ <callid> | all | own | foreign ] | totals | loglevel ]
numsessions : print the number of sessions
maxsessions : print the number of allowed sessions
maxopenfiles : print the number of allowed open files
sessions <callid> : print detail about one session
sessions all : print one-liner all sessions information
sessions own : print one-liner own sessions information
sessions foreign : print one-liner foreign sessions information
totals : print total statistics
timeout : print timeout parameter
silenttimeout : print silent-timeout parameter
finaltimeout : print final-timeout parameter
loglevel : print current log level
redisallowederrors : print redis-allowed-errors parameter
redisdisabletime : print redis-disable-time parameter
redisconnecttimeout : print redis-connect-timeout parameter
rediscmdtimeout : print redis-cmd-timeout parameter
controltos : print control-tos parameter

get : get is an alias for list, same parameters apply

terminate [ <callid> | all | own | foreign ]
<callid> : session is immediately terminated
all : terminates all current sessions
own : terminates own current sessions
foreign : terminates foreign current sessions

set [ maxsessions <int> | maxopenfiles <uint> | timeout <uint> | silent_timeout <uint> | final_timeout <uint> | loglevel <uint> ]
maxsessions <int> : set the max nr of allowed sessions
maxopenfiles <uint> : set the max nr of allowed open files
timeout <uint> : set the --timeout parameter
silenttimeout <uint> : set the --silent-timeout parameter
finaltimeout <uint> : set the --final-timeout parameter
loglevel <uint> : set the log level to new value (1-7)
redisallowederrors : set the --redis-allowed-errors parameter
redisdisabletime : set the --redis-disable-time parameter
redisconnecttimeout : set the --redis-connect-timeout parameter
rediscmdtimeout : set the --redis-cmd-timeout parameter
controltos : set the --control-tos parameter

params [ start | current | diff ]
start : lists the initial values of all the configuration file parameters
current : lists the present values of all the configuration file parameters
diff : compares initial and present values of all the configuration file parameters and lists the updated parameters
revert : reverts the values of all the configuration file parameters to their initial values

ksadd [ keyspace <uint>]
keyspace <uint> : subscribe to 'keyspace' database

ksrm [ keyspace <uint>]
keyspace <uint> : unsubscribe to 'keyspace' database
: remove all foreign calls for that 'keyspace'

kslist : print all currently subscribed keyspaces

Return Value:
0 on success with output from server side, other values for failure.
</pre>

<pre>
$ /usr/local/src/rtpengine/utils/rtpengine-ctl list sessions all
callid: 3d73842720964cefbad634027c1f135d-419 | deletionmark: no | created: 1691552773 | proxy:10.76.0.105:55290 | redis_keyspace:12 | foreign:no
callid: 4d3df327-1c79-498d-82ad-64994d16e60d | deletionmark: no | created: 1691552770 | proxy:10.97.76.4:59999 | redis_keyspace:12 | foreign:no
</pre>

== See also ==
* https://github.com/sipwise/rtpengine

[[category:system]]

STIR/SHAKEN

2023-08-02T14:39:12Z

Pchero: /* Validation */

== Overview ==
STIR/SHAKEN 내용 정리.

== STIR/SHAKEN ==
The Federal Communications Commission(FCC) has been encouraging the telecommunications industry to develop a solution to stop robocalls and spoofed calling numbers since 2014. The industry's response has been to develop a new technology standard called STIR(Secure Telephony Identity Revisited) and SHAKEN(Secure Handling of Asserted information using toKENs) which defines how telephone service providers should implement the STIR technology to ensure calling numbers are not spoofed.

== How STIR/SHAKEN works ==
STIR/SHAKEN uses digital certificates, based on common public key cryptography techniques, to ensure the calling number of a telephone call is secure. In simple terms, each telephone service provider obtains their digital certificate from a certificate authority who is trusted by other telephone service providers. The certificate technology enables the called party to verify that the calling number is accurate and has not been spoofed.

* A SIP INVITE is received by the originating telephone service provider.
* The originating telephone service provider checks the call source and calling number to determine how to attest for the validity of the calling number.
** Full Attestation(A): The service provider has authenticated the calling party and they are authorized to use the calling number. An example of this case is a subscriber registered with the originating telephone service provider's software.
** Partial Attestation(B): The service provider has authenticated the call origination, but cannot verify the call source is authorized to use the calling number. An example of this use case is a telephone number behind an enterprise PBX.
** Gateway Attestation(C): The service provider has authenticated from where it received the call, but cannot authenticate the call source. An example of this case would be a call received from an international gateway.
* The originating telephone service provider uses the authentication service to create a SIP identity header. The authentication service could be a third-party service hosted in the cloud software application integrated with the telephone service provider's Softswitch or Session Border Controller(SBC). The SIP identity header contains the following data.
** Calling number
** Called number(s)
** Current timestamp
** Attestation level
** Origination identifier
* The SIP INVITE with the SIP identity header is sent to the terminating telephone service provider. In addition, the identity token may be sent across the internet, around non-SIP call segments, using Out-of-Band SHAKEN.
* The SIP INVITE with identity header is passed to the verification service.
* The verification service obtains the digital certificate of the originating telephone service provider from the public certificate repository and begins a multi-step verification process. If all verification steps are successful, then the calling number has not been spoofed.
** The SIP identity header is base64 URL decoded and the details are compared to the SIP INVITE message.
** The public key of the certificate is used to verify the SIP identity header signature.
** The certificate chain of trust is verified.
* The verification service returns the result to the terminating service provider's Softswitch or SBC.
* The call is completed to the called party.

== SIP identity header example ==
The following is an example SIP INVITE message with an identity header.
<pre>
INVITE sip:18001234567@example.com:5060 SIP/2.0
Via: SIP/2.0/UDP example.com:5060
From: "Alice" <sip:14045266060@5.6.7.8:5060>;tag=123456789
To: "Bob" <sip:18001234567@1.2.3.4:5060>
Call-ID: 1-12345@5.6.7.8
CSeq: 1 INVITE
Max-Forwards: 70
Identity: eyJhbGciOiAiRVMyNTYiLCJwcHQiOiAic2hha2VuIiwidHlwIjogInBhc3Nwb3J0IiwieDV1IjogImh0dHBzOi8vY2VydGlmaWNhdGVzLmNsZWFyaXAuY29tL2IxNWQ3Y2M5LTBmMjYtNDZjMi04M2VhLWEzZTYzYTgyZWMzYS83Y2M0ZGI2OTVkMTNlZGFkYTRkMWY5ODYxYjliODBmZS5jcnQifQ.eyJhdHRlc3QiOiAiQSIsImRlc3QiOiB7InRuIjogWyIxNDA0NTI2NjA2MCJdfSwiaWF0IjogMTU0ODg1OTk4Miwib3JpZyI6IHsidG4iOiAiMTgwMDEyMzQ1NjcifSwib3JpZ2lkIjogIjNhNDdjYTIzLWQ3YWItNDQ2Yi04MjFkLTMzZDVkZWVkYmVkNCJ9.S_vqkgCk88ee9rtk89P6a6ru0ncDfSrdb1GyK_mJj-10hsLW-dMF7eCjDYARLR7EZSZwiu0fd4H_QD_9Z5U2bg;info=<https://certificates.clearip.com/b15d7cc9-0f26-46c2-83ea-a3e63a82ec3a/7cc4db695d13edada4d1f9861b9b80fe.crt>alg=ES256;ppt=shaken
</pre>

== Validation ==
It is not easy to validate the stir/shaken without third parties.

Test numbers. These numbers are playing back the received attestation level of the call.
* +1 202 539 1419
* +1 302 257 7304

Also, the IDT Express provides STIR/SHAKEN test tool.
* https://www.idtexpress.com/tools/stir-shaken-tool/

== See also ==
* Understanding STIR/SHAKEN - https://transnexus.com/whitepapers/understanding-stir-shaken/

[[category:Telephony]]

STIR/SHAKEN

2023-08-02T14:38:56Z

Pchero: /* Validation */

== Overview ==
STIR/SHAKEN 내용 정리.

== STIR/SHAKEN ==
The Federal Communications Commission(FCC) has been encouraging the telecommunications industry to develop a solution to stop robocalls and spoofed calling numbers since 2014. The industry's response has been to develop a new technology standard called STIR(Secure Telephony Identity Revisited) and SHAKEN(Secure Handling of Asserted information using toKENs) which defines how telephone service providers should implement the STIR technology to ensure calling numbers are not spoofed.

== How STIR/SHAKEN works ==
STIR/SHAKEN uses digital certificates, based on common public key cryptography techniques, to ensure the calling number of a telephone call is secure. In simple terms, each telephone service provider obtains their digital certificate from a certificate authority who is trusted by other telephone service providers. The certificate technology enables the called party to verify that the calling number is accurate and has not been spoofed.

* A SIP INVITE is received by the originating telephone service provider.
* The originating telephone service provider checks the call source and calling number to determine how to attest for the validity of the calling number.
** Full Attestation(A): The service provider has authenticated the calling party and they are authorized to use the calling number. An example of this case is a subscriber registered with the originating telephone service provider's software.
** Partial Attestation(B): The service provider has authenticated the call origination, but cannot verify the call source is authorized to use the calling number. An example of this use case is a telephone number behind an enterprise PBX.
** Gateway Attestation(C): The service provider has authenticated from where it received the call, but cannot authenticate the call source. An example of this case would be a call received from an international gateway.
* The originating telephone service provider uses the authentication service to create a SIP identity header. The authentication service could be a third-party service hosted in the cloud software application integrated with the telephone service provider's Softswitch or Session Border Controller(SBC). The SIP identity header contains the following data.
** Calling number
** Called number(s)
** Current timestamp
** Attestation level
** Origination identifier
* The SIP INVITE with the SIP identity header is sent to the terminating telephone service provider. In addition, the identity token may be sent across the internet, around non-SIP call segments, using Out-of-Band SHAKEN.
* The SIP INVITE with identity header is passed to the verification service.
* The verification service obtains the digital certificate of the originating telephone service provider from the public certificate repository and begins a multi-step verification process. If all verification steps are successful, then the calling number has not been spoofed.
** The SIP identity header is base64 URL decoded and the details are compared to the SIP INVITE message.
** The public key of the certificate is used to verify the SIP identity header signature.
** The certificate chain of trust is verified.
* The verification service returns the result to the terminating service provider's Softswitch or SBC.
* The call is completed to the called party.

== SIP identity header example ==
The following is an example SIP INVITE message with an identity header.
<pre>
INVITE sip:18001234567@example.com:5060 SIP/2.0
Via: SIP/2.0/UDP example.com:5060
From: "Alice" <sip:14045266060@5.6.7.8:5060>;tag=123456789
To: "Bob" <sip:18001234567@1.2.3.4:5060>
Call-ID: 1-12345@5.6.7.8
CSeq: 1 INVITE
Max-Forwards: 70
Identity: eyJhbGciOiAiRVMyNTYiLCJwcHQiOiAic2hha2VuIiwidHlwIjogInBhc3Nwb3J0IiwieDV1IjogImh0dHBzOi8vY2VydGlmaWNhdGVzLmNsZWFyaXAuY29tL2IxNWQ3Y2M5LTBmMjYtNDZjMi04M2VhLWEzZTYzYTgyZWMzYS83Y2M0ZGI2OTVkMTNlZGFkYTRkMWY5ODYxYjliODBmZS5jcnQifQ.eyJhdHRlc3QiOiAiQSIsImRlc3QiOiB7InRuIjogWyIxNDA0NTI2NjA2MCJdfSwiaWF0IjogMTU0ODg1OTk4Miwib3JpZyI6IHsidG4iOiAiMTgwMDEyMzQ1NjcifSwib3JpZ2lkIjogIjNhNDdjYTIzLWQ3YWItNDQ2Yi04MjFkLTMzZDVkZWVkYmVkNCJ9.S_vqkgCk88ee9rtk89P6a6ru0ncDfSrdb1GyK_mJj-10hsLW-dMF7eCjDYARLR7EZSZwiu0fd4H_QD_9Z5U2bg;info=<https://certificates.clearip.com/b15d7cc9-0f26-46c2-83ea-a3e63a82ec3a/7cc4db695d13edada4d1f9861b9b80fe.crt>alg=ES256;ppt=shaken
</pre>

== Validation ==
It is not easy to validate the stir/shaken without third parties.

Test numbers. These numbers are playing back the received attestation level of the call.
* +1 202 539 1419
* +1 302 257 7304

Also, the IDT provides STIR/SHAKEN test tool.
* https://www.idtexpress.com/tools/stir-shaken-tool/

== See also ==
* Understanding STIR/SHAKEN - https://transnexus.com/whitepapers/understanding-stir-shaken/

[[category:Telephony]]

STIR/SHAKEN

2023-08-02T14:38:40Z

Pchero: /* See also */

== Overview ==
STIR/SHAKEN 내용 정리.

== STIR/SHAKEN ==
The Federal Communications Commission(FCC) has been encouraging the telecommunications industry to develop a solution to stop robocalls and spoofed calling numbers since 2014. The industry's response has been to develop a new technology standard called STIR(Secure Telephony Identity Revisited) and SHAKEN(Secure Handling of Asserted information using toKENs) which defines how telephone service providers should implement the STIR technology to ensure calling numbers are not spoofed.

== How STIR/SHAKEN works ==
STIR/SHAKEN uses digital certificates, based on common public key cryptography techniques, to ensure the calling number of a telephone call is secure. In simple terms, each telephone service provider obtains their digital certificate from a certificate authority who is trusted by other telephone service providers. The certificate technology enables the called party to verify that the calling number is accurate and has not been spoofed.

* A SIP INVITE is received by the originating telephone service provider.
* The originating telephone service provider checks the call source and calling number to determine how to attest for the validity of the calling number.
** Full Attestation(A): The service provider has authenticated the calling party and they are authorized to use the calling number. An example of this case is a subscriber registered with the originating telephone service provider's software.
** Partial Attestation(B): The service provider has authenticated the call origination, but cannot verify the call source is authorized to use the calling number. An example of this use case is a telephone number behind an enterprise PBX.
** Gateway Attestation(C): The service provider has authenticated from where it received the call, but cannot authenticate the call source. An example of this case would be a call received from an international gateway.
* The originating telephone service provider uses the authentication service to create a SIP identity header. The authentication service could be a third-party service hosted in the cloud software application integrated with the telephone service provider's Softswitch or Session Border Controller(SBC). The SIP identity header contains the following data.
** Calling number
** Called number(s)
** Current timestamp
** Attestation level
** Origination identifier
* The SIP INVITE with the SIP identity header is sent to the terminating telephone service provider. In addition, the identity token may be sent across the internet, around non-SIP call segments, using Out-of-Band SHAKEN.
* The SIP INVITE with identity header is passed to the verification service.
* The verification service obtains the digital certificate of the originating telephone service provider from the public certificate repository and begins a multi-step verification process. If all verification steps are successful, then the calling number has not been spoofed.
** The SIP identity header is base64 URL decoded and the details are compared to the SIP INVITE message.
** The public key of the certificate is used to verify the SIP identity header signature.
** The certificate chain of trust is verified.
* The verification service returns the result to the terminating service provider's Softswitch or SBC.
* The call is completed to the called party.

== SIP identity header example ==
The following is an example SIP INVITE message with an identity header.
<pre>
INVITE sip:18001234567@example.com:5060 SIP/2.0
Via: SIP/2.0/UDP example.com:5060
From: "Alice" <sip:14045266060@5.6.7.8:5060>;tag=123456789
To: "Bob" <sip:18001234567@1.2.3.4:5060>
Call-ID: 1-12345@5.6.7.8
CSeq: 1 INVITE
Max-Forwards: 70
Identity: eyJhbGciOiAiRVMyNTYiLCJwcHQiOiAic2hha2VuIiwidHlwIjogInBhc3Nwb3J0IiwieDV1IjogImh0dHBzOi8vY2VydGlmaWNhdGVzLmNsZWFyaXAuY29tL2IxNWQ3Y2M5LTBmMjYtNDZjMi04M2VhLWEzZTYzYTgyZWMzYS83Y2M0ZGI2OTVkMTNlZGFkYTRkMWY5ODYxYjliODBmZS5jcnQifQ.eyJhdHRlc3QiOiAiQSIsImRlc3QiOiB7InRuIjogWyIxNDA0NTI2NjA2MCJdfSwiaWF0IjogMTU0ODg1OTk4Miwib3JpZyI6IHsidG4iOiAiMTgwMDEyMzQ1NjcifSwib3JpZ2lkIjogIjNhNDdjYTIzLWQ3YWItNDQ2Yi04MjFkLTMzZDVkZWVkYmVkNCJ9.S_vqkgCk88ee9rtk89P6a6ru0ncDfSrdb1GyK_mJj-10hsLW-dMF7eCjDYARLR7EZSZwiu0fd4H_QD_9Z5U2bg;info=<https://certificates.clearip.com/b15d7cc9-0f26-46c2-83ea-a3e63a82ec3a/7cc4db695d13edada4d1f9861b9b80fe.crt>alg=ES256;ppt=shaken
</pre>

== Validation ==
It is not easy to validate the stir/shaken without third parties.

Test numbers. These numbers are playing back the received attestation level of the call.
* +1 202 539 1419
* +1 302 257 7304

Also, the IDT provides STIR/SHAKEN test tool.
https://www.idtexpress.com/tools/stir-shaken-tool/

== See also ==
* Understanding STIR/SHAKEN - https://transnexus.com/whitepapers/understanding-stir-shaken/

[[category:Telephony]]

Asterisk ari-event

2023-07-27T03:22:53Z

Pchero: /* ChannelStateChange */

== Overview ==
Asterisk ARI event 내용 정리

== Channel ==
A specific communication connection between Asterisk and an Endpoint.
<pre>
{
  "properties": {
    "accountcode": {
      "required": true,
      "type": "string"
    },
    "name": {
      "required": true,
      "type": "string",
      "description": "Name of the channel (i.e. SIP/foo-0000a7e3)"
    },
    "language": {
      "required": true,
      "type": "string",
      "description": "The default spoken language"
    },
    "channelvars": {
      "required": false,
      "type": "object",
      "description": "Channel variables"
    },
    "caller": {
      "required": true,
      "type": "CallerID"
    },
    "creationtime": {
      "required": true,
      "type": "Date",
      "description": "Timestamp when channel was created"
    },
    "state": {
      "allowableValues": {
        "valueType": "LIST",
        "values": [
          "Down",
          "Rsrved",
          "OffHook",
          "Dialing",
          "Ring",
          "Ringing",
          "Up",
          "Busy",
          "Dialing Offhook",
          "Pre-ring",
          "Unknown"
        ]
      },
      "required": true,
      "type": "string"
    },
    "connected": {
      "required": true,
      "type": "CallerID"
    },
    "dialplan": {
      "required": true,
      "type": "DialplanCEP",
      "description": "Current location in the dialplan"
    },
    "id": {
      "required": true,
      "type": "string",
      "description": "Unique identifier of the channel.\n\nThis is the same as the Uniqueid field in AMI."
    }
  },
  "id": "Channel",
  "description": "A specific communication connection between Asterisk and an Endpoint."
}
</pre>
* accountcode: string
* caller: CallerID
* channelvars: object(optional): Channel variables
* connected: CallerID
* creationtime: Date: Timestamp when channel was created.
* dialplan: DialplanCEP: Current location in the dialplan.
* id: string: Unique identifier of the channel.
: This is the same as the Uniqueid filed in AMI

== BridgeCreated ==

=== Example ===
<pre>
{
"type": "BridgeCreated",
"timestamp": "2019-03-19T16:48:54.251+0000",
"bridge": {
"id": "1b98c21c-98f5-41cc-8fa0-1981bc380501",
"technology": "simple_bridge",
"bridge_type": "mixing",
"bridge_class": "stasis",
"creator": "Stasis",
"name": "",
"channels": [],
"video_mode": "none"
},
"asterisk_id": "42:01:0a:12:32:12",
"application": "test"
}
</pre>

== BridgeDestroyed ==
<pre>
{
"type": "BridgeDestroyed",
"timestamp": "2019-03-19T17:00:36.477+0000",
"bridge": {
"id": "1209eb30-5823-49b2-b582-a3100e667eb2",
"technology": "simple_bridge",
"bridge_type": "mixing",
"bridge_class": "stasis",
"creator": "Stasis",
"name": "",
"channels": [],
"video_mode": "talker"
},
"asterisk_id": "42:01:0a:84:12:21",
"application": "test"
}
</pre>

== ChannelCallerId ==
Base type: Event

Channel changed Caller ID.
<pre>
{
  "properties": {
    "caller_presentation_txt": {
      "required": true,
      "type": "string",
      "description": "The text representation of the Caller Presentation value."
    },
    "caller_presentation": {
      "required": true,
      "type": "int",
      "description": "The integer representation of the Caller Presentation value."
    },
    "channel": {
      "required": true,
      "type": "Channel",
      "description": "The channel that changed Caller ID."
    }
  },
  "id": "ChannelCallerId",
  "description": "Channel changed Caller ID."
}
</pre>
* asterisk_id: string(optional) : The unique ID for the Asterisk instance that raised this event.
* type: string : Indicates the type of this message.
* application: string : Name of the application receiving the event.
* timestamp: Date(optional) : Time at which this event was created.
* caller_presentation: int : The integer representation of the Caller Presentation value.
* caller_presentation_txt: string : The text representation of the Caller Presentation value.
* channel: [[#Channel|Channel]] : The channel that changed Caller ID.

=== Example ===
<pre>
{
"type": "ChannelCallerId",
"timestamp": "2019-03-10T20:44:47.240+0000",
"caller_presentation": 0,
"caller_presentation_txt": "Presentation Allowed, Not Screened",
"channel": {
"id": "1552250684.286164",
"name": "PJSIP/pchero-voip-siptrunking-0f922f18",
"state": "Ring",
"caller": {
"name": "",
"number": "test_caller"
},
"connected": {
"name": "",
"number": ""
},
"accountcode": "",
"dialplan": {
"context": "pchero-voip-siptrunking",
"exten": "test_call",
"priority": 2
},
"creationtime": "2019-03-10T20:44:44.835+0000",
"language": "en"
},
"asterisk_id": "42:01:0a:94:00:11",
"application": "pchero_voip"
}
</pre>

== ChannelConnectedLine ==
Channel changed Connected LIne.
<pre>
{
  "properties": {
    "channel": {
      "required": true,
      "type": "Channel",
      "description": "The channel whose connected line has changed."
    }
  },
  "id": "ChannelConnectedLine",
  "description": "Channel changed Connected Line."
}
</pre>
* asterisk_id: string(optional): The unique ID for the Asterisk instance that raised this event.
* type: string: Indicates the type of this message.
* application: string: Name of the application receiving the event.
* timestamp: Date: Time at which this evvent was created.
* channel: [[#Channel|Channel]]

=== Example ===
<pre>
{
"type": "ChannelConnectedLine",
"timestamp": "2019-12-11T12:28:41.318+0000",
"channel": {
"id": "e64d6d31-6f09-4b3d-b80a-7eb62d1a1d47",
"name": "PJSIP/pchero-voip-00224c0b",
"state": "Down",
"caller": {
"name": "",
"number": ""
},
"connected": {
"name": "anonymous",
"number": ""
},
"accountcode": "",
"dialplan": {
"context": "pchero-voip",
"exten": "s",
"priority": 1,
"app_name": "Stasis",
"app_data": "pchero_voip,DIALED=1"
},
"creationtime": "2019-12-11T12:28:41.111+0000",
"language": "en"
},
"asterisk_id": "42:01:0a:84:00:b6",
"application": "pchero_voip"
}
</pre>

== ChannelCreated ==
Base type: Event

Notification that a channel has been created.
<pre>
{
  "properties": {
    "channel": {
      "required": true,
      "type": "Channel"
    }
  },
  "id": "ChannelCreated",
  "description": "Notification that a channel has been created."
}
</pre>
* asterisk_id: string(optional) : The unique ID for the Asterisk instance that raised this event.
* type : string : Indicates the type of this message.
* application : string : Name of the application receiving the event.
* timestamp : Date(optional) : Time at which this event was created.
* channel : [[#Channel|Channel]]

=== Example ===
<pre>
{
"type": "ChannelCreated",
"timestamp": "2019-03-06T23:47:09.077+0100",
"channel": {
"id": "test_call",
"name": "PJSIP/sipp-uac-00000000",
"state": "Down",
"caller": {
"name": "",
"number": ""
},
"connected": {
"name": "",
"number": ""
},
"accountcode": "",
"dialplan": {
"context": "sipp-uac",
"exten": "s",
"priority": 1
},
"creationtime": "2019-03-06T23:47:09.058+0100",
"language": "en"
},
"asterisk_id": "00:11:22:33:44:55",
"application": "test"
}
</pre>

== ChannelDestroyed ==
Base type: Event

Notification that a channel has been destroyed.
<pre>
{
  "properties": {
    "cause": {
      "required": true,
      "type": "int",
      "description": "Integer representation of the cause of the hangup"
    },
    "cause_txt": {
      "required": true,
      "type": "string",
      "description": "Text representation of the cause of the hangup"
    },
    "channel": {
      "required": true,
      "type": "Channel"
    }
  },
  "id": "ChannelDestroyed",
  "description": "Notification that a channel has been destroyed."
}
</pre>
* asetrisk_id: string(optional): The unique ID for the Asterisk instance that raised this event.
* type: string: Indicates the type of this message.
* application: string: Name of the application receiving the event.
* timestamp: Date(optional): Time at which this event was created.
* cause: int: Integer representation of the cause of the hangup. [[Asterisk_hangup_code]]
* cause_txt: string: Text representation of the cause of the hangup.
* channel: [[#Channel|Channel]]

=== Example ===
<pre>
{
"type": "ChannelDestroyed",
"timestamp": "2018-10-23T12:36:11.110+0000",
"cause": 0,
"cause_txt": "Unknown",
"channel": {
"id": "pchero-462475.572686",
"name": "PJSIP/pchero-voip-00001b1f",
"state": "Up",
"caller": {
"name": "",
"number": "1337"
},
"connected": {
"name": "",
"number": "1337"
},
"accountcode": "",
"dialplan": {
"context": "pchero-voip",
"exten": "s",
"priority": 2
},
"creationtime": "2018-10-23T12:36:02.671+0000",
"language": "en"
},
"asterisk_id": "210445d7-73bd-456a-aef2-e0ef847bfa0f",
"application": "pchero_voip"
}
</pre>

== ChannelDialplan ==
Base type: Event

Channel changed location in the dialplan.
<pre>
{
  "properties": {
    "dialplan_app_data": {
      "required": true,
      "type": "string",
      "description": "The data to be passed to the application."
    },
    "channel": {
      "required": true,
      "type": "Channel",
      "description": "The channel that changed dialplan location."
    },
    "dialplan_app": {
      "required": true,
      "type": "string",
      "description": "The application about to be executed."
    }
  },
  "id": "ChannelDialplan",
  "description": "Channel changed location in the dialplan."
}
</pre>
* asterisk_id: string(optional): The unique ID for the Asterisk instance that raised this event.
* type: string: Indicates the type of this message.
* application: string: Name of the application receiving the event.
* timestamp: Date(optional): Time at which this event was created.
* channel: [[#Channel|Channel]]: The channel that changed dialplan location.
* dialplan_app: string: The application about to be executed.
* dialplan_app_data: string: The data to be passed to the application.

=== Example ===
<pre>
{
"type": "ChannelDialplan",
"timestamp": "2018-10-23T12:36:11.109+0000",
"dialplan_app": "AppDial2",
"dialplan_app_data": "(Outgoing Line)",
"channel": {
"id": "pchero-462475.572686",
"name": "PJSIP/pchero-voip-00001b1f",
"state": "Up",
"caller": {
"name": "",
"number": "1337"
},
"connected": {
"name": "",
"number": "1337"
},
"accountcode": "",
"dialplan": {
"context": "pchero-voip",
"exten": "s",
"priority": 2
},
"creationtime": "2018-10-23T12:36:02.671+0000",
"language": "en"
},
"asterisk_id": "210445d7-73bd-456a-aef2-e0ef847bfa0f",
"application": "pchero_voip"
}
</pre>

== ChannelDtmfReceived ==
=== Example ===
<pre>
{
"type": "ChannelDtmfReceived",
"timestamp": "2020-05-20T06:40:45.663+0000",
"digit": "9",
"duration_ms": 100,
"channel": {
"id": "1589956827.6285",
"name": "PJSIP/call-in-00000633",
"state": "Up",
"caller": {
"name": "tttt",
"number": "pchero"
},
"connected": {
"name": "",
"number": ""
},
"accountcode": "",
"dialplan": {
"context": "call-in",
"exten": "9912321321",
"priority": 2,
"app_name": "Stasis",
"app_data": "voipbin"
},
"creationtime": "2020-05-20T06:40:27.599+0000",
"language": "en"
},
"asterisk_id": "42:01:0a:a4:00:05",
"application": "voipbin"
}

</pre>

== ChannelEnteredBridge ==
=== Example ===
<pre>
{
"type": "ChannelEnteredBridge",
"timestamp": "2019-03-19T16:48:54.265+0000",
"bridge": {
"id": "1b98c21c-98f5-41cc-8fa0-1981bc380501",
"technology": "simple_bridge",
"bridge_type": "mixing",
"bridge_class": "stasis",
"creator": "Stasis",
"name": "",
"channels": ["d3137253-7118-418c-80f3-1595fbcd75b0"],
"video_mode": "talker"
},
"channel": {
"id": "d3137253-7118-418c-80f3-1595fbcd75b0",
"name": "PJSIP/pchero-voip-00000010",
"state": "Up",
"caller": {
"name": "",
"number": "test"
},
"connected": {
"name": "",
"number": "test"
},
"accountcode": "",
"dialplan": {
"context": "pchero-voip",
"exten": "s",
"priority": 1
},
"creationtime": "2019-03-19T16:48:45.352+0000",
"language": "en"
},
"asterisk_id": "42:01:0a:84:12:32",
"application": "test"
}
</pre>

== ChannelHangupRequest ==
Base type: Event

A hangup was requested on the channel.

ChannelHangupRequest 에는 몇 가지 의미가 있다.

Soft 가 true 로 설정되었을 때는, Hangup() application 이 실행되었거나, Dialplan 에서의 h extension 이 실행되었을 경우 발생한다. h extension 은 명시적으로 지정될 수 도 있고, 묵시적으로 실행이 될 수 있다. 따라서 한번 Dailplan 으로 인입된 Channel 이 종료될 때는 이 이벤트를 발생시킨다.

Soft 가 false 이거나 설정되어 있지 않는 경우는, Hangup Request 를 명시적으로 받았음을 의미한다. ```channel hangup request``` 명령어나 상대방쪽에서 BYE 메시지를 먼저 보냈을 경우가 이에 해당한다.

하지만 뭔가 규칙이 일정하지 않다. ARI 에서 ChannelHangupRequest 이벤트를 사용하고자 할 때는 주의가 필요하다.
<pre>
{
  "properties": {
    "soft": {
      "type": "boolean",
      "description": "Whether the hangup request was a soft hangup request."
    },
    "cause": {
      "type": "int",
      "description": "Integer representation of the cause of the hangup."
    },
    "channel": {
      "required": true,
      "type": "Channel",
      "description": "The channel on which the hangup was requested."
    }
  },
  "id": "ChannelHangupRequest",
  "description": "A hangup was requested on the channel."
}
</pre>
* asterisk_id: string (optional) - The unique ID for the Asterisk instance that raised this event.
* type: string - Indicates the type of this message.
* application: string - Name of the application receiving the event.
* timestamp: Date(optional) - Time at which this event was created.
* cause: int(optional) - Integer representation of the cause of the hangup. [[Asterisk_hangup_code]]
* channel: Channel - The channel on which the hangup was requested.
* soft: boolean(optional) - Whether the hangup request was a soft hangup request.

=== Example ===
<pre>
{
"cause": 32,
"soft": true,
"type": "ChannelHangupRequest",
"timestamp": "2018-12-02T22:11:29.118+0100",
"channel": {
"id": "1543785048.30",
"name": "PJSIP/sippuas-0000000f",
"state": "Up",
"caller": {
"name": "",
"number": ""
},
"connected": {
"name": "",
"number": ""
},
"accountcode": "",
"dialplan": {
"context": "sippuas",
"exten": "s",
"priority": 1
},
"creationtime": "2018-12-02T22:10:48.176+0100",
"language": "en"
},
"asterisk_id": "08:00:27:2f:9e:d4",
"application": "test"
}
</pre>

== ChannelLeftBridge ==
=== Example ===
<pre>
{
"type": "ChannelLeftBridge",
"timestamp": "2019-03-19T16:49:09.571+0000",
"bridge": {
"id": "1b98c21c-98f5-41cc-8fa0-1981bc380501",
"technology": "simple_bridge",
"bridge_type": "mixing",
"bridge_class": "stasis",
"creator": "Stasis",
"name": "",
"channels": [],
"video_mode": "talker"
},
"channel": {
"id": "d3137253-7118-418c-80f3-1595fbcd75b0",
"name": "PJSIP/pchero-voip-00000010",
"state": "Up",
"caller": {
"name": "",
"number": "test"
},
"connected": {
"name": "",
"number": ""
},
"accountcode": "",
"dialplan": {
"context": "pchero-voip",
"exten": "s",
"priority": 1
},
"creationtime": "2019-03-19T16:48:45.352+0000",
"language": "en"
},
"asterisk_id": "42:01:0a:84:23:12",
"application": "test"
}
</pre>

== ChannelStateChange ==
Base type: Event

Notification of a channel's state change
<pre>
{
  "properties": {
    "channel": {
      "required": true,
      "type": "Channel"
    }
  },
  "id": "ChannelStateChange",
  "description": "Notification of a channel's state change."
}
</pre>
* asterisk_id: string(optional): The unique ID for the Asterisk instance that raised this event.
* type: string: Indicates the type of this message.
* application: string: Name of the application receiving the event.
* timestamp: Date(optional): Time at which this event was created.
* channel: [[#Channel|Channel]]

=== Example ===
<pre>
{
"type": "ChannelStateChange",
"timestamp": "2018-10-23T12:36:07.628+0000",
"channel": {
"id": "pchero-462475.572686",
"name": "PJSIP/pchero-voip-00001b1f",
"state": "Ringing",
"caller": {
"name": "",
"number": "1337"
},
"connected": {
"name": "",
"number": "1337"
},
"accountcode": "",
"dialplan": {
"context": "pchero-voip",
"exten": "s",
"priority": 1
},
"creationtime": "2018-10-23T12:36:02.671+0000",
"language": "en"
},
"asterisk_id": "210445d7-73bd-456a-aef2-e0ef847bfa0f",
"application": "pchero_voip"
}
</pre>

== ChannelTalkingStarted ==
=== Example ===
<pre>
{
"application": "sdp",
"asterisk_id": "42:01:0a:4b:00:36",
"type": "ChannelTalkingStarted",
"timestamp": "2023-07-27T03:04:30.241+0000",
"channel": {
"state": "Up",
"connected": {
"name": "Dev Test",
"number": "+1123"
},
"name": "PJSIP/registries-0000006f",
"language": "en",
"caller": {
"number": "+1123",
"name": "Dev Test"
},
"id": "1690426949.1707",
"creationtime": "2023-07-27T03:02:29.556+0000",
"accountcode": "",
"dialplan": {
"exten": "s",
"app_data": "sdp,context=register-incoming",
"priority": 4,
"app_name": "Stasis",
"context": "common"
}
}
}
</pre>

== ChannelTalkingFinished ==
=== Example ===
<pre>
{
"channel": {
"accountcode": "",
"language": "en",
"connected": {
"number": "+1123",
"name": "Dev Test"
},
"name": "PJSIP/registries-0000006f",
"id": "1690426949.1707",
"caller": {
"number": "+1123",
"name": "Dev Test"
},
"creationtime": "2023-07-27T03:02:29.556+0000",
"state": "Up",
"dialplan": {
"app_data": "sdp,context=register-incoming",
"app_name": "Stasis",
"priority": 4,
"exten": "s",
"context": "common"
}
},
"application": "sdp",
"timestamp": "2023-07-27T03:05:15.581+0000",
"duration": 42839,
"asterisk_id": "42:01:0a:4b:00:36",
"type": "ChannelTalkingFinished"
}
</pre>

== ChannelVarset ==
Base type: Event

Channel variable changed
<pre>
{
  "properties": {
    "variable": {
      "required": true,
      "type": "string",
      "description": "The variable that changed."
    },
    "channel": {
      "required": false,
      "type": "Channel",
      "description": "The channel on which the variable was set.\n\nIf missing, the variable is a global variable."
    },
    "value": {
      "required": true,
      "type": "string",
      "description": "The new value of the variable."
    }
  },
  "id": "ChannelVarset",
  "description": "Channel variable changed."
}
</pre>
* asterisk_id: string(optional): The unique ID for the Asterisk instance that raised this event.
* type: string: Indicates the type of this message.
* application: string: Name of the application receiving the event.
* timestamp: Date(optional): Time at which this event was created.
* channel: [[#Channel|Channel]](optional): The channel on which the variable was set.
: If missing, the variable is a global variable.

=== Example ===
<pre>
{
"variable": "STASISSTATUS",
"value": "",
"type": "ChannelVarset",
"timestamp": "2018-10-23T12:36:09.602+0000",
"channel": {
"id": "pchero-462475.572686",
"name": "PJSIP/pchero-voip-00001b1f",
"state": "Up",
"caller": {
"name": "",
"number": "1337"
},
"connected": {
"name": "",
"number": "1337"
},
"accountcode": "",
"dialplan": {
"context": "pchero-voip",
"exten": "s",
"priority": 1
},
"creationtime": "2018-10-23T12:36:02.671+0000",
"language": "en"
},
"asterisk_id": "210445d7-73bd-456a-aef2-e0ef847bfa0f",
"application": "pchero_voip"
}
</pre>

== DeviceStateChanged ==
Represents the state of a device.
<pre>
{
  "properties": {
    "state": {
      "allowableValues": {
        "valueType": "LIST",
        "values": [
          "UNKNOWN",
          "NOT_INUSE",
          "INUSE",
          "BUSY",
          "INVALID",
          "UNAVAILABLE",
          "RINGING",
          "RINGINUSE",
          "ONHOLD"
        ]
      },
      "required": true,
      "type": "string",
      "description": "Device's state"
    },
    "name": {
      "required": true,
      "type": "string",
      "description": "Name of the device."
    }
  },
  "id": "DeviceState",
  "description": "Represents the state of a device."
}
</pre>
* name: string - Name of the device.
* state: string - Device's state.

=== Example ===
<pre>
{
"type": "DeviceStateChanged",
"application": "test",
"timestamp": "2018-12-02T22:11:29.121+0100",
"device_state": {
"name": "PJSIP/sippuas",
"state": "NOT_INUSE"
},
"asterisk_id": "08:00:27:2f:9e:d4"
}
</pre>

== Dial ==
Base type: Event

Dialing state has changed.
<pre>
{
  "properties": {
    "forwarded": {
      "required": false,
      "type": "Channel",
      "description": "Channel that the caller has been forwarded to."
    },
    "caller": {
      "required": false,
      "type": "Channel",
      "description": "The calling channel."
    },
    "dialstatus": {
      "required": true,
      "type": "string",
      "description": "Current status of the dialing attempt to the peer."
    },
    "forward": {
      "required": false,
      "type": "string",
      "description": "Forwarding target requested by the original dialed channel."
    },
    "dialstring": {
      "required": false,
      "type": "string",
      "description": "The dial string for calling the peer channel."
    },
    "peer": {
      "required": true,
      "type": "Channel",
      "description": "The dialed channel."
    }
  },
  "id": "Dial",
  "description": "Dialing state has changed."
}
</pre>
* asterisk_id: string(optional): The unique ID for the Asterisk instance that raised this event.
* type: string: Indicates the type of this message.
* application: string: Name of the application receiving the event.
* timestamp: Date(optional): Time at which this event was created.
* caller: Channel(optional): The calling channel
* dialstatus: string: Current status of the dialing attempt to the peer.
** <empty> : The dialing has begun
* dialstring: string(optional): The dial string for calling the peer channel.
* forward: string(optional): Forwarding target requested by the original dialed channel.
* forwarded: Channel(optional): Channel that the caller has been forwared to.
* peer: [[#Channel|Channel]]: The dialed channel.

The ARI's Dial event has some different scope compare with AMI's event.
<pre>
2016-05-09 15:00 +0000 [205a31f86c] Mark Michelson <mmichelson@digium.com>

* Expand the scope of Dial Events

Dial events up to this point have come in two flavors
* A Dial event with no status to indicate that dialing has begun
* A Dial event with a status to indicate that dialing has ended

With this change, Dial events have been expanded to also give
intermediate events, such as "RINGING", "PROCEEDING", and "PROGRESS".
This is especially useful for ARI dialing, as it gives the application
writer the opportunity to place a channel into an early bridge when
early media is detected.

AMI handles these in-progress dial events by sending a new event called
"DialState" that simply indicates that dial state has changed but has
not ended. ARI never distinguished between DialBegin and DialEnd, so no
change was made to the event itself.

Another change here relates to dial forwards. A forward-related event
was previously only sent when a channel was successfully able to forward
a call to a new channel. With this set of changes, if forwarding is
blocked, we send a Dial event with a forwarding destination but no
forwarding channel, since we were prevented from creating one. This is
again useful for ARI since application writers can now handle call
forward attempts from within their own application.

ASTERISK-25925 #close
Reported by Mark Michelson

Change-Id: I42cbec7730d84640a434d143a0d172a740995543
</pre>

=== Example ===
<pre>
{
"type": "Dial",
"timestamp": "2018-10-23T12:36:02.673+0000",
"dialstatus": "",
"forward": "",
"dialstring": "pchero-voip/sip:284712939482@127.0.0.1",
"peer": {
"id": "pchero-462475.572686",
"name": "PJSIP/pchero-voip-00001b1f",
"state": "Down",
"caller": {
"name": "",
"number": "1337"
},
"connected": {
"name": "",
"number": "1337"
},
"accountcode": "",
"dialplan": {
"context": "pchero-voip",
"exten": "s",
"priority": 1
},
"creationtime": "2018-10-23T12:36:02.671+0000",
"language": "en"
},
"asterisk_id": "210445d7-73bd-456a-aef2-e0ef847bfa0f",
"application": "pchero_voip"
}
</pre>

== Playback ==
Object representing the playback of media to a channel.

<pre>
{
  "properties": {
    "next_media_uri": {
      "required": false,
      "type": "string",
      "description": "If a list of URIs is being played, the next media URI to be played back."
    },
    "target_uri": {
      "required": true,
      "type": "string",
      "description": "URI for the channel or bridge to play the media on"
    },
    "language": {
      "type": "string",
      "description": "For media types that support multiple languages, the language requested for playback."
    },
    "state": {
      "allowableValues": {
        "valueType": "LIST",
        "values": [
          "queued",
          "playing",
          "continuing",
          "done"
        ]
      },
      "required": true,
      "type": "string",
      "description": "Current state of the playback operation."
    },
    "media_uri": {
      "required": true,
      "type": "string",
      "description": "The URI for the media currently being played back."
    },
    "id": {
      "required": true,
      "type": "string",
      "description": "ID for this playback operation"
    }
  },
  "id": "Playback",
  "description": "Object representing the playback of media to a channel"
}
</pre>
* id: string: ID for this playback operation.
* language: string(optional): For media types that support multiple languages, the language requested for playback.
* media_uri: string: The URI for the media currently being played back.
* next_media_uri: string(optional): If a list of URIs is being played, the next media URI to be played back.
* state: string: Current state of the playback operation.
* target_uri: string: URI for the channel or bridge to play the media on.

=== Example ===
<pre>
{
"id": "1b590cfa-5880-493f-8afc-3f9dfed9022a:3f59e78f-acb2-4bd4-bcd0-23da52c1a2c2",
"media_uri": "sound:https://pchero21.com/var/spool/asterisk/tts/test.wav",
"target_uri": "channel:pchero-462475.572686",
"language": "en",
"state": "playing"
}
</pre>

== PlaybackContinuing ==
Base type: Event

Event showing the continuation of a media playback operation from one media URI to the next in the list.
<pre>
{
  "properties": {
    "playback": {
      "required": true,
      "type": "Playback",
      "description": "Playback control object"
    }
  },
  "id": "PlaybackContinuing",
  "description": "Event showing the continuation of a media playback operation from one media URI to the next in the list."
}
</pre>
* asterisk_id: string(optional): The unique ID for the Asterisk instance that raised this event.
* type: string: Indicates the type of this message.
* application: string: Name of the application receiving the event.
* timestamp: Date(optional): Time at which this event was created.
* playback: Playback: Playback control object.

=== Example ===
<pre>
{
"type": "PlaybackContinuing",
"playback": {
"id": "5618648a-985c-4c81-a35e-32f6135b43b9",
"media_uri": "sound:https://github.com/pchero/asterisk_wavs/raw/master/pcm_samples/example_pcm16_mono_8k_short.wav",
"next_media_uri": "sound:https://github.com/pchero/asterisk_wavs/raw/master/pcm_samples/example_pcm16_mono_8k_short.wav",
"target_uri": "channel:test-call",
"language": "en",
"state": "continuing"
},
"asterisk_id": "42:01:0a:84:00:12",
"application": "pchero_voip"
}
</pre>

== PlaybackFinished ==
Base type: Event

Event showing the completion of a media playback operation.
<pre>
{
  "properties": {
    "playback": {
      "required": true,
      "type": "Playback",
      "description": "Playback control object"
    }
  },
  "id": "PlaybackFinished",
  "description": "Event showing the completion of a media playback operation."
}
</pre>
* asterisk_id: string(optional): The unique ID for the Asterisk instance that raised this event.
* type: string: Indicates the type of this message.
* application: string: Name of the application receiving the event.
* timestamp: Date(optional): Time at which this event was created.
* playback: Playback: Playback control object.

=== Example ===
<pre>
{
"type": "PlaybackFinished",
"timestamp": "2019-03-07T21:18:53.043+0100",
"playback": {
"id": "5b8ea8c2-bf67-4282-9c10-55ebf37a07c1",
"media_uri": "sound:https://github.com/pchero/asterisk-medias/raw/master/samples_codec/pcm_samples/example-mono_16bit_8khz_pcm.wav",
"target_uri": "channel:test_call",
"language": "en",
"state": "done"
},
"asterisk_id": "00:11:22:33:44:55",
"application": "test"
}
</pre>

== PlaybackStarted ==
Base type: Event

Event showing the start of a media playback operation.
<pre>
{
  "properties": {
    "playback": {
      "required": true,
      "type": "Playback",
      "description": "Playback control object"
    }
  },
  "id": "PlaybackStarted",
  "description": "Event showing the start of a media playback operation."
}
</pre>
* aserisk_id: string(optional): The unique ID for the Asterisk instance that raised this event.
* type: string: Indicates the type of this message.
* application: string: Name of the application receiving the event.
* timestamp: Date(optional): Time at which this event was created.
* playback: Playback: Playback control object.

=== Example ===
<pre>
{
"type": "PlaybackStarted",
"timestamp": "2019-03-07T21:17:56.241+0100",
"playback": {
"id": "5b8ea8c2-bf67-4282-9c10-55ebf37a07c1",
"media_uri": "sound:https://github.com/pchero/asterisk-medias/raw/master/samples_codec/pcm_samples/example-mono_16bit_8khz_pcm.wav",
"target_uri": "channel:test_call",
"language": "en",
"state": "playing"
},
"asterisk_id": "00:11:22:33:44:55",
"application": "test"
}
</pre>

== RecordingFinished ==
Event showing the completion of a recording operation.
<pre>
{
  "properties": {
    "recording": {
      "required": true,
      "type": "LiveRecording",
      "description": "Recording control object"
    }
  },
  "id": "RecordingFinished",
  "description": "Event showing the completion of a recording operation."
}
</pre>
* recording: LiveRecording - Recording control object.

=== Example ===
<pre>
{
"type": "RecordingFinished",
"timestamp": "2020-02-10T13:08:18.888+0000",
"recording": {
"name": "testrecording-202002101401",
"format": "wav",
"state": "done",
"target_uri": "bridge:e9946f5c-2632-4a92-a608-068994d27cbf",
"duration": 351
},
"asterisk_id": "42:01:0a:84:00:68",
"application": "hello-world"
}
</pre>

== RecordingStarted ==
Event showing the start of a recording operation.

=== Example ===
* Channel recording
<pre>
{
"type": "RecordingStarted",
"recording": {
"name": "test_call",
"format": "wav",
"state": "recording",
"target_uri": "channel:test_call"
},
"asterisk_id": "42:01:0a:84:00:12",
"application": "pchero"
}
</pre>

* Bridge recording
<pre>
{
"type": "RecordingStarted",
"timestamp": "2020-02-10T13:01:22.752+0000",
"recording": {
"name": "testrecording-202002101401",
"format": "wav",
"state": "recording",
"target_uri": "bridge:e9946f5c-2632-4a92-a608-068994d27cbf"
},
"asterisk_id": "42:01:0a:84:00:68",
"application": "hello-world"
}
</pre>

== StasisEnd ==
Bast type: Event

Notification that a channel has left a Stasis application.
<pre>
{
  "properties": {
    "channel": {
      "required": true,
      "type": "Channel"
    }
  },
  "id": "StasisEnd",
  "description": "Notification that a channel has left a Stasis application."
}
</pre>
* asterisk_id: string(optional): The unique ID for the Asterisk instance that raised this event.
* type: string: Indicates the type of this message.
* application: string: Name of the application receiving the event.
* timestamp: Date(Optional): Time at which this event was created.
* channel: [[#Channel|Channel]]

=== Example ===
<pre>
{
"type": "StasisEnd",
"timestamp": "2018-10-23T12:36:11.105+0000",
"channel": {
"id": "pchero-462475.572686",
"name": "PJSIP/pchero-voip-00001b1f",
"state": "Up",
"caller": {
"name": "",
"number": "1337"
},
"connected": {
"name": "",
"number": "1337"
},
"accountcode": "",
"dialplan": {
"context": "pchero-voip",
"exten": "s",
"priority": 2
},
"creationtime": "2018-10-23T12:36:02.671+0000",
"language": "en"
},
"asterisk_id": "210445d7-73bd-456a-aef2-e0ef847bfa0f",
"application": "pchero_voip"
}
</pre>

== StasisStart ==
Base type: Event

Notification that a channel has entered a Stasis application.
<pre>
{
  "properties": {
    "args": {
      "required": true,
      "type": "List[string]",
      "description": "Arguments to the application"
    },
    "replace_channel": {
      "required": false,
      "type": "Channel"
    },
    "channel": {
      "required": true,
      "type": "Channel"
    }
  },
  "id": "StasisStart",
  "description": "Notification that a channel has entered a Stasis application."
}
</pre>
* asterisk_id: string(optional): The unique ID for the Asterisk instance that raised this event.
* type: string: Indicates the type of this message.
* application: string: Name of the application receiving the event.
* timestamp: Date(optional): Time at which this event was created.
* args: List[string]: Arguments to the application.
* channel: [[#Channel|Channel]]
* replace_channel: [[#Channel|Channel]](optional)

=== Example ===
<pre>
{
"type": "StasisStart",
"timestamp": "2018-10-23T12:36:09.603+0000",
"args": ["PCHERO_DIALED=1"],
"channel": {
"id": "pchero-462475.572686",
"name": "PJSIP/pchero-voip-00001b1f",
"state": "Up",
"caller": {
"name": "",
"number": "1337"
},
"connected": {
"name": "",
"number": "1337"
},
"accountcode": "",
"dialplan": {
"context": "pchero-voip",
"exten": "s",
"priority": 1
},
"creationtime": "2018-10-23T12:36:02.671+0000",
"language": "en"
},
"asterisk_id": "210445d7-73bd-456a-aef2-e0ef847bfa0f",
"application": "pchero_voip"
}
</pre>

== See also ==
* https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+REST+Data+Models
* https://wiki.asterisk.org/wiki/display/AST/Asterisk+17+REST+Data+Models

[[category:asterisk]]

Company info

2023-07-06T13:33:30Z

Pchero: /* International */

== Overview ==
관심있는 회사 정보 정리.

* http://worldvoipproviders.com/countries/
: 전 세계의 voip 관련 기업 모음

== Belgium ==
=== Voxbone ===
* https://www.voxbone.com/
: Asterisk gerrit 코드 커밋으로 알게됨. 벨기에 주재 IP communication 회사.

== Bulgaria ==
=== Zoiper ===
* https://www.zoiper.com

== Canada ==
=== AllStream ===
* https://allstream.com/
* Asterisk IRC 로 알게됨.

=== Jive ===
* https://jive.com/
* 대기업. 사원수가 많음.

=== Wazo ===
* http://wazo.community
* Asterisk-amqp 관련 자료를 찾다가 발견함. Astricon2017 에서 발표한 내용이 있음.

=== Textnow ===
* http://textnow.com

== China ==
=== Hiastar ===
* http://www.hiastar.com/

== Denmark ==
=== Dixa ===
* https://www.dixa.com/
* Denmark
Telephony, Live chat, Virtual Service Assistant 등의 통합 시스템 서비스를 제공하는 회사.

=== ipnordic ===
* http://www.ipnordic.dk
* Denmark
덴마크 통신 회사.

Asterisk 기반의 CTI 서비스를 제공한다.

=== ipvision ===
덴마크 통신회사.

Asterisk 기반의 CTI 서비스를 제공한다.
: http://ipvision.dk

=== zylinc ===
* http://www.zylinc.com/
* Denmark
UC 관련 컨택트 센터 프로그램을 개발하는 덴마크 회사.

=== Unitel ===
* https://uni-tel.dk/
* Denmark
Denmark UC 관련 통신 회사.

== France ==
=== Prescom ===
* http://www.prescom.net

== Germany ==
=== AVM GmbH ===
* https://www.avm.de/
* https://en.wikipedia.org/wiki/AVM_GmbH
인터넷 공유기 및 스위치, 라우터 등을 판매함.

=== C2Call GmbH ===
* http://www.c2call.com/
* https://en.wikipedia.org/wiki/C2Call_GmbH
2008 년 세워진 독일 VoIP 관련 회사.

=== Nfon ===
* http://nfon.com/
* https://en.wikipedia.org/wiki/Nfon
Cloud-based telephone systems.

=== SIPGate ===
* http://www.sipgate.de/
* https://en.wikipedia.org/wiki/Sipgate

== India ==
=== Plivo ===
* https://www.plivo.com/
* India
기업용 SMS, Voice calls 서비스를 제공하는 회사.

== Korea ==
=== bridge mobile ===
국내에 있는 mVoIP 관련 회사.
* Asterisk 를 이용하여 서비스를 제공함.
: http://rocketpun.ch/company/playmobs/
: http://www.bridge.co/

=== couchgram ===
국내 모바일 기반 통신 프로그램 개발 회사.
: http://www.couchgram.com/

=== herit ===
통신관련 솔루션 회사.
Parlay X 관련 정보 검색 중 발견. 기술력이 높아보임.
: http://www.herit.net/kr/index.php

=== hyper connect ===
WebRTC 관련 회사.
회사 문화가 매우 좋아보임. :)
: https://hyperconnect.com/

=== safeDKorea ===
* http://www.safedkorea.co.kr/
* Korea
Raspberry pi + Asterisk 솔루션 제작 업체.

=== sendbird ===
* https://sendbird.com/
* https://platum.kr/archives/121122
* 2020 1월 기준, 약 100여명 정도가 한국과 미국에서 근무중. 실리콘 벨리에 본사가 있음.
* https://sendbird.com/about 회사 마인드가 괜찮음.

=== trys ===
국내 VoIP 관련 업체.
: http://www.trys.co.kr

=== zoyi ===
리테일 컴퓨팅이라는 서비스를 제공하는 회사.
* 임베디드와 클라우드를 이용하여 재미있는 기업형(?) 서비스를 제공한다.
* 무엇보다 연봉 테이블을 공개한 것이 매우 인상적.
: http://zoyi.co/

=== 보이스로코 ===
국내 무료 통화 제공 업체.
* 아이폰/안드로이드로 이미 출시된 앱이 있으며(2015,04 기준), 앞으로도 많은 발전 가능성이 보임.
: http://www.voiceloco.com/

=== IMC Games ===
국내 게임 개발 명가. 김학규 프로그래머가 프로듀서로 있음.

<pre>
지금까지 필자가 읽었던 컴퓨터 책 중 최고의 책 한 권만을 꼽으라면 단연 본서 Pragmatic Programmer를 꼽을 것이다.
그만큼 필자의 프로그래밍 인생에 많은 영향을 주었고, 다시 매니저가 된 필자로 하여금 팀원들에게 영향을 끼치고 있기 때문이다.

프로그래밍의 세계에는 많은 이론들이 생겨나고, 저마다 혁신적인 방법론을 제창하기도 하며, 프로그래밍의 왕도에 대한 수많은 논란이 벌어지고 있다.
도대체 더 나은 소프트웨어를 만들려면 어떻게 해야 하는 것일까?
지금까지 우리는 구조적 프로그래밍, OOP, Generic 프로그래밍, 컴포넌트 기반 개발, 디자인 패턴, 리팩터링, Aspect Oriented Programming 등등
수많은 이론과 방법을 접하고 있으며, 앞으로도 새로운 이론들은 계속 나올 것으로 보인다.
하지만 이러한 많은 이론들이 추구하는바 더 나은 소프트웨어를 만드는 더 나은 방법의 공통 요소가 있는 것은 아닐까? 그런 것이 있다면 어떤 것일까?

본서는 그 공통요소에 대해 명쾌한 비유와 설명, 실용적인 예시로 필자의 궁금증을 풀어주었다.
DRY나 직교화 같은 개념을 마음속으로 이해하고 나면 위에 예로 들었던 수많은 방법론들이 어떤 필요성에서 출발해서 왜 이런 형태로 존재하고, 또 앞으로는 어떻게 나아갈 것인지에 대한 통찰을 얻을 수 있다.
깨진 창문이나 삶은 개구리 같은 식의비유를 통해서 팀원들 간 이해의 공감대를 넓힌 것은 정말 가치 있는 일이었다.

필자의 회사에서는 새로운 팀원을 채용하기 전에, 지원자에게 Pragmatic Programmer를 면접보기 전에 읽고 올 것을 요구하고 있다.
안 읽고 온 사람에게는 책에 있는 것과 똑같은 얘기를 회사에서 해줘야 하기 때문이다.

늦은 감이 있지만 이러한 명저가 한국어로 출간된다는 점에 대해 너무나도 다행스럽게 생각하며, 독자 여러분도 깨달음의 기쁨을 공유할 수 있기를 기원한다.
[IMC게임즈 프로듀서 김학규]

</pre>
: http://www.imc.co.kr/

=== 나온웍스(Naon Works) ===
* http://www.naonworks.com
국내 SBC(Session Border Controller) 관련 내용을 찾다가 알게 된 회사.

=== 스무디(smoothy) ===
* https://smoothy.co/ko
영상 채팅 관련 회사. WebRTC 기반 다자간 영상통화 서버 프로그램 개발 및 인프라 운영.

=== 민코넷(minkonet) ===
* https://www.minkonet.com/
WebRTC 기반 게임 스트리밍 서비스 제공.

=== 더블미디어(double media) ===
* https://www.saramin.co.kr/zf_user/company-info/view?csn=T1MrRzlIMG1ROUNqUFlwRjdtekh1QT09

=== 브로드 씨엔에스(Broad CNS) ===
* http://www.broadcns.com/
* Asterisk 기반 콜센터 솔루션 업체.
* Java, ASP.NET, C#

=== 포지큐브(Posicube) ===
* https://www.posicube.com/
* Asterisk + AI 관련 솔루션 개발.
* 콜센터 관련 프로그램 개발.

=== 아틀라스랩스(atlaslabs) ===
* https://www.atlaslabs.ai/
* Asterisk + AI 관련 솔루션 개발.

=== 솔트룩스(saltlux) ===
* http://www.saltlux.com/
* Asterisk 사용.

== New zealand ==
=== Venture voip ===
* http://venturevoip.com/index.php
뉴질랜드 회사. Asterisk 메일링 리스트에서 알게됨.

== USA ==
=== Avoxi ===
* https://www.avoxi.com/
* US based call center solution company.

=== Connexo ===
* http://www.connexo.net
* Porta Text 메시지(SMS) 전송 서비스.
github 에서 알게 된 회사. 미국에 본사가 있으며 CTI 쪽 개발을 하는 회사 같다. CTO가 굉장히 github 활동이 왕성해서 알게됨.

=== elastix ===
UC 관련 교환기 회사(Fronend/Backend).
: http://www.elastix.com/en/
: 본사는 3CX. https://www.3cx.com

=== ooma ===
VoIP 업체. 위키 피디아에도 등재되어 있음. Kamalio/OpenSER, Asterisk, Freeswitch 와 관련한 개발자를 구하고 있음(Senior).

2015.07 $8.5M 규모 나스닥 상장.<ref>http://www.nasdaq.com/article/internet-based-telecom-provider-ooma-sets-terms-for-85-million-ipo-cm493605</ref>

미국 팔로 알토에 본사 위치.
: http://www.ooma.com/
: https://en.wikipedia.org/wiki/Ooma

=== telnyx ===
2017.05.02 Amsterdam 에서 열린 OpenSIP Summt 에서 알게됨.
유투브로 시청하던 중, 강단에 찍힌 로고로 알게되었음.

미국 일리노이 주에 위치함. SIP service provider 및 기업용 소프트웨어를 판매하는 것으로 보임.
: https://telnyx.com/

=== IDT ===
* https://www.idt.net/
* Asterisk/Kamailio/... 등등 기반으로 Route provide 서비스 제공.

=== Twilio ===
* https://www.twilio.com/
SMS, Voice, Video, Authentication 관련 API 를 제공하는 회사.

=== xcally ===
Asterisk 기반 Call center solution 회사
: http://www.xcally.com/

=== NextVR ===
실시간 VR(Virtual Reality) 개발 회사. 실시간으로 VR이 가능하다면 어떤 것들이 가능해질지 정말 궁금하다. :)
: http://www.nextvr.com/
: http://www.nextvr.com/careers/
: http://www.wsj.com/articles/comcast-time-warner-invest-in-virtual-reality-1447274523 - VR 실시간 스트리밍 업체 NextVR, 350억원 유치

=== Freeswitch ===
* http://freeswitch.com - freeswitch

=== Kandy ===
* https://www.kandy.io/

=== Flowroute ===
* https://www.flowroute.com

=== Switch ===
* https://www.switch.co/

=== 2600Hz ===
* https://www.2600hz.com/

=== Tropo ===
* https://www.tropo.com/products

=== Onsip ===
* https://www.onsip.com/

=== Orecx ===
* http://www.orecx.com/

== International ==
=== Sangoma ===
* http://www.sangoma.com/

=== Mitel ===
* http://www.mitel.com

=== Twilio ===
* https://www.twilio.com

=== Truphone ===
* https://www.truphone.com

=== Cisco ===
* https://meraki.cisco.com

=== VoiceTel ===
* http://www.voicetel.com/

=== Zendesk ===
* https://www.zendesk.com/jobs/

=== Infobip ===
* 유럽(Poland)에 HQ가 위치한 CCaaS 기업.
* 여러 채널(Call/SMS/SNS/...)을 지원하며, API 문서 정리가 잘 되어 있음.(https://www.infobip.com/docs/api)
* https://www.infobip.com

=== Link mobility ===
* https://www.linkmobility.com/
* Norway based CPaas Company.

== Other ==

== References ==
<references />

[[category:etc]]

Mysql sql

2023-07-03T02:43:27Z

Pchero: /* ETC */

== Overview ==
Mysql 사용법 정리.

== Basic ==
=== Data types ===
==== datetime ====
Mysql-5.6 버전 이후부터 사용가능.

=== Naming ===
Mysql 에서 Table, View 등의 이름을 숫자로 만들 수는 없다. 하지만 숫자-스트링으로는 가능하다. 이 경우 숫자-스트링을 ``로 감싸주면 된다.
<pre>
mysql> create view 123 as select * from t1 where time="now";
ERROR 1064 (42000): You have an error in your SQL syntax;
check the manual that corresponds to your MySQL server version for the right syntax to use near '123 as select * from t1 where time="now"' at line 1

mysql> create view "123" as select * from t1 where time="now";
ERROR 1064 (42000): You have an error in your SQL syntax;
check the manual that corresponds to your MySQL server version for the right syntax to use near '"123" as select * from t1 where time="now"' at line 1

mysql> create view '123' as select * from t1 where time="now";
ERROR 1064 (42000): You have an error in your SQL syntax;
check the manual that corresponds to your MySQL server version for the right syntax to use near ''123' as select * from t1 where time="now"' at line 1

mysql> create view `123` as select * from t1 where time="now";
Query OK, 0 rows affected (0.10 sec)
</pre>

== foreign key ==
Mysql-3.23.43 버전 이후부터는 외래키 지정이 가능하다.

=== Options ===
* on delete cascade
부모의 해당키가 삭제되면 자동으로 삭제된다.

* on delete set null
부모의 해당키가 삭제되면 자동으로 null 로 만든다.

* on update cascade
부모의 해당키가 삭제되면 자동으로 갱신된다.

=== Example ===
agent id 를 외래키로 지정을 한 agent_group 테이블이다. agent_group 에 속한 agent 삭제시 같이 삭제되고, 업데이트 시, 같이 업데이트된다.

<source lang=sql>
create table agent (
id int not null unique,
name varchar(255),

primary key(id)

);

create table agent_group(
group_id int not null unique,
agent_id int not null,

foreign key(agent_id) references agent(id) on delete cascade on update cascade,

primary key(group_id, agent_id)
);
</source>

== Alter ==
이미 생성되어 있는 테이블의 내용을 변경한다.

Drop the column from the table.
<source lang=sql>
ALTER TABLE table_name DROP column_name;
</source>

Add the column to the table
<source lang=sql>
ALTER TABLE Customers ADD Email varchar(255);
</source>

<source lang=sql>
ALTER TABLE table_name MODIFY COLUMN column_name datatype;
</source>

== Update ==
이미 존재하는 레코드의 값을 변경한다.
<pre>
UPDATE <table> SET <field> = "<value>" WHERE <field> > "<condition>";
조건 값보다 큰 필드의 레코드 값을 수정

UPDATE <table> SET <field> = "<value>" WHERE <field> <> "<condition>";
조건 값을 제외한 모든 레코드 값을 수정

UPDATE <table> SET <field1> = "<value>", <field2> = "<value>" WHERE <conditions>;
조건에 맞는 두개의 필드를 바꿈

UPDATE <table> SET <field> = REPLACE(<field>, 'alpha', 'beta')
필드의 값에 'alpha'라는 단어가 포함 되어 있다면 모두 'beta'로 수정

UPDATE <table> SET <field> = CONCAT(<field>,'alpha') WHERE <conditions>
조건에 맞는 필드명의 값에 'alpha' 단어를 덧붙임
</pre>

== Insert ==
<pre>
INSERT INTO <table> (columns) VALUES (values);
</pre>

== Delete ==
<pre>
DELETE FROM `table_name` [WHERE condition];
</pre>

== View ==
View 는 임시 테이블로도 번역이 된다. 어떤 테이블에서 특정 자료들만을 관리하는 임의의 테이블을 만들고자할 때, 사용할 수 있다.

=== Create ===
View 를 생성한다.
<source lang=sql>
create view <view_name> as <select_query>;
</source>

=== Show all views ===
현재 생성되어 있는 모든 view 들을 확인하고자 할 때는 다음의 쿼리를 사용하면 된다.
<source lang=sql>
SHOW FULL TABLES IN <database_name> WHERE TABLE_TYPE LIKE 'VIEW';
</source>

== Error ==

=== Warnings ===
Mysql Query 를 실행하다보면 한번씩 Warning 메시지를 확인할 수 있다. 뭔가 경고할만한 내용이 있다는 것인데, 확인하기 위해서는 다음의 명령어를 입력하면 된다<ref>http://dev.mysql.com/doc/refman/5.0/en/show-warnings.html</ref>.
<source lang=sql>
SHOW WARNINGS;
</source>
<pre>
mysql> select * from `32e9e86e_f57f_4156_8d1a_26f169b845c4`;
Empty set, 2 warnings (0.00 sec)

mysql> show warnings;
+---------+------+---------------------------------------------------------------------------------------------+
| Level | Code | Message |
+---------+------+---------------------------------------------------------------------------------------------+
| Warning | 1292 | Incorrect datetime value: '32e9e86e-f57f-4156-8d1a-26f169b845c4' for column 'time' at row 1 |
| Warning | 1292 | Incorrect datetime value: '32e9e86e-f57f-4156-8d1a-26f169b845c4' for column 'time' at row 1 |
+---------+------+---------------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)
</pre>

== ETC ==
=== Checksum ===
<pre>
CHECKSUM TABLE tbl_name [, tbl_name] ... [QUICK | EXTENDED]
</pre>
CHECKSUM TABLE reports a checksum for the contents of a table. You can use this statement to verify that the contents are the same before and after a backup, rollback, or other operation that is intended to put the data back to a known state.

=== Check table exist ===
특정 테이블이 있는지, 아닌지를 알고 싶을 때가 있다. 이런 경우, 다음의 쿼리를 입력하면, 테이블이 있으면 정상, 없으면 오류를 리턴한다.<ref>http://stackoverflow.com/questions/8829102/mysql-check-if-table-exists-without-using-select-from</ref>
<source lang=sql>
SELECT 1 FROM testtable LIMIT 1;
</source>

=== Execute sql script ===
SQL 스크립트를 실행하고자 할 때는 다음과 같이 하면 된다.<ref>https://dev.mysql.com/doc/refman/5.7/en/mysql-batch-commands.html</ref>
<pre>
-- shell
shell> mysql db_name
shell> mysql db_name < text_file
shell> mysql < text_file

-- mysql
mysql> source file_name
mysql> \. file_name
</pre>

=== Create Primary Key with UUID() ===
uuid 를 primary key로 지정할 때, UUID() 함수를 사용할 수 있다. trigger 를 만들어 놓으면, 매번 테이블에 데이터를 입력할 때마다 자동으로 UUID() 함수가 실행되어 입력되도록 할 수도 있다.<ref>http://forums.mysql.com/read.php?10,175939,176708#msg-176708</ref>
<source lang=sql>
DROP TABLE IF EXISTS t;
CREATE TABLE t(id CHAR(128));

DELIMITER //
CREATE TRIGGER init_uuid BEFORE INSERT ON t
FOR EACH ROW SET NEW.id = UUID();
//
DELIMITER ;

INSERT INTO t VALUES( NULL );
SELECT * FROM t;
+--------------------------------------+
| id |
+--------------------------------------+
| 42114800-6f22-1000-9611-2eb9174826e3 |
+--------------------------------------+
</source>

=== MAX_EXECUTION_TIME ===
Mysql 5.7 버전부터 사용할 수 있다. select 및 다른 SQL query 실행에 timeout 을 설정하는 옵션이다.

<source lang=sql>
SELECT /*+ MAX_EXECUTION_TIME(1000) */ * FROM calls where destination = '11234';

SELECT /*+ MAX_EXECUTION_TIME(1000) */ * FROM t1 INNER JOIN t2 WHERE ...
</source>
* https://dev.mysql.com/doc/refman/5.7/en/optimizer-hints.html#optimizer-hints-execution-time
* https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html

== See also ==
* http://sjs0270.tistory.com/54 - 뷰(View)

== References ==
<references />

[[category:mysql]]

Kamailio module tls

2023-05-26T01:43:47Z

Pchero:

== Overview ==
Kamailio's TLS 모듈 내용 정리.

The TLS(Transport Layer Security) module in Kamailio enables secure communication between SIP clients and servers using the TLS protocol.

== TLS ciphers ==
When configuring the TLS module in Kamailio, user has the option to specify the cipher suites that will be used for securing the communication. Cipher suites are sets of cryptographic algorithms used for encryption, authentication, and key exchange during the TLS handshake process.

Kamailio's TLS module supports various cipher suites, and the user can define the desired cipher list in the Kamailio configuration file. The cipher list determines the order and preference of cipher suites that Kamailio will negotiate with the connecting clients.

* Default Cipher List
: The default cipher list used by Kamailio's TLS module is determined by the underlying TLS library(such as OpenSSL). It usually includes a broad range of cipher suites, prioritizing security and compatibility. The default cipher list can be overridden in the Kamailio configuration file.

* Custom Cipher List
: User can define a custom cipher list in the Kamailio configuration file by setting the 'tls_ciphers' parameter. The cipher list should be a space-separated list of cipher suite names or aliases.
: <pre>modparam("tls", "tls_ciphers", "ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-GCM-SHA256")</pre>
: In this example, the custom cipher list includes 3 cipher suites: ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-AES128-GCM-SHA256. Kamailio will attempt to negotiate these cipher suites in the specified order.

* Restricting Cipher Suites
: If user wants to restrict the available cipher suites to a specific subset, user can define an explicit cipher list. This can be useful for enforcing stronger security measures or ensuring compatibility with specific requirements.
: <pre>modparam("tls", "tls_ciphers", "HIGH:!aNULL:!MD5:!RC4")</pre>
: In this example, the cipher list restrict the available cipher suites to those considered to have high security strength and excludes certain weak or deprecated algorithms, such as 'aNULL'(no authentication), 'MD5', and 'RC4'.

== See also ==
* https://kamailio.org/docs/modules/5.3.x/modules/tls.html

[[category:kamailio]]

Kamailio module tls

2023-05-26T01:28:20Z

Pchero: Created page with "== Overview == Kamailio's TLS 모듈 내용 정리. The TLS(Transport Layer Security) module in Kamailio enables secure communication between SIP clients and servers using the TLS protocol. == TLS ciphers == When configuring the TLS module in Kamailio, user has the option to specify the cipher suites that will be used for securing the communication. Cipher suites are sets of cryptographic algorithms used for encryption, authentication, and key exchange during the TLS h..."

SIP Header

2023-04-20T08:25:27Z

Pchero: /* Session-Expires */

== Overview ==
SIP headers 내용 정리

== Basic ==
=== SIP and SIPS URIs ===
SIP URIs are used in a number of places including the To, From, and Contact headers, as well as in the Request-URI, which indicates the destination. SIP URIs are similar to the mailto URL and can be used in hyperlinks on Web page, for example. They can also include telephone numbers. The information in a SIP URL incidates the way in which the resource (user) should be contacted using SIP.

An example SIP URI contains the scheme '''sip''' a ''':''', then a '''username@host''' or IPv4 or IPv6 address followed by an optional ''':''', then port number, or a list of ''';''' separated URI parameters.
<pre>
sip:pchero.sungtae@pchero21.com:5060;transport=udp;user=ip;method=INVITE;ttl=1;maddr=240.101.102.103?Subject=FFT
</pre>
Note that URIs may not contain spaces or line breaks, so this example would be on a single line. Some SIP URIs, such as REGISTER Request-URI do not have a username, but begin with the host or IP address. In this example, the port number is shown as 5060, the well-known port number for SIP. For a SIP number 5061 is assumed. The transport parameter indicates UDP is to be used, which is the default. TCP, TLS, and SCTP are alternative transport parameters.

The user parameter is used by parsers to determine if a telephone number is present in the username portion of the URI. The assumed default is that it is not, indicated by the value ip. If a telephone. number is present, it is indicated by the value phone. This parameter must not used to guess at the characteristics or capabilities of the user agent. For example, the presence of a user=phone parameter must not be interpreted that the user agent is a SIP telephone(which may have limited display and processing capabilties). In a telephone environment, IP telephones and IP/PSTN gateways may in fact use the reverse assumption, interpreting any digits in a username as digits regardless of the presence of user=phone.

== CSeq ==
The CSeq header field serves as a way to identify and order transactions. It consists of a sequence number and a method. The method MUST match that of the request. For non-REGISTER requests outside of a dialog, the sequence number value is arbitrary. The sequence number value MUST be expressible as a 32-bit unsigned integer and MUST be less than 2**31. As long as it follows the above guidelines, a client may use any mechanism it would like to select CSeq header field values.
<pre>
CSeq: 4711 INVITE
</pre>

CSeq 는 메시지의 순서를 파악하는데 사용된다. 각각의 request 메시지마다 1씩 증가하게 되며, 이를 통해서 메시지의 순서를 확인할 수 있다. 만약 이전에 처리한 CSeq 보다 낮은 숫자의 Request 가 오게된다면 500 response 를 보내야 한다. 하지만 CSeq 는 종종 한번에 1 이상씩 증가할 수도 있다. 하지만 이는 에러가 아니며, 메시지는 정상적으로 처리되게 된다.

=== UAC behavior ====
The Call-ID of the request MUST be set to the Call-ID of the dialog. Requests within a dialog MUST contain strictly monotonically increasing and contiguous CSeq sequence numbers (increasing-by-one) in each direction (excepting ACK and CANCEL of course, whose numbers equal the requests being acknowledged or canceled). Therefore, if the local sequence number is not empty, the value of the local sequence number MUST be incremented by one, and this value MUST be placed into the CSeq header field. If the local sequence number is empty, an initial value MUST be chosen using the guidelines.

=== UAS behavior ===
If the remote sequence number is empty, it MUST be set to the value of the sequence number in the CSeq header field value in the request. If the remote sequence number was not empty, but the sequence number of the request is lower than remote sequence number, the request is out of order and MUST be rejected with a 500 (Server internal Error) response. If the remote sequence number was not empty, and the sequence number of the request is greater than the remote sequence number, the request is in order. It is possible for the CSeq sequence number to be higher than the remote sequence umber by more than one. This is not an error condition, and a UAS SHOULD be prepared to receive and process requests with CSeq values more than one higher than the previous received request. The UAS MUST then set the remote sequence number to the value of the sequence number in the CSeq header field value in the request.

: If a proxy challenges a request generated by the UAC, the UAC has to resubmit the request with credentials. The resubmitted request will have a new CSeq number. The UAS will never see the first request, and thus, it will notice a gap in the CSeq number space. Such a gap does not represent any error condition.

When a UAS receives a target refresh request, it MUST replace the dialog's remote target URI with the URI from the Contact header field in the request, if present.

== Max-Forwards ==
The Max-Forwards header field is used to indicate the maximum number of hops that a SIP request may take. The value of the header field is decremented by each proxy that forwards the request. A proxy receiving the header field with a value of zero discards the message and sends a 403 Too Many Hops response back to the originator.

Max-Forwards is a mandatory header field in requests generated by an RFC 3261 compliant UA. However, an RFC 2543 UA generally will not include the header field. The suggested initial value is 70 hops.
<pre>
Max-Forwards: 70
</pre>

== P-Asserted-Identity ==
P-Asserted-Identity is a special type of UA identity implying "This is the proven ID for me within this trusted network".

Usually, UA ID is set in 'From' header, but the From header does not necessarily contain the actual identity. Actually, you can put any kind of string for 'From' header. Therefore, once the authentication is complete for a UA, a proxy can add P-Asserted-Identity to inform other proxies saying 'Hey, this is a proven ID. So you can trust'.

From the RFC 3325, 9.1 The P-Asserted-Identity header:
: The P-Asserted-Identity header field is used among trusted SIP entities (typically intermediaries)to carry the identity of the user sending a SIP message as it was verified by authentication.
: A P-Asserted-Identity header field value MUST consist of exactly one name-addr or addr-spec. There may be one or two P-Asserted-Identity values. If there is one value, it MUST be a sip, or tel URI. If there are two values, one value MUST be a sip or sips URI and the other MUST be a tel URI. It is worth noting that proxies can (and will) add and remove this header field.

<pre>
P-Asserted-Identity: tel:+123456789
P-Asserted-Identity: "sungtae kim" <sip:pchero@pchero21.com>
</pre>
* https://i3forum.org/wp-content/uploads/2019/06/i3f_CLI_management_guidelines_rev-1.pdf

== Record-Route ==
The Record-Route header field is used to force routing through a proxy for all subsequent requests in a session(dialog) between two UAs. Normally, the presence of a Contact header field allows UAs to send messages directly bypassing the proxy chain used in the initial request (which probably involved database lookups to locate the called party). A proxy inserting its address into a Record-Route header field overrides this and forces future requests to include a Route header field containing the address of the proxy that forces this proxy to be included.

A proxy wishing to implement this inserts the header field containing its own URI, or adds it URI to an already present Record-Route header field. The URI is constructed so that the URI resolves back to the proxy server. The UAS copies the Record-Route header field into the 200 OK response to the request. The header field is forwarded unchanged by proxies back to the UAC. The UAC then stores the Record-Route proxy list plus a Contact header field if present in the 200 OK for use in a Route header field in all subsequent requests. Because Record-Route is bidirectional, messages in the reverse direction will also traverse the same set of proxies.

The 'lr' parameter is new to RFC 3261 and indicates that the proxy server supports "loose routing".

Older RFC 2543 compliant proxy servers create Record-Route URIs that instead of the lr parameter often contain the maddr parameter with an address or host that resolves to that proxy server.
<pre>
Record-Route: <sip:10.164.0.8;transport=tcp;lr;r2=on>
Record-Route: <sip:192.168.0.237;transport=tcp;lr;r2=on>

Record-Route: <sip:10.164.0.8;transport=tcp;lr;r2=on>,<sip:192.168.0.237;transport=tcp;lr;r2=on>
</pre>

== Request line URI ==
The Request line URI includes the destination of the call. It contains the same information as the To field, omitting the display name.

== Route ==
The Route header field is used to provide routing information for requests. RFC 3261 introduces two types of routing: strict and loose routing, which have a similar meaning as the IP routing modes of the same name. In strict routing, a proxy must use the first URI in the Route header field to rewrite the Request-URI, which is then forwarded. In loose routing, a proxy does not rewrite the Request-URI, but either forwards the request to the first URI in the Route header field or to another loose routing element.

In loose routing, the request must route through every server in the Route list(but may also route through other servers) before it may be routed based on the Request-URI.

In strict routing, the request must only route through the set of server in the Route header field with the Request-URI being rewritten at each hop.

A proxy or UAC can tell if the next element in the route set supports loose routing by the presence of an 'lr' parameter.
<pre>
Route: <sip:192.168.0.237;transport=tcp;lr;r2=on>
Route: <sip:10.164.0.8;transport=tcp;lr;r2=on>

Route: <sip:192.168.0.237;transport=tcp;lr;r2=on>, Route: <sip:10.164.0.8;transport=tcp;lr;r2=on>
</pre>

== Session-Expires ==
The Session-Expires header field is used to specify the expiration time of the session. To extend the session, either UA can send a re-INVITE or UPDATE with a new Session-Expires header field.

At the expiration of the interval in the Session-Expires, either UA may send a BYE and call-stateful proxies may destroy any state information. A proxy may shorten the expiration time by reducing the interval in the header field as it proxies the request.

A UAS confirms the session timer by including the Session-Expires header field in the response to the request. A UAS may also shorten the interval by reducing the interval.
<pre>
Session-Expires: 1800
</pre>

Btw, the UA can expire the session before the session expiration. The RFC-4028 recommends 32-secs for early expiration. Here is a detailed description. In this case, the UA should send the BYE.

https://www.rfc-editor.org/rfc/rfc4028.html#section-10
<pre>
Similarly, if the side not performing refreshes does not receive a
session refresh request before the session expiration, it SHOULD send
a BYE to terminate the session, slightly before the session
expiration. The minimum of 32 seconds and one third of the session
interval is RECOMMENDED.
</pre>

And the Asterisk(PJSIP) follows this 32-sec recommendation.

https://github.com/pjsip/pjproject/blob/master/pjsip/src/pjsip-ua/sip_timer.c#L518
<pre>
} else {
/* Send BYE if no refresh received until this timer fired, delay
* is the minimum of 32 seconds and one third of the session interval
* before session expiration.
*/
delay.sec = timer->setting.sess_expires -
timer->setting.sess_expires/3;
delay.sec = PJ_MAX((long)timer->setting.sess_expires-32, delay.sec);
}
</pre>

== To ==
The To header field is required header field in every SIP message used to indicate the recipient of the request. Any responses generated by a UA will contain this header field with the addition of a tag. (Note tha t an RFC 2543 client will typically only generate a tag if more than one Via header field is present in the request.) Any response generated by a proxy must have a tag added to the To header field. A tag added to the header field in a 200 OK response is used throughout the call and incorporated into the dialog. The To header field URI is never used for routing - the request-URI is used for this purpose. An optional display name can be present in the header field, in which case the SIP URI is enclosed in < >. If the URI contains any parameters or username parameters, the URI must be enclosed in < > even if no display name is present. The compact form of the header fields is t.

== Via ==
Every proxy in the request path adds to top of the "Via" the address and port on which it received the message, than forwards it onwards. When processing responses, each proxy in the return path process the contents of the "Via" field in reverse order, removing its address from the top.

== See also ==
* https://www.3cx.com/blog/voip-howto/sip-invite-header-fields - The main SIP INVITE Header Fields explained

[[category:SIP protocol]]

SIP RTP

2023-02-28T13:57:11Z

Pchero: /* RTP Header */

== Overview ==
RTP 내용정리

== Basic ==
실시간 음성, 영상 데이터를 IP 네트워크 상에서 전송하기 위해서는 항상 RTP 를 사용한다. RTP는 RFC 1889(A Transport Protocol for Real-Time Applications)에 정의되어 있었지만, 2003년 RFC 1889를 대신하는 RFC 3550이 standards track 으로 채택 되면서, RFC 1889 가 폐기되었다.

간략하게 RFC 3550의 앞부분에 명시된 개요 부분을 요약하면, RTP는 Real-Time Transport Protocol의 약어로 음성, 영상 또는 시뮬레이션 데이터와 같은 실시간 데이터를 멀티캐스트 또는 유니캐스트 네트워크를 이용하여 전송하는 응용 서비스를 위한 end-to-end 네트워크 전송 프로토콜이다. RTP는 RTCP(Real-Time Control Protocol)에 의해 데이터의 전달 상황을 감시하며, 최소한의 제어 기능과 미디어 식별 기능을 제공한다.

== Protocol ==
RTP는 전송 프로토콜로 UDP(User Datagram Protocol)과 네트워크 프로토콜로 IP를 이용한다. RTP가 신뢰할 수 있는 TCP를 이용하지 않고 UDP를 이용하는 이유는 실시간 음성 및 영상은 패킷 에러나 패킷 소실이 발생하더라도 TCP 재전송 매커니즘을 활용할 수 없기 때문이다. 재전송된 패킷은 수신 단말이 재생해야 할 시점을 이미 지나버린 이후가 될 확률이 높아 패킷을 폐기한다.
<pre>
RTP 패킷당 페이로드 크기
--------------------------------------------------------------
| Ethernet(18 bytes) | IP(20 bytes) | RTP(12 bytes) | Sample |
--------------------------------------------------------------
</pre>

섀논과 나이키스트 정리에 의해 G.711 코덱은 1초당 8000 개의 샘플링과 샘플당 8비트로 양자화한다. DSP 칩으로 G.711 코덱을 적용하면 10ms 단위당 음성 샘플을 160 바이트이고, G.729는 20 바이트이다. 만일 패킷당 10ms 단위로 페이로드를 만들면 초당 100개가 전송되고, 패킷당 20ms 단위로 페이로드를 만들면 50개가 전송된다. 일반적으로 20ms 단위로 하나의 패킷을 만들어 초당 50개의 패킷을 생성한다.
<pre>
G.711

1 초당 8000 개의 샘플링
샘플당 8 비트(bit)
1초 음성에 사용되는 바이트(byte) = 8000 * 8(bit) / 8(byte 계산) = 8000 byte = 8Kb
만약 스테레오라면 8Kb x 2 = 16Kb
</pre>

== RTP Header ==
RFC 3550에 RTP 헤더가 정의되어 있다.
<pre>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
* V(version)
: 2 Bit.
: RTP 의 Version 표시. 현재 버전은 2.

* P(padding)
: 1 bit.
: 패킷의 마지막 부분에 하나 이상의 패딩 바이트 유무 표시.
: 패딩 비트는 의미가 없는 비트로 헤더나 패킷의 크기를 일정하게 유지하기 위해 사용하는 비트.

* X (extension)
: 1 bit.
: 고정 헤더 이후의 하나 이상의 확장 헤더 유무 표시.

* CC (CSRC Count)
: 4 bit.
: RTP 12 바이트 고정 헤더 위에 CSRC identifier 의 수 표시.

* M (Marker)
: 1 bit.
: 패킷 내에서 프레임 경계와 같은 중요한 이벤트들을 표시.
: Payload Type 필드의 확장을 위해 무시되기도 함.
: The interpretation of the marker is defined by a profile. It is intended to allow significant events such as frame boundaries to be marked in the packet stream. A profile MAY define additional bits or specify that there is no marker bit by changing the number of bits in the payload type field.

* PT (Payload Type)
: 7 bit.
: 페이로드 타입은 RTP가 전송하고 있는 실시간 데이터의 압축 코덱을 명시.
: 페이로드 타입은 Capability Exchange 협상에서 상호 인지 필수.
: This field identifies the format of the RTP payload and determines its interpretation by the application. A profile MAY specify a default static mapping of payload type codes to payload formats. Additional payload type codes MAY be defined dynamically through non-RTP means. A set of default mappings for audio and video is specified in the companion RFC 3551. An RTP source MAY change the payload type during a session, but this field SHOULD NOT be used for multiplexing separate media streams. A receiver MUST ignore packets with payload types that it does not understand.

* Sequence number
: 16 bit.
: 보안을 이유로 랜덤 번호에서 시작하고 패킷이 늘어날 때마다 1씩 증가.
: 수신 측이 패킷 손실 여부 확인 가능.
: The sequence number increments by one for each RTP data packet sent, and may be used by the receiver to detect packet loss and to restore packet sequence. The initial value of the sequence number SHOULD be random(unpredictable) to make known-plaintext attacks on encryption more difficult, even if the source itself does not encrypt, because the packets may flow through a translator that does.

* Timestamp
: 32 bit.
: RTP 패킷의 첫 번째 바이트의 샘플링 순간을 표시.
: 초기값은 랜덤 넘버로 결정되지만 샘플링 레이트에 따라 증가량은 상이함.
: The timestamp reflects the sampling instant MUST be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations. The resolution of the clock MUST be sufficient for the desired

* SSRC (Synchronization Source) Identifier
: 32 bit.
: 동기화 소스로 랜덤 넘버로 결정.

* CSRC (Contributing Source) Identifier
: 32 bit.
: 다수의 음원이 Audio Mixer 를 통해 하나로 통합될 경우 원래 음원의 목록을 표시.

== RTCP Header ==
RFC 3550에 RTCP 헤더가 정의되어 있다.
<pre>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| RC | PT=SR=200 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
sender | NTP timestamp, most significant word |
info +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's packet count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's octet count |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_1 (SSRC of first source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | fraction lost | cumulative number of packets lost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_2 (SSRC of second source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 : ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>

== SRTP Decode ==
=== libsrtp ===
* https://github.com/cisco/libsrtp
<pre>
./configure --enable-openssl --enable-log-stdout --with-openssl-dir=/opt/homebrew/opt/openssl@3 --prefix=/usr/local
</pre>

libsrtp provides useful utilities under the test folder.
* rtp_decoder: Performs the description.

== Troubleshooting ==
* RTP 패킷이 정상적으로 수신되는가?
: 시그널링이 정상적이어도 RTP 패킷이 송수신되지 않는 경우가 있다. 실제 NAT(Network Address Translation) 이슈로 인해 주소가 잘못 지정되었을 수도 있다.

* SSRC 가 변경되지는 않았는가?
: 같은 통화의 패킷임에도 SSRC가 변경되면 다른 세션으로 인식되어 패킷은 폐기된다.

* 시퀀스 넘버는 일정하게 증가하는가?
: 시퀀스 넘버가 순차적으로 증가하지않고 갑자기 증가하거나 감소하는 경우가 있다. 예를 들어 100 다음 400번이 오는 경우 수신 단말은 300 개의 패킷이 손실된 것으로 보고 재생하지 않는다. 반대로 100 다음에 60 이 오는 경우 수신단말은 이미 수신한 패킷으로 인식하고 재생하지 않는다.
: RFC 3550 Appendix A.3 Determining Number of Packets Expected and Lost 에 의하면, 갑자기 비연속적인 시퀀스 넘버가 3개 이상 연속될 경우 수신 단말은 시퀀스 넘버가 재설정된 것으로 인삭하고 재생해야 한다.

* 타임스탬프는 일정하게 증가하는가?
: 타임스탬프는 패킷의 재생 시점을 확인하므로 갑자기 감소하거나 크게 증가하면 안된다.

* 음질에 문제가 있는가?
: 와이어 샤크로 RTP 패킷을 캡쳐하여 음성 파일로 만들어서 재생할 수 있다. 음성 파일에 문제가 있다면 송신 단말에서 문제가 있는 것이고, 음성 파일에 문제가 없다면 수신 단말의 문제이다.

== See also ==
* https://brunch.co.kr/@linecard/154 - RTP의 이해

[[category:SIP protocol]]