23 Dec
2003
23 Dec
'03
1:21 a.m.
Comments in line..
Jiri Kuthan wrote:
There's nothing prohibiting it. It's just that voice mail fails when
you use location entries which cause forked branches to spiral back
through SER instead of being dispatched to a phone, or another SIP
router, or PBX, or whatever. I think (hope) that the reason for the
failure is because right now, each branch of the forked call is setting
up a call to voice mail.
These sorts of branches need special treatment. For instance, for these
branches, you shouldn't set up a failure_route to call voice mail upon
INVITE timer expiration, since in this special case, it results in
multiple branches of the same call calling voice mail, which causes a
failure. Only the original group user should set up the voice mail
timeout. You also must be careful not to call voice mail immediately if
there's no final contact for this user, since you want the other users
listed in the group user contact to ring.
The problem I have is figuring out a way to differentiate between a
normal call to the user him/herself, and a call to a 'group user' in
which this particular user is included in a forked branch. Basically, I
need a way to implement the logic: if(user is called directly) { set up
voice mail timeout, call voice mail normally if offline; relay call; }
else if(user is part of a branch of a group user call) { just relay call
or 404 if no contact; }
So far, the idea I've come up with to handle this is to use special
prefixes on the contacts usernames which are later stripped off when the
branch spirals back through SER. These prefixes would essentially carry
state back into SER, telling it in this case not to set up a voice mail
timeout for this branch, and not to call voice mail if the branch's
contact is off line. Instead, it just strips off the prefix, looks up
the URI in the locations table, returns a 404 if offline, and relays the
call if location exists. I'm hoping this will work and solve all the
problems I'm having with these group addresses.
Are there better ways of doing this ? I cant think of another way to
'mark' these branches, or use ser.cfg code to have it detect this
special case. Would "setflag" serve in this case ? I'm not sure if
setflag's scope is just for one iteration through the ser.cfg file, or
whether it's saved as state for the entire transaction and all
associated forked branches. I believe the former is true.
I also previously thought that returning a 404 in the case of having no
final contact (offline) would cause the _entire_ call to fail. But
after reading your reply, I realize that this shouldn't happen, and
returning the 404 is the proper thing to do.
My idea was to have SERWeb look up the IP:ports of the contacts entered
and put them into the group user's contact list to avoid branches
spiraling back through SER. A few seconds thought made me realize that
this wouldn't work since the IPs could change.
No. I do understand this. That's what we're having them do now, but
it's not user friendly, since they need to enter all of their phones by
IP address:port with our present SER configuration for reasons I
explained above.
Yes. I realize it's hard to debug this without this information. I
usually include this, but this time I didn't have access to good dumps.
I need to reproduce them.
Ah. I was under the impression that a single 404 for a contact in the
group would cancel the whole call, because this seemed to be what was
happening when I was troubleshooting.
I also wondered how SIP differentiates between different branches of a
call while I was analyzing the dumps. I came to the conclusion that it
was the "branch=" suffix in the VIA field, since these were the only
items that were consistently in every message sent in the transaction,
and unique.
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.
Yes. Granted. I'm no SIP expert, as I already stated in my previous
message. My background is in Unix systems administration and Network
administration. Like many on this list, I'm still learning about
SIP/VOIP technology. I haven't actually had time to plow through the
RFC yet, but the SER documentation has a fairly good explanation of what
'location' and 'forking' are. I've also read some of the other
documentation from iptel, like the SIP tutorial, etc. But like most
things, the devil is in the details, and learning all the subtleties and
nuances of SIP is a bit of a learning curve. This is why I occasionally
post messages on this list, asking questions and stuff. :-)
Having said that, I think your hints have nudged me in the proper
direction for solving this problem.
-jiri
At 08:54 AM 12/21/2003, Jim Burwell wrote:
Yes. I mentioned this solution in my last message. We're already doing
this. But this is inconvenient and not very _user friendly_. It
requires the end user, some of whom will be non technical people, to
know the dynamically changing IP address and port number of their SIP
phones and enter them into SERWeb for the 'group AOR'. They'd also have
to repeat this process for every SIP phone they have. Either that, or
set up their SIP phones to register both themselves, and the 'group AOR'
with SER. Some SIP phones allow this (the Xten soft phones do, for
instance), some don't.
What I'd like to do is just have them simply enter
"sip:myusername@domain.tld" to cover all their phones without having to
go through phone menus and look up IP addresses and ports, etc. This is
where I ran into the problems. Using "sip:user@domain" as a contact for
the 'group AOR' results in voice mail failure for various reasons I'll
try to explain below.
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)
This works fine, but as I've said requires the user to know the IP/port
of his phone(s) and enter it into SERWeb for the group user, or have
their phones register for this group user as well as for themselves if
the phone supports multiple users.
- sip:secretary@iptel.org (calls to jiri should ring
there too -- note
a contact address may ne another AOR)
In our current ser.cfg logic, having a contact like this in your AOR
causes VM to fail, for reasons I explained above. This is the problem
and the point of my whole post/question to the list.
- 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.
Yes. I will try to. If this is the way you guys do it at iptel, and it
works in the way desired, including voicemail, then the problem is
obviously a configuration issue in our ser.cfg file, and not a bug in SER.
However, I remember from some of my experimentation that SER was
CANCELing the calls to VM that it just sent an INVITE for when a VM URI
was appended in the failure_route.
I'm hoping that this was because the failure_route was not set up at the
initial INVITE, but rather at a later iteration when the branch spiraled
back through SER. To illustrate:
INVITE -> SER forks to destination set, no failure_route set up ->
forked branch enters SER, failure_route set up -> relay to branch
contact.
I'm not sure if this would be a problem or not. Regardless of whether
it is or not, this is not the desired behavior I want anyway. I need to
set up a cfg so that only the original group user gets a VM timeout set,
and subsequent contact users don't, as I explained above.
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
- Jim
--
+---------------------------------------------------------------------------+
| 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: jimb(a)jsbc.cc ICQ UIN: 1695089 |
+---------------------------------------------------------------------------+
| Reply problems ? Turn off the "sign" function in email prog. Blame MS. |
+---------------------------------------------------------------------------+