From fcfa6385b9701ae8e04abffa5671745cf53b6c66 Mon Sep 17 00:00:00 2001
From: Emir Aganovic <emir.aganovic@babelforce.com>
Date: Thu, 29 Aug 2024 23:26:23 +0200
Subject: [PATCH] fix: remove output example for now

---
 docs/examples/index.html | 11 ++++-------
 en.search-data.json      |  2 +-
 2 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/docs/examples/index.html b/docs/examples/index.html
index d95aa6c..ef8d206 100644
--- a/docs/examples/index.html
+++ b/docs/examples/index.html
@@ -17,7 +17,7 @@
 Source code of examples can be found in library. You will need go compiler installed
 Audio playback Run playback as server
 go run ./examples/playback Dial in and you should hear audio on your speakers
-gophone dial -media=speaker sip:112@127.0.0.1 Output sample Bridge media Run bridge app that always bridges with bob on port 5090" />
+gophone dial -media=speaker sip:112@127.0.0.1 Bridge media Run bridge app that always bridges with bob on port 5090" />
 
   
     <link rel="canonical" href="https://emiago.github.io/diago/docs/examples/" itemprop="url" />
@@ -37,8 +37,8 @@
 Source code of examples can be found in library. You will need go compiler installed
 Audio playback Run playback as server
 go run ./examples/playback Dial in and you should hear audio on your speakers
-gophone dial -media=speaker sip:112@127.0.0.1 Output sample Bridge media Run bridge app that always bridges with bob on port 5090">
-  <meta itemprop="wordCount" content="113">
+gophone dial -media=speaker sip:112@127.0.0.1 Bridge media Run bridge app that always bridges with bob on port 5090">
+  <meta itemprop="wordCount" content="111">
   <meta name="twitter:card" content="summary">
   <meta name="twitter:title" content="Examples">
   <meta name="twitter:description" content="CLI Softphone for testing For testing below scenarios, gophone as CLI softphone is used, but you can use any softphone you like Visit the page and install:
@@ -46,7 +46,7 @@
 Source code of examples can be found in library. You will need go compiler installed
 Audio playback Run playback as server
 go run ./examples/playback Dial in and you should hear audio on your speakers
-gophone dial -media=speaker sip:112@127.0.0.1 Output sample Bridge media Run bridge app that always bridges with bob on port 5090">
+gophone dial -media=speaker sip:112@127.0.0.1 Bridge media Run bridge app that always bridges with bob on port 5090">
 
     <link rel="preload" href="/diago/css/compiled/main.min.c1fe2c80102c9dc9ddc66184191e646769052d36a21b38ac5ab5077713cf7a81.css" as="style" integrity="sha256-wf4sgBAsncndxmGEGR5kZ2kFLTaiGzisWrUHdxPPeoE=" />
     <link href="/diago/css/compiled/main.min.c1fe2c80102c9dc9ddc66184191e646769052d36a21b38ac5ab5077713cf7a81.css" rel="stylesheet" integrity="sha256-wf4sgBAsncndxmGEGR5kZ2kFLTaiGzisWrUHdxPPeoE=" />
@@ -386,8 +386,6 @@ <h2>Audio playback<span class="hx-absolute -hx-mt-20" id="audio-playback"></span
 
   
 </div>
-<p>Output sample
-<img src="example_out_playback.png" alt="example_out" loading="lazy" /></p>
 <h2>Bridge media<span class="hx-absolute -hx-mt-20" id="bridge-media"></span>
     <a href="#bridge-media" class="subheading-anchor" aria-label="Permalink for this section"></a></h2><p>Run bridge app that always bridges with bob on port <code>5090</code></p>
 <div class="hextra-code-block hx-relative hx-mt-6 first:hx-mt-0 hx-group/code">
@@ -437,7 +435,6 @@ <h2>Bridge media<span class="hx-absolute -hx-mt-20" id="bridge-media"></span>
 
   
 </div>
-<p><img src="example_out_bridge.png" alt="example_out" loading="lazy" /></p>
 <h2>Upcomming!<span class="hx-absolute -hx-mt-20" id="upcomming"></span>
     <a href="#upcomming" class="subheading-anchor" aria-label="Permalink for this section"></a></h2><ul>
 <li>Read media directly</li>
diff --git a/en.search-data.json b/en.search-data.json
index 699f8e0..91bb186 100644
--- a/en.search-data.json
+++ b/en.search-data.json
@@ -1 +1 @@
-{"/diago/docs/":{"data":{"":"","why-diago#Why Diago?":"Development of VOIP services can be slow or it was full workarrounds. Diago try to offer more modern Stack and put you closer to protcol,network,media but offering High level and low level API calls.\nDiago is built with GO language and we are keeping well optimized sip and media stack to have performance and low GC latency. Major win is Go offers fast development speed and memory safety, but also tooling to tweak best performance.\nIn case you wondering is Go right language, there are already good benchmark results with just sipgo."},"title":"_index"},"/diago/docs/examples/":{"data":{"":"","audio-playback#Audio playback":"Run playback as server\ngo run ./examples/playback Dial in and you should hear audio on your speakers\ngophone dial -media=speaker sip:112@127.0.0.1 Output sample ","bridge-media#Bridge media":"Run bridge app that always bridges with bob on port 5090\ngo run ./examples/bridge sip:bob@127.0.0.1:5090 Run receiver:\ngophone answer -ua bob -l 127.0.0.1:5090 Dial server on 5060 be bridged with bob on 5090\ngophone dial -ua alice sip:bob@127.0.0.1:5060 ","cli-softphone-for-testing#CLI Softphone for testing":"For testing below scenarios, gophone as CLI softphone is used, but you can use any softphone you like Visit the page and install:\nhttps://github.com/emiago/gophone\nSource code of examples can be found in library. You will need go compiler installed","upcomming#Upcomming!":" Read media directly Recording "},"title":"Examples"},"/diago/docs/getting_started/":{"data":{"#":"Getting starteddiago can act as UAS(User Agent Server) and UAC(User Agent Client), and ofcourse adds bridging capability to build B2BUA services.\nTo keep abstractions low it intentionally distincts dialog received (Acting as server) and dialog created (Acting as client) Therefore it distincts your dialog/session control with this structs:\nDialogServerSession when receving incoming dialog (SIP INVITE) and setups session (media) DialogClientSession when it creates outgoing dialog (SIP INVITE) and setups session (media) Setup diago: ua, _ := sipgo.NewUA() transportUDP := diago.Transport{ Transport: \"udp\", BindHost: \"127.0.0.1\", BindPort: 5060, } transportTCP := diago.Transport{ Transport: \"tcp\", BindHost: \"127.0.0.1\", BindPort: 5060, } d := diago.NewDiago(ua, diago.WithTransport(transportUDP), diago.WithTransport(transportTCP), ) Incoming call d.Serve(ctx, func(inDialog *diago.DialogServerSession) { // - Do your call routing. switch inDialog.ToUser() { case \"answer\": case \"123456\" } }) Outgoing dialog, err := d.Invite(ctx, recipient sip.Uri, opts diago.InviteOptions) dialog.Hangup() ","answering-call#Answering call":" func Answer(inDialog *diago.DialogServerSession) { inDialog.Progress() // Progress -\u003e 100 Trying inDialog.Ringing() // Ringing -\u003e 180 Response if err := inDialog.Answer(); err != nil { fmt.Println(\"Failed to answer\", err) return } ctx := inDialog.Context() select { case \u003c-ctx.Done(): case \u003c-time.After(1 * time.Minute): } } ","getting-started#Getting started":"","playing-file-with-playback#Playing file with Playback":"Playing file is done by playback.\nSupported formats:\nwav (PCM) func Playback(inDialog *diago.DialogServerSession) { inDialog.Ringing() playfile, err := os.Open(\"demo-instruct.wav\") if err != nil { fmt.Println(\"Failed to open file\", err) return } pb, err := inDialog.PlaybackCreate() if err != nil { fmt.Println(\"Failed to create playback\", err) return } if err := inDialog.Answer(); err != nil { fmt.Println(\"Failed to answer\", err) return } if err := pb.Play(playfile, \"audio/wav\"); err != nil { fmt.Println(\"Playing failed\", err) } } "},"title":"getting_started"},"/diago/docs/guides/":{"data":{"":"Understanding VOIP can be a challenge for newcomers, but can it be simple and easier approach?\nVOIP is now mostly built with SIP. SIP is textual protocol same as HTTP so if you know HTTP reading SIP messages will be easy. It acts similar and has similar behavior (request/response) but focus is more on Session. With realtime media like audio/video there is always session after which it ends. Creating, Updating, Clossing this Session is something that SIP is designed\nTo understand and have good debug skills it is important to know how SIP works in different situations. Here I will try to provide some simple documentation to help you BUILDERS.\nNext: Understanding SIP with Call Scenarios"},"title":"Guides"},"/diago/docs/guides/sip_and_media/":{"data":{"":"","undestanding-sip-and-media#Undestanding SIP and media":"INVITE carries SDP (application/sdp) in body of message as offer to exlain media capabilites and connection setup. INVITE can have any other type in Body like HTTP, but SDP protocol is mainly used. More about this later\nAccepting(Answering) call is done by respondin with 200 OK\nResponse carries SDP in body as answer to explain callee’s media capabilites and connection.\nCall with media Here we will just explain most important things for media.\nWith SDP we explain our capabilites and protocol used for media and this mostly boils down to this 3 things:\nexplaining which codecs are supported for decoding (alaw,ulaw, opus, g722, …), protocol (RTP) and Listen IP where we expect incoming media (UDP) Client (Caller) and Server (Callee) both exchange SDP to explain their capabilites and Listening IP\nCodecs Codecs or in other words Formats are identified as numbers for audio. Ex:\n0 ulaw 8000Hz 8 alaw 8000Hz In SDP this will be shown as m=desc key. Ex:\nm=audio 49170 RTP/AVP 0\nDescription:\naudio: type of stream 49170: port on which is listening RTP/AVP: identifier for RTP protocol and AVP denotes as Audio Video 0: is codec identifier Listen IP Information and where device/use is listening for incoming media traffic c=IN IP4 198.51.100.1\nIP4 denotes IP version 4 is used NOTE: Publishing local IP like above is problem for NAT and there different approaches to solve this issue, but for now we will skip this part."},"title":"SIP and Media"},"/diago/docs/guides/understanding_sip/":{"data":{"":"","#":"Every call starts with INVITE SIP Messages. Here is how to relate SIP message to PHONE actions\nDialing = INVITE Answer = 200 OK response on INVITE Hangup = BYE Cancel = CANCEL Reject = 486 Busy INVITE is creating session which we call dialog.\nCaller (Client): Sends one time ACK as confirmation\nSuccesfull call Example of alice inviting bob\nINVITE sip:bob@127.0.0.1:5060 SIP/2.0 Via: SIP/2.0/udp 127.0.0.99:50725;branch=z9hG4bK.pgb382qZ312tyXIP Content-Type: application/sdp Content-Length: 235 Contact: \u003csip:alice@127.0.0.99:50725\u003e;transport=udp From: \"alice\" \u003csip:alice@127.0.0.99\u003e;tag=hImscoj6Jew8y6da To: \u003csip:bob@127.0.0.1\u003e Call-ID: 729cd7dd-96dc-419b-b339-327c60dfc2d7 CSeq: 1 INVITE Max-Forwards: 70 Succesfull call with provisional responses (More realistic) Call establishment can take a while, so provisional responses help with this.\nProvisional responses = 1xx and mostly you will see 100 and 180. 100 is used in HTTP as well, it just notifies client that request is accepted but it is in progress.\nAfter very quickly you may have Ringing, which indicates that end user device is reached and it is ringing.\nCanceling call with SIP CANCEL Caller cancels call by sending CANCEL msg. It contains mainly same headers as INVITE\nNOTE:\n200 OK is for CANCEL TO BE CONTINUED"},"title":"Understading SIP with Call Scenarios"}}
\ No newline at end of file
+{"/diago/docs/":{"data":{"":"","why-diago#Why Diago?":"Development of VOIP services can be slow or it was full workarrounds. Diago try to offer more modern Stack and put you closer to protcol,network,media but offering High level and low level API calls.\nDiago is built with GO language and we are keeping well optimized sip and media stack to have performance and low GC latency. Major win is Go offers fast development speed and memory safety, but also tooling to tweak best performance.\nIn case you wondering is Go right language, there are already good benchmark results with just sipgo."},"title":"_index"},"/diago/docs/examples/":{"data":{"":"","audio-playback#Audio playback":"Run playback as server\ngo run ./examples/playback Dial in and you should hear audio on your speakers\ngophone dial -media=speaker sip:112@127.0.0.1 ","bridge-media#Bridge media":"Run bridge app that always bridges with bob on port 5090\ngo run ./examples/bridge sip:bob@127.0.0.1:5090 Run receiver:\ngophone answer -ua bob -l 127.0.0.1:5090 Dial server on 5060 be bridged with bob on 5090\ngophone dial -ua alice sip:bob@127.0.0.1:5060 ","cli-softphone-for-testing#CLI Softphone for testing":"For testing below scenarios, gophone as CLI softphone is used, but you can use any softphone you like Visit the page and install:\nhttps://github.com/emiago/gophone\nSource code of examples can be found in library. You will need go compiler installed","upcomming#Upcomming!":" Read media directly Recording "},"title":"Examples"},"/diago/docs/getting_started/":{"data":{"#":"Getting starteddiago can act as UAS(User Agent Server) and UAC(User Agent Client), and ofcourse adds bridging capability to build B2BUA services.\nTo keep abstractions low it intentionally distincts dialog received (Acting as server) and dialog created (Acting as client) Therefore it distincts your dialog/session control with this structs:\nDialogServerSession when receving incoming dialog (SIP INVITE) and setups session (media) DialogClientSession when it creates outgoing dialog (SIP INVITE) and setups session (media) Setup diago: ua, _ := sipgo.NewUA() transportUDP := diago.Transport{ Transport: \"udp\", BindHost: \"127.0.0.1\", BindPort: 5060, } transportTCP := diago.Transport{ Transport: \"tcp\", BindHost: \"127.0.0.1\", BindPort: 5060, } d := diago.NewDiago(ua, diago.WithTransport(transportUDP), diago.WithTransport(transportTCP), ) Incoming call d.Serve(ctx, func(inDialog *diago.DialogServerSession) { // - Do your call routing. switch inDialog.ToUser() { case \"answer\": case \"123456\" } }) Outgoing dialog, err := d.Invite(ctx, recipient sip.Uri, opts diago.InviteOptions) dialog.Hangup() ","answering-call#Answering call":" func Answer(inDialog *diago.DialogServerSession) { inDialog.Progress() // Progress -\u003e 100 Trying inDialog.Ringing() // Ringing -\u003e 180 Response if err := inDialog.Answer(); err != nil { fmt.Println(\"Failed to answer\", err) return } ctx := inDialog.Context() select { case \u003c-ctx.Done(): case \u003c-time.After(1 * time.Minute): } } ","getting-started#Getting started":"","playing-file-with-playback#Playing file with Playback":"Playing file is done by playback.\nSupported formats:\nwav (PCM) func Playback(inDialog *diago.DialogServerSession) { inDialog.Ringing() playfile, err := os.Open(\"demo-instruct.wav\") if err != nil { fmt.Println(\"Failed to open file\", err) return } pb, err := inDialog.PlaybackCreate() if err != nil { fmt.Println(\"Failed to create playback\", err) return } if err := inDialog.Answer(); err != nil { fmt.Println(\"Failed to answer\", err) return } if err := pb.Play(playfile, \"audio/wav\"); err != nil { fmt.Println(\"Playing failed\", err) } } "},"title":"getting_started"},"/diago/docs/guides/":{"data":{"":"Understanding VOIP can be a challenge for newcomers, but can it be simple and easier approach?\nVOIP is now mostly built with SIP. SIP is textual protocol same as HTTP so if you know HTTP reading SIP messages will be easy. It acts similar and has similar behavior (request/response) but focus is more on Session. With realtime media like audio/video there is always session after which it ends. Creating, Updating, Clossing this Session is something that SIP is designed\nTo understand and have good debug skills it is important to know how SIP works in different situations. Here I will try to provide some simple documentation to help you BUILDERS.\nNext: Understanding SIP with Call Scenarios"},"title":"Guides"},"/diago/docs/guides/sip_and_media/":{"data":{"":"","undestanding-sip-and-media#Undestanding SIP and media":"INVITE carries SDP (application/sdp) in body of message as offer to exlain media capabilites and connection setup. INVITE can have any other type in Body like HTTP, but SDP protocol is mainly used. More about this later\nAccepting(Answering) call is done by respondin with 200 OK\nResponse carries SDP in body as answer to explain callee’s media capabilites and connection.\nCall with media Here we will just explain most important things for media.\nWith SDP we explain our capabilites and protocol used for media and this mostly boils down to this 3 things:\nexplaining which codecs are supported for decoding (alaw,ulaw, opus, g722, …), protocol (RTP) and Listen IP where we expect incoming media (UDP) Client (Caller) and Server (Callee) both exchange SDP to explain their capabilites and Listening IP\nCodecs Codecs or in other words Formats are identified as numbers for audio. Ex:\n0 ulaw 8000Hz 8 alaw 8000Hz In SDP this will be shown as m=desc key. Ex:\nm=audio 49170 RTP/AVP 0\nDescription:\naudio: type of stream 49170: port on which is listening RTP/AVP: identifier for RTP protocol and AVP denotes as Audio Video 0: is codec identifier Listen IP Information and where device/use is listening for incoming media traffic c=IN IP4 198.51.100.1\nIP4 denotes IP version 4 is used NOTE: Publishing local IP like above is problem for NAT and there different approaches to solve this issue, but for now we will skip this part."},"title":"SIP and Media"},"/diago/docs/guides/understanding_sip/":{"data":{"":"","#":"Every call starts with INVITE SIP Messages. Here is how to relate SIP message to PHONE actions\nDialing = INVITE Answer = 200 OK response on INVITE Hangup = BYE Cancel = CANCEL Reject = 486 Busy INVITE is creating session which we call dialog.\nCaller (Client): Sends one time ACK as confirmation\nSuccesfull call Example of alice inviting bob\nINVITE sip:bob@127.0.0.1:5060 SIP/2.0 Via: SIP/2.0/udp 127.0.0.99:50725;branch=z9hG4bK.pgb382qZ312tyXIP Content-Type: application/sdp Content-Length: 235 Contact: \u003csip:alice@127.0.0.99:50725\u003e;transport=udp From: \"alice\" \u003csip:alice@127.0.0.99\u003e;tag=hImscoj6Jew8y6da To: \u003csip:bob@127.0.0.1\u003e Call-ID: 729cd7dd-96dc-419b-b339-327c60dfc2d7 CSeq: 1 INVITE Max-Forwards: 70 Succesfull call with provisional responses (More realistic) Call establishment can take a while, so provisional responses help with this.\nProvisional responses = 1xx and mostly you will see 100 and 180. 100 is used in HTTP as well, it just notifies client that request is accepted but it is in progress.\nAfter very quickly you may have Ringing, which indicates that end user device is reached and it is ringing.\nCanceling call with SIP CANCEL Caller cancels call by sending CANCEL msg. It contains mainly same headers as INVITE\nNOTE:\n200 OK is for CANCEL TO BE CONTINUED"},"title":"Understading SIP with Call Scenarios"}}
\ No newline at end of file