[Serusers] Re: SIP URI that points to multiple users/VM issues...
Jim Burwell
jimb at jsbc.cc
Tue Dec 23 00:21:50 CET 2003
Comments in line..
Jiri Kuthan wrote:
>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:
>
>
>>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.
>
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 at 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 at domain" as a contact for
the 'group AOR' results in voice mail failure for various reasons I'll
try to explain below.
>>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.
>
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.
>>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?
>
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.
>
>
>>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.
>
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.
>For examples, jiri at iptel.org may be provisioned to link to contacts:
>- sip:jiri at 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 at 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 at 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 at domain.tld>"user1 at domain.tld", <mailto:user2 at domain.tld>"user2 at 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 at domain.tld>main at domain.tld -> <mailto:user1 at domain.tld>user1 at 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.
>
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.
>>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.
>
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.
>>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 at 10.0.0.1
> ---INVITE----> SER ---+--------------> ringing < 180
> | b at 10.0.0.1
> +---------------> offline < 404
> | c at 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.
>
>
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.
>-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 at jsbc.cc ICQ UIN: 1695089 |
+---------------------------------------------------------------------------+
| Reply problems ? Turn off the "sign" function in email prog. Blame MS. |
+---------------------------------------------------------------------------+
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20031222/cd525ce3/attachment.htm>
More information about the sr-users
mailing list