[sr-dev] git:master: SL doc: fix typos
Olle E. Johansson
oej at edvina.net
Sun Oct 14 18:03:18 CEST 2012
Module: sip-router
Branch: master
Commit: 4c45f67a42ea76c909893bd684cac03fde8d5c2b
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=4c45f67a42ea76c909893bd684cac03fde8d5c2b
Author: Olle E. Johansson <oej at edvina.net>
Committer: Olle E. Johansson <oej at edvina.net>
Date: Sun Oct 14 18:02:45 2012 +0200
SL doc: fix typos
---
modules/sl/README | 29 +++++++++++++++--------------
modules/sl/doc/functions.xml | 4 ++--
modules/sl/doc/sl.xml | 18 +++++++++---------
3 files changed, 26 insertions(+), 25 deletions(-)
diff --git a/modules/sl/README b/modules/sl/README
index 19ae7b6..03f8d26 100644
--- a/modules/sl/README
+++ b/modules/sl/README
@@ -53,10 +53,10 @@ Daniel-Constantin Mierla
1.1. Overview
- The SL module allows ser to act as a stateless UA server and generate
- replies to SIP requests without keeping state. That is beneficial in
- many scenarios, in which you wish not to burden server's memory and
- scale well.
+ The SL module allows the SIP server to act as a stateless UA server and
+ generate replies to SIP requests without keeping state. That is
+ beneficial in many scenarios, in which you wish not to burden server's
+ memory and scale well.
The SL module needs to filter ACKs sent after a local stateless reply
to an INVITE was generated. To recognize such ACKs, ser adds a special
@@ -64,17 +64,18 @@ Daniel-Constantin Mierla
and if included, the ACKs are absorbed.
To speed up the filtering process, the module uses a timeout mechanism.
- When a reply is sent, a timer us set. As time as the timer is valid,
- The incoming ACK requests will be checked using TO tag value Once the
- timer expires, all the ACK are let through - a long time passed till it
- sent a reply, so it does not expect any ACK that have to be blocked.
+ When a reply is sent, a timer us set. As long as the timer is valid,
+ the incoming ACK requests will be checked using TO tag value. Once the
+ timer expires, all the ACK messages are let through - a long time
+ passed till it sent a reply, so it does not expect any ACK that have to
+ be blocked.
The ACK filtering may fail in some rare cases. If you think these
- matter to you, better use stateful processing (tm module) for INVITE
+ matter to you, better use stateful processing (TM module) for INVITE
processing. Particularly, the problem happens when a UA sends an INVITE
- which already has a to-tag in it (e.g., a re-INVITE) and SER want to
- reply to it. Than, it will keep the current to-tag, which will be
- mirrored in ACK. SER will not see its signature and forward the ACK
+ which already has a to-tag in it (e.g., a re-INVITE) and the server
+ want to reply to it. Then, it will keep the current to-tag, which will
+ be mirrored in ACK. SER will not see its signature and forward the ACK
downstream. Caused harm is not bad--just a useless ACK is forwarded.
1.2. Parameters
@@ -134,8 +135,8 @@ sl_send_reply("404", "Not found");
For the current request, a reply is sent back having the given code and
text reason. The reply is sent stateful or stateless, depending of the
- TM module: if the transaction for current request is created, then the
- reply is sent stateful, otherwise stateless.
+ TM module: if a transaction exists for the current request, then the
+ reply is sent statefully, otherwise stateless.
Meaning of the parameters is as follows:
* code - Return code.
diff --git a/modules/sl/doc/functions.xml b/modules/sl/doc/functions.xml
index 2cfe4d9..63abcb6 100644
--- a/modules/sl/doc/functions.xml
+++ b/modules/sl/doc/functions.xml
@@ -44,8 +44,8 @@ sl_send_reply("404", "Not found");
<para>
For the current request, a reply is sent back having the given code
and text reason. The reply is sent stateful or stateless, depending of
- the TM module: if the transaction for current request is
- created, then the reply is sent stateful, otherwise stateless.
+ the <acronym>TM</acronym> module: if a transaction exists for the current
+ request, then the reply is sent statefully, otherwise stateless.
</para>
<para>Meaning of the parameters is as follows:</para>
<itemizedlist>
diff --git a/modules/sl/doc/sl.xml b/modules/sl/doc/sl.xml
index 5be9974..4b5a402 100644
--- a/modules/sl/doc/sl.xml
+++ b/modules/sl/doc/sl.xml
@@ -33,7 +33,7 @@
<section id="sl.overview">
<title>Overview</title>
<para>
- The <acronym>SL</acronym> module allows ser to act as a stateless
+ The <acronym>SL</acronym> module allows the SIP server to act as a stateless
UA server and generate replies to SIP requests without keeping
state. That is beneficial in many scenarios, in which you wish not
to burden server's memory and scale well.
@@ -47,18 +47,18 @@
</para>
<para>
To speed up the filtering process, the module uses a timeout
- mechanism. When a reply is sent, a timer us set. As time as the
- timer is valid, The incoming ACK requests will be checked using TO
- tag value Once the timer expires, all the ACK are let through - a
- long time passed till it sent a reply, so it does not expect any
- ACK that have to be blocked.
+ mechanism. When a reply is sent, a timer us set. As long as the
+ timer is valid, the incoming ACK requests will be checked using TO
+ tag value. Once the timer expires, all the ACK messages are let
+ through - a long time passed till it sent a reply, so it does not
+ expect any ACK that have to be blocked.
</para>
<para>
The ACK filtering may fail in some rare cases. If you think these
- matter to you, better use stateful processing (tm module) for
- INVITE processing. Particularly, the problem happens when a UA
+ matter to you, better use stateful processing (<acronym>TM</acronym>
+ module) for INVITE processing. Particularly, the problem happens when a UA
sends an INVITE which already has a to-tag in it (e.g., a
- re-INVITE) and SER want to reply to it. Than, it will keep the
+ re-INVITE) and the server want to reply to it. Then, it will keep the
current to-tag, which will be mirrored in ACK. SER will not see
its signature and forward the ACK downstream. Caused harm is not
bad--just a useless ACK is forwarded.
More information about the sr-dev
mailing list