21 Dec
2003
21 Dec
'03
8:56 a.m.
Jim,
I think you should first make yourself better with the SIP technology,
especially if you indicate that you have customers to whom you would
like to market it. In particularly, the concepts of user location and
forking are important to you. I'm trying to respond to some of your
questions, but such quick hints are not a good substitute for thorough
understanding. More inline.
-jiri
At 08:54 AM 12/21/2003, Jim Burwell wrote:
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.
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.
That's all simple -- let the users register with the same address, that's it.
If you would like to provision some users manualy, use serweb or serctl
to manipulate contacts associated with the address. All the contacts will
be ringing on incoming calls.
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.
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.
I'm not aware of anything what would prohibit you from doing so.
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,
Why have you thought of hacking serweb, when contact manipulation is already there?
but then realized that they'd have to update this
every time they turned off a phone, added a new phone, etc.
I'm not sure you completely understand the user location model. SIP address,
so called address of record (AOR), can be linked to any number of contacts.
There are handled by phones' REGISTER requests, but also any other
out-of-band method, such as serweb. Obviously, if you wish the contact
list to change, than someone has to do the modification job. Either
the telephone using REGISTER, or a user through serweb.
For examples, jiri(a)iptel.org may be provisioned to link to contacts:
- sip:jiri@10.0.0.1 (my phone)
- sip:secretary@iptel.org (calls to jiri should ring there too -- note
a contact address may ne another AOR)
- sip:1234@iptel.org (my PBX phone as well).
All these contacts have some time-to-live. Telephones use one hour by
default, provisioning interface allows you to set infinite time if you
wish.
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 <mailto:user1@domain.tld>"user1@domain.tld",
<mailto:user2@domain.tld>"user2@domain.tld". 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: <mailto:main@domain.tld>main@domain.tld ->
<mailto:user1@domain.tld>user1@domain.tld -> 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.
That's the way to do it. If you think there is an error, then come up
with a case.
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).
Sounds like a SER miconfiguration. That's however hard to judge without seeing
message dumps, config files. See www.iptel.org/ser/problems/ for information on
how meaningful problem reporting is supposed to look like. Hopefuly, someone on
the mailing list will have cycles to go through your information.
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.
Again, I think you wish to make yourself better familiar with SIP (RFC3261).
Reponding with 404 to a request to an off-line user is the only correct
thing to do for a server. If a request is forked to multiple destinations
(this is called "parallel forking") well, then one will return 404, the other
branches will keep pending till someone answers.
a(a)10.0.0.1
---INVITE----> SER ---+--------------> ringing < 180
| b(a)10.0.0.1
+---------------> offline < 404
| c(a)iptel.org
+-----------+
|
+----------------------|
|
+--------------------------> offline < 404
In this example, the INVITE will be fokred to a,b,c. a results
in rigning phone. b will immediately yield 404. c will result
in a spiral through the server and yiled 404 in next step.
So later, b and c branches are gone, only a keeps ringing. If ser
is configured to do so, it will CANCEL the branch a) and initate
another branch to voicemail eventually.
If you troubleshoot such scenarios, it is important that you understand
how transactions are identified. All request branches must include the
same Via/branch id prefix, only the suffix differs as it identifies
branch in question.
-jiri