<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
I'm going to try to explain this to Jiri and the list. I've changed
the subject since it will diverge from the original.<br>
<br>
What we're trying to do is set something up in SER which allows a
single URI/phone # to be called, and have it ring multiple user's
phones, which, if they go unanswered, will go to the original dialed
user's voice mail box (which is a 'common' VM account that multiple
users have access to). It also needs to be flexible in that any user
can put themselves on and
take themselves off the 'list' of users whose phones will ring when
this number is dialed. And lastly, but not leastly, it also needs to
be very user friendly, so users with no knowledge of SER/SIP can
add/remove themselves from this list.<br>
<br>
I'd like to do this with as little custom programming as possible.
Preferably, none. I've been trying to get this working with
SER/SERWeb/Asterisk/SEMS "natively". I realize this may not be
possible without some coding, and that SER wasn't meant to do
everything every user wanted 'out of the box' without coding, etc.<br>
<br>
The main problem is, with the current setup of SEMS/SERWeb, and the
current examples of voice mail setup, there is a presumption that the
original called URI is the same person, and rings one or more of this
same person's phones. But as explained above, we want to dial one
user, and have it actually ring a bunch of other users phones, which
can change dynamically.<br>
<br>
The simplest way to implement this is to have whoever wants to receive
the calls have their phones register themselves as the "main" user.
This actually works fine with existing setups. The problem with this
is that it's not very user friendly or practical, since not all SIP
phones allow multiple user registration, which would require each user
who wants to do this to have a separate phone reserved for this
purpose. It's also somewhat inconvenient for a user with multiple
phones to add/remove themselves from the registration for this "main"
user on every phone every time they need to do it (like when they go to
lunch, etc). It's far nicer for a user to be able to log into a
central location and add their personal URI there, and have their
already registered phones ring. I've though of hacking SERWeb and
adding some functionality which would look up the users' current
contacts in location and simply add them to the "main" user's contact
list, but then realized that they'd have to update this every time they
turned off a phone, added a new phone, etc. <br>
<br>
We tried doing this by having the users register their contacts via
SERWeb by logging into the "main" user's account and adding contacts
like <a class="moz-txt-link-rfc2396E" href="mailto:user1@domain.tld">"user1@domain.tld"</a>, <a class="moz-txt-link-rfc2396E" href="mailto:user2@domain.tld">"user2@domain.tld"</a>. I call these sorts of
locations entries "indirect contacts", since they're not destined for a
different SIP domain, but they're also not pointing at the users'
phones. Instead, they point back at other SER location entries which
in turn point to the actual phones (hence, indirect). They wind up
causing SER to relay the call back to itself. Example:
<a class="moz-txt-link-abbreviated" href="mailto:main@domain.tld">main@domain.tld</a> -> <a class="moz-txt-link-abbreviated" href="mailto:user1@domain.tld">user1@domain.tld</a> ->
user1@<phoneIP:port>. These sorts of location entries would
actually work for ringing the phones, etc, but would fail when it timed
out to voice mail, for reasons both clear and unclear when the SIP
messages were analyzed.<br>
<br>
Analyzing the SIP messages, the failure reasons varied depending on
whether there was a single contact, multiple contacts, and which
"time-out method" was used, etc. For the case of multiple contacts,
the routing logic wound up doing multiple failure_routes for voice mail
for the same phone call, etc, which is bad. If there was a single
contact, and we were using the failure_route method of timing out, SER
would send a CANCEL message to the VM system within a second of issuing
the INVITE from the added VM branch (as if it couldn't differentiate
between the original URI, indirect contact, and final contact branches
of the call, and the added VM branch, or was simply choosing the wrong
ones to CANCEL). <br>
<br>
However, if the "have Asterisk wait" method of timing out were used
with a single contact, SER would be fine and the call would be answered
by the VM system (unfortunately not for the original URI user, but for
the "ringing phone" user, which makes sense when the routing logic is
examined). If the call involved multiple contacts, this method would
fail, not because of SER, but because Asterisk would misinterpret SER's
CANCEL message for one user for another, and stop responding to the
call it just issued an OK for. This is likely because a double INVITE
was issued (for each branch of the final destination set), and confused
Asterisk.<br>
<br>
The problem is, for this sort of set up is that there's no easy
'native' way to 'mark' the particular original URI, and resulting
indirect URIs for the special treatment by the routing logic without
hard coding them into ser.cfg, or using exec_dset() and some other of
database of special users, etc, for which their would need to be a UI
front end written (and which could be an expensive operation because of
the "exec_dset").<br>
<br>
The new approach I'm implementing right now is to use special prefixes
for these types of users so that SER will treat them differently in the
routing logic, and "do the proper thing". I'm hoping this will result
in SER keeping its cookies, etc, and CANCELing the right calls when VM
picks up.<br>
<br>
Another stumbling block I see already is the case of handling "indirect
contacts" which don't have a final location entry. E.g., the user
logged out of the SIP domain, but didn't remove his indirect contact
entry. When SER relays the call back to itself, and goes to lookup the
location, it won't find one and normally it'd issue a "404". The
desired action in this case is to forget about that particular contact,
and just ring any other contacts that exist without having it tear down
the entire call, or instantly shunt it off to voice mail (unless of
course, there are no 'final contacts' available to ring). Tricky,
especially since I'm still learning all this stuff.<br>
<br>
Hopefully this will explain what I'm trying to do, the problems I've
been having, etc. Perhaps I'm taking a completely wrong approach and
someone will just say "just do it this way dummy!". :-)<br>
<br>
- Jim<br>
<br>
<br>
Jiri Kuthan wrote:<br>
<blockquote type="cite"
cite="mid6.0.1.1.0.20031220105848.01cdc550@localhost">
<pre wrap="">At 02:39 AM 12/20/2003, Jim Burwell wrote:
</pre>
<blockquote type="cite">
<pre wrap="">For instance, if you have a locations entry that points a user to another user, or more than one user (e.g. <a class="moz-txt-link-rfc2396E" href="mailto:mainline@domain.com"><mailto:mainline@domain.com></a><a class="moz-txt-link-abbreviated" href="mailto:mainline@domain.com">mainline@domain.com</a> -> <a class="moz-txt-link-rfc2396E" href="mailto:receptionist@domain.com"><mailto:receptionist@domain.com></a><a class="moz-txt-link-abbreviated" href="mailto:receptionist@domain.com">receptionist@domain.com</a> -> receptionist@<phone-IP:port>), SER seems to get confused and sends a CANCEL to the voice mail system you've just triggered the INVITE to in your failure_route.
</pre>
</blockquote>
<pre wrap=""><!---->
Whats is exactly the issue? I mean SER sends CANCEL when timeout strikes or when some of the
branches completes. If you decide to forward to voice mail, other pending branches will be
cancelled and it is good so. If you maintain the CANCEL is sent to voice mail (as opposed to
pending branhces), send me your message dumps.
-jiri
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="78">--
+---------------------------------------------------------------------------+
| Jim Burwell - Sr. Systems/Network/Security Engineer, JSBC |
+---------------------------------------------------------------------------+
| "I never let my schooling get in the way of my education." - Mark Twain |
| "UNIX was never designed to keep people from doing stupid things, because |
| that policy would also keep them from doing clever things." - Doug Gwyn |
| "Cool is only three letters away from Fool" - Mike Muir, Suicyco |
| "..Government in its best state is but a necessary evil; in its worst |
| state an intolerable one.." - Thomas Paine, "Common Sense" (1776) |
+---------------------------------------------------------------------------+
| Email: <a class="moz-txt-link-abbreviated" href="mailto:jimb@jsbc.cc">jimb@jsbc.cc</a> ICQ UIN: 1695089 |
+---------------------------------------------------------------------------+
| Reply problems ? Turn off the "sign" function in email prog. Blame MS. |
+---------------------------------------------------------------------------+
</pre>
</body>
</html>