<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Thanks all for the suggestions.<br>
<br>
@Charles<br>
Yes that is correct, that is the scenario that is occurring, we are
using asterisk, when a call is initiated via asterisk 1, the second
call then routes through to asterisk 2, asterisk 1 then gets the
REFER but doesn't know about the 2nd call.<br>
<br>
@Reda<br>
I like this option of using the hash table (I'd like to exclude a
database lookup for each initial invite), however, would I be forced
to use a database in the case of 2 loadbalancers, surely some shared
state would need to exist between the loadbalancers to make this
decision on where to route the call if it already exists. I suspect
the hashtable suggestion may work perfectly in a single loadbalancer
scenario, unless I'm missing something. For example, the initialy
call may go via loadbalancer 1 however the second call may go
through loadbalancer 2, that way loadbalancer 2 may not know of an
existing call already been setup.<br>
<br>
In keeping with the hashtable train of thought, is it really
neccessary to keep a reference to the callid, as the second call in
the transfer scenario described by Charles, the callid of the second
call is different to the original call.<br>
<br>
Just as an FYI, I am currently using dispatcher algorithm 0 which is
a hash over callid.<br>
<br>
Thanks again all for the suggestions/tips<br>
<br>
<br>
On 26/04/12 16:12, Charles Chance wrote:
<blockquote cite="mid:E1SNQNm-0005U6-AI@www.kamailio.org"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 11 (filtered
medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:smarttagtype
namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="State">
<o:smarttagtype
namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="country-region">
<o:smarttagtype
namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="place">
<o:smarttagtype
namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="PersonName">
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:blue;
text-decoration:underline;}
p
{mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:Arial;
color:navy;}
@page Section1
{size:595.3pt 841.9pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
{page:Section1;}
-->
</style>
<div class="Section1">
<p class="MsoNormal"><font color="navy" face="Arial"
size="2"><span style="font-size:
10.0pt;font-family:Arial;color:navy">Yes, I
realise Asterisk is not a media
relay, but I don’t think the OP is using a pure
media relay, otherwise
the REFER message would not be sent to it, would
it?<o:p></o:p></span></font></p>
<p class="MsoNormal"><font color="navy" face="Arial"
size="2"><span style="font-size:
10.0pt;font-family:Arial;color:navy"><o:p> </o:p></span></font></p>
<p class="MsoNormal"><font color="navy" face="Arial"
size="2"><span style="font-size:
10.0pt;font-family:Arial;color:navy">Thank you for
the hash table suggestion by
the way.<o:p></o:p></span></font></p>
<p class="MsoNormal"><font color="navy" face="Arial"
size="2"><span style="font-size:
10.0pt;font-family:Arial;color:navy"><o:p> </o:p></span></font></p>
<p class="MsoNormal"><font color="navy" face="Arial"
size="2"><span style="font-size:
10.0pt;font-family:Arial;color:navy">Charles<o:p></o:p></span></font></p>
<p class="MsoNormal"><font color="navy" face="Arial"
size="2"><span style="font-size:
10.0pt;font-family:Arial;color:navy"><o:p> </o:p></span></font></p>
<div>
<div class="MsoNormal" style="text-align:center"
align="center"><font face="Times New Roman" size="3"><span
style="font-size:12.0pt" lang="EN-US">
<hr tabindex="-1" align="center" size="2"
width="100%">
</span></font></div>
<p class="MsoNormal"><b><font face="Tahoma" size="2"><span
style="font-size:10.0pt;font-family:Tahoma;font-weight:bold"
lang="EN-US">From:</span></font></b><font
face="Tahoma" size="2"><span
style="font-size:10.0pt;font-family:Tahoma"
lang="EN-US">
<a class="moz-txt-link-abbreviated" href="mailto:sr-users-bounces@lists.sip-router.org">sr-users-bounces@lists.sip-router.org</a>
[<a class="moz-txt-link-freetext" href="mailto:sr-users-bounces@lists.sip-router.org">mailto:sr-users-bounces@lists.sip-router.org</a>] <b><span
style="font-weight:
bold">On Behalf Of </span></b>Reda Aouad<br>
<b><span style="font-weight:bold">Sent:</span></b>
26 April 2012 15:15<br>
<b><span style="font-weight:bold">To:</span></b>
<st1:personname w:st="on">SIP Router - Kamailio</st1:personname>
(OpenSER) and SIP Express Router (SER) -
UsersMailing List<br>
<b><span style="font-weight:bold">Subject:</span></b>
Re: [SR-Users] dispatcher
and call transfer</span></font><span
lang="EN-US"><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><font face="Times New Roman"
size="3"><span style="font-size:
12.0pt"><o:p> </o:p></span></font></p>
<div>
<p class="MsoNormal"><font color="#3366ff"
face="Tahoma" size="3"><span
style="font-size:12.0pt;font-family:Tahoma;color:#3366FF">Asterisk
is not
really a media relay. Asterisk establishes 2
legs for each call, and I'm not
sure what happens in this case.<br>
<br>
An improvement you can make is to use a hash
table (in-memory) to store the
information you need (call-id, from, to) then
lookup in <br>
the htable for existing calls for same users.
That should relieve your database
from a query on every invite and increase
performance if you have a large
number of calls.<br clear="all">
</span></font><o:p></o:p></p>
<div>
<p class="MsoNormal"><font face="Times New Roman"
size="3"><span style="font-size:
12.0pt"><o:p> </o:p></span></font></p>
<div>
<p class="MsoNormal"><font color="#3366ff"
face="Tahoma" size="3"><span
style="font-size:12.0pt;font-family:Tahoma;color:#3366FF">Reda</span></font><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><font face="Times New Roman"
size="3"><span style="font-size:
12.0pt"><o:p> </o:p></span></font></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><font
face="Times New Roman" size="3"><span
style="font-size:12.0pt"><o:p> </o:p></span></font></p>
<div>
<p class="MsoNormal"><font face="Times New Roman"
size="3"><span style="font-size:
12.0pt">On Thu, Apr 26, 2012 at 15:52,
Charles Chance <<a moz-do-not-send="true"
href="mailto:charles.chance@sipcentric.com" target="_blank">charles.chance@sipcentric.com</a>>
wrote:<o:p></o:p></span></font></p>
<div link="blue" vlink="blue">
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><font
color="navy" face="Arial" size="2"><span
style="font-size:10.0pt;font-family:Arial;
color:navy">Hi Reda,</span></font><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><font
color="navy" face="Arial" size="2"><span
style="font-size:10.0pt;font-family:Arial;
color:navy"> </span></font><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><font
color="navy" face="Arial" size="2"><span
style="font-size:10.0pt;font-family:Arial;
color:navy">Sorry, I should have been
more specific – I am referring to
instances where the media server is for
example Asterisk. If first call goes
through Asterisk 1, second call goes
through Asterisk 2, when Asterisk 2
receives the REFER it does not know of
initial call on Asterisk 1. The only way
we have found for it to work is to
ensure the second call is dispatched to
the
same Asterisk box as the first.</span></font><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><font
color="navy" face="Arial" size="2"><span
style="font-size:10.0pt;font-family:Arial;
color:navy"> </span></font><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><font
color="navy" face="Arial" size="2"><span
style="font-size:10.0pt;font-family:Arial;
color:navy">I would be pleased to hear
of an alternative method.</span></font><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><font
color="navy" face="Arial" size="2"><span
style="font-size:10.0pt;font-family:Arial;
color:navy"> </span></font><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><font
color="navy" face="Arial" size="2"><span
style="font-size:10.0pt;font-family:Arial;
color:navy">Regards,</span></font><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><font
color="navy" face="Arial" size="2"><span
style="font-size:10.0pt;font-family:Arial;
color:navy"> </span></font><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><font
color="navy" face="Arial" size="2"><span
style="font-size:10.0pt;font-family:Arial;
color:navy">Charles</span></font><o:p></o:p></p>
<div>
<div class="MsoNormal"
style="text-align:center" align="center"><font
face="Times New Roman" size="3"><span
style="font-size:12.0pt" lang="EN-US">
<hr align="center" size="2"
width="100%">
</span></font></div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><font
face="Tahoma" size="2"><span
style="font-size:10.0pt;font-family:Tahoma;
font-weight:bold" lang="EN-US">From:</span></font></b><font
face="Tahoma" size="2"><span
style="font-size:10.0pt;font-family:Tahoma"
lang="EN-US"> <a
moz-do-not-send="true"
href="mailto:sr-users-bounces@lists.sip-router.org"
target="_blank">sr-users-bounces@lists.sip-router.org</a>
[mailto:<a moz-do-not-send="true"
href="mailto:sr-users-bounces@lists.sip-router.org"
target="_blank">sr-users-bounces@lists.sip-router.org</a>]
<b><span style="font-weight:bold">On
Behalf Of </span></b>Reda Aouad<br>
<b><span style="font-weight:bold">Sent:</span></b>
26 April 2012 14:34</span></font><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><font face="Tahoma"
size="3"><span
style="font-size:12.0pt;
font-family:Tahoma"><br>
<b><span style="font-weight:bold">To:</span></b>
<st1:personname w:st="on">SIP
Router - Kamailio</st1:personname>
(OpenSER) and SIP Express Router
(SER) -
UsersMailing List<br>
<b><span style="font-weight:bold">Subject:</span></b>
Re: [SR-Users] dispatcher
and call transfer</span></font><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><font
face="Times New Roman" size="3"><span
style="font-size:12.0pt"> <o:p></o:p></span></font></p>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><font
color="#3366ff" face="Tahoma"
size="3"><span
style="font-size:12.0pt;font-family:
Tahoma;color:#3366FF">Hi,<br>
<br>
@Carsten<br>
Dispatcher algorithm 0 based on
call-id should do it in your case
of re-invite
within dialog with same call-id.<br>
<br>
@Charles<br>
In the case of attended transfers,
shouldn't both media servers be
relaying
media between them? I didn't
understand why your are obliged to
dispatch to the
same media server since they are 2
different calls with different
call-ids.</span></font><o:p></o:p></p>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><font
face="Times New Roman" size="3"><span
style="font-size:12.0pt"> <o:p></o:p></span></font></p>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><font
color="#3366ff" face="Tahoma"
size="3"><span
style="font-size:12.0pt;font-family:
Tahoma;color:#3366FF">Reda</span></font><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><font
face="Times New Roman" size="3"><span
style="font-size:12.0pt"> <o:p></o:p></span></font></p>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><font
face="Times New Roman" size="3"><span
style="font-size:12.0pt"> <o:p></o:p></span></font></p>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><font
face="Times New Roman" size="3"><span
style="font-size:12.0pt">On
Thu, Apr 26,
2012 at 14:30, Charles Chance
<<a moz-do-not-send="true"
href="mailto:charles.chance@sipcentric.com" target="_blank">charles.chance@sipcentric.com</a>>
wrote:<o:p></o:p></span></font></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><font
face="Times New Roman" size="3"><span
style="font-size:12.0pt">Hi,<br>
<br>
Actually, this won't help for
attended transfers where
another call is<br>
initiated first then the two
are joined together by REFER.
In this case, the<br>
second INVITE must be routed
to the same media server as
the existing call<br>
for the transfer to work.<br>
<br>
What we do is store the
dialogs in DB, then when a new
call comes in, prior<br>
to doing ds_select_dst we
query DB for existing call
involving same user. If<br>
we find one, we simply replace
destination host with that
from the contact<br>
(to/from depending on
direction of call).<br>
<br>
It may not be the most elegant
way but it works for us :)<br>
<br>
Charles<o:p></o:p></span></font></p>
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><font
face="Times New Roman"
size="3"><span
style="font-size:12.0pt"><br>
<br>
-----Original Message-----<br>
From: <a
moz-do-not-send="true"
href="mailto:sr-users-bounces@lists.sip-router.org"
target="_blank">sr-users-bounces@lists.sip-router.org</a><br>
[mailto:<a
moz-do-not-send="true"
href="mailto:sr-users-bounces@lists.sip-router.org"
target="_blank">sr-users-bounces@lists.sip-router.org</a>]
On Behalf Of Carsten Bock<br>
Sent: 26 April 2012 13:25<br>
To: <st1:personname
w:st="on">SIP Router -
Kamailio</st1:personname>
(OpenSER)
and SIP Express Router
(SER) -<br>
UsersMailing List<br>
Subject: Re: [SR-Users]
dispatcher and call
transfer<br>
<br>
Hi,<br>
<br>
if you look at the docs of
the dispatcher module,
you'll find this:<br>
<br>
alg - the algorithm used
to select the destination
address. The<br>
parameter can be an
integer or a variable
holding an interger.<br>
- “0” - hash over callid<br>
(<a moz-do-not-send="true"
href="http://kamailio.org/docs/modules/devel/modules_k/dispatcher.html#id2498492"
target="_blank">http://kamailio.org/docs/modules/devel/modules_k/dispatcher.html#id2498492</a>)<br>
<br>
But probably you should
look into
record/loose_route for
your setup.<br>
Since REFER is normally an
in-dialog request (belongs
to another<br>
voice-session), it should
take the same route as the
initial INVITE.<br>
This is normally achieved
by the record/loose-route
mechanisms<br>
described in RFC3261.<br>
In the example config of
Kamailio you find an
configuration example
(below).<br>
<br>
It is not a bug in the
dispatcher module, it's
how you use it.<br>
<br>
So long,<br>
Carsten<br>
<br>
455 # handle
requests within SIP
dialogs<br>
456
route(WITHINDLG);<br>
<br>
[...]<br>
<br>
473 # record
routing for dialog forming
requests (in case<br>
they are routed)<br>
474 # - remove
preloaded route headers<br>
475
remove_hf("Route");<br>
476 if
(is_method("INVITE|SUBSCRIBE"))<br>
477
record_route();<br>
<br>
and the relevent parts in
the "WITHINDLG" route:<br>
<br>
566 # Handle requests
within SIP dialogs<br>
567 route[WITHINDLG] {<br>
568 if
(has_totag()) {<br>
569 #
sequential
request withing a dialog
should<br>
570 #
take the
path determined by
record-routing<br>
571 if
(loose_route()) {<br>
[...]<br>
580
route(RELAY);<br>
581 }
else {<br>
[...]<br>
587
if ( is_method("ACK")
) {<br>
588
if (
t_check_trans() ) {<br>
589
# no
loose-route, but stateful<br>
ACK;<br>
590
# must
be
an ACK after a 487<br>
591
# or
e.g.
404 from upstream<br>
server<br>
592
t_relay();<br>
593
exit;<br>
594
} else {<br>
595
# ACK
without matching<br>
transaction ... ignore and
discard<br>
596
exit;<br>
597
}<br>
598
}<br>
599
sl_send_reply("404","Not
here");<br>
600 }<br>
601 exit;<br>
602 }<br>
603 }<br>
<br>
2012/4/26 Asgaroth <<a
moz-do-not-send="true"
href="mailto:00asgaroth00@gmail.com"
target="_blank">00asgaroth00@gmail.com</a>>:<br>
> Hi All,<br>
><br>
> Currently we are
running kamailio in a
loadbalanced fashion
whereby calls<br>
> come in via the
loadbalancers and
distribute calls accross 2
media<br>
servers.<br>
> We have come accross
and issue whereby call
transfers may be
distributed<br>
> accross two media
servers and when the REFER
message comes along to<br>
transfer<br>
> the call, in some
cases (if we're lucky) the
message arrives at the
wrong<br>
> media server
(transaction leg doesnt
exist).<br>
><br>
> Some googling later
and it appears that
dispatcher doesnt play
nice when<br>
it<br>
> comes to this
scenario. Some suggestions
popped up in my previous
searches<br>
> saying that a
potential work around is
to use the dialog module
to check<br>
if<br>
> a call is
eastablished and then to
send all calls to the same
media server<br>
> based on the dialog
already being established.<br>
><br>
> I'd appreciate some
input from the guru's out
there that have come
accross<br>
> this same issue and,
if possible, some
suggestions on how to work
around<br>
the<br>
> problem, does the
dispatcher module have a
hashing algorithm that can
be<br>
> suited for this
particular scenario?<br>
><br>
> Thanks in advance for
any tips or sugestions.<br>
><br>
>
_______________________________________________<br>
> SIP Express Router
(SER) and Kamailio
(OpenSER) - sr-users
mailing list<br>
> <a
moz-do-not-send="true"
href="mailto:sr-users@lists.sip-router.org"
target="_blank">sr-users@lists.sip-router.org</a><br>
> <a
moz-do-not-send="true"
href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users"
target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
><br>
<br>
<br>
<br>
--<br>
Carsten Bock<br>
CEO (Geschäftsführer)<br>
<br>
ng-voice GmbH<br>
Schomburgstr. 80<br>
D-22767 <st1:state
w:st="on">Hamburg</st1:state>
/ <st1:country-region
w:st="on"><st1:place
w:st="on">Germany</st1:place></st1:country-region><br>
<br>
<a moz-do-not-send="true"
href="http://www.ng-voice.com" target="_blank">http://www.ng-voice.com</a><br>
mailto:<a
moz-do-not-send="true"
href="mailto:carsten@ng-voice.com"
target="_blank">carsten@ng-voice.com</a><br>
<br>
Mobile <a
moz-do-not-send="true"
href="tel:%2B49%20179%202021244"
target="_blank"
value="+491792021244">+49
179
2021244</a><br>
Office <a
moz-do-not-send="true"
href="tel:%2B49%2040%2034927219"
target="_blank"
value="+494034927219">+49
40
34927219</a><br>
Fax <a
moz-do-not-send="true"
href="tel:%2B49%2040%2034927220"
target="_blank"
value="+494034927220">+49
40
34927220</a><br>
<br>
Sitz der Gesellschaft: <st1:state
w:st="on"><st1:place
w:st="on">Hamburg</st1:place></st1:state><br>
Registergericht:
Amtsgericht <st1:state
w:st="on"><st1:place
w:st="on">Hamburg</st1:place></st1:state>,
HRB 120189<br>
Geschäftsführer: Carsten
Bock<br>
Ust-ID: DE279344284<br>
<br>
Hier finden Sie unsere
handelsrechtlichen
Pflichtangaben:<br>
<a moz-do-not-send="true"
href="http://www.ng-voice.com/imprint/" target="_blank">http://www.ng-voice.com/imprint/</a><br>
<br>
--<br>
Meet ng-voice at LinuxTag
2012 in <st1:state
w:st="on"><st1:place
w:st="on">Berlin</st1:place></st1:state>
- May 23rd - 26th, 2012.
Save the<br>
date!<br>
<br>
_______________________________________________<br>
SIP Express Router (SER)
and Kamailio (OpenSER) -
sr-users mailing list<br>
<a moz-do-not-send="true"
href="mailto:sr-users@lists.sip-router.org" target="_blank">sr-users@lists.sip-router.org</a><br>
<a moz-do-not-send="true"
href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users"
target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><o:p></o:p></span></font></p>
</div>
</div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><font
face="Times New Roman" size="3"><span
style="font-size:12.0pt">-----<br>
No virus found in this
message.<br>
Checked by AVG - <a
moz-do-not-send="true"
href="http://www.avg.com"
target="_blank">www.avg.com</a><br>
Version: 2012.0.1913 / Virus
Database: 2411/4959 - Release
Date: 04/25/12<o:p></o:p></span></font></p>
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><font
face="Times New Roman"
size="3"><span
style="font-size:12.0pt"><br>
<br>
_______________________________________________<br>
SIP Express Router (SER)
and Kamailio (OpenSER) -
sr-users mailing list<br>
<a moz-do-not-send="true"
href="mailto:sr-users@lists.sip-router.org" target="_blank">sr-users@lists.sip-router.org</a><br>
<a moz-do-not-send="true"
href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users"
target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><o:p></o:p></span></font></p>
</div>
</div>
</div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><font
face="Times New Roman" size="3"><span
style="font-size:12.0pt"> <o:p></o:p></span></font></p>
</div>
</div>
</div>
</div>
<div class="MsoNormal"
style="text-align:center" align="center"><font
face="Times New Roman" size="3"><span
style="font-size:12.0pt">
<hr align="center" color="#a0a0a0"
noshade="noshade" size="1"
width="100%">
</span></font></div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"
color="#000000"><font face="Times New
Roman" size="3"><span style="font-size:
12.0pt">No virus found in this
message.<br>
Checked by AVG - <a
moz-do-not-send="true"
href="http://www.avg.com"
target="_blank">www.avg.com</a><br>
Version: 2012.0.1913 / Virus Database:
2411/4959 - Release Date: 04/25/12<o:p></o:p></span></font></p>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><font
face="Times New Roman" size="3"><span
style="font-size:12.0pt"><br>
_______________________________________________<br>
SIP Express Router (SER) and Kamailio
(OpenSER) - sr-users mailing list<br>
<a moz-do-not-send="true"
href="mailto:sr-users@lists.sip-router.org"
target="_blank">sr-users@lists.sip-router.org</a><br>
<a moz-do-not-send="true"
href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users"
target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><o:p></o:p></span></font></p>
</div>
<p class="MsoNormal"><font face="Times New Roman"
size="3"><span style="font-size:
12.0pt"><o:p> </o:p></span></font></p>
</div>
</div>
<div class="MsoNormal" style="text-align:center"
align="center"><font face="Times New Roman" size="3"><span
style="font-size:12.0pt">
<hr align="center" color="#a0a0a0"
noshade="noshade" size="1" width="100%">
</span></font></div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"
color="#000000"><font face="Times New Roman" size="3"><span
style="font-size:
12.0pt">No virus found in this message.<br>
Checked by AVG - <a moz-do-not-send="true"
href="http://www.avg.com">www.avg.com</a><br>
Version: 2012.0.1913 / Virus Database: 2411/4959 -
Release Date: 04/25/12<o:p></o:p></span></font></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a>
<a class="moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</o:smarttagtype></o:smarttagtype></o:smarttagtype></o:smarttagtype></blockquote>
<br>
</body>
</html>