<!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">
Comments in line..<br>
<br>
Jiri Kuthan wrote:<br>
<blockquote type="cite"
cite="mid6.0.1.1.0.20031221142524.01f09ec0@localhost">
<pre wrap="">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.</pre>
</blockquote>
<br>
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.
:-)<br>
<br>
Having said that, I think your hints have nudged me in the proper
direction for solving this problem.<br>
<br>
<blockquote type="cite"
cite="mid6.0.1.1.0.20031221142524.01f09ec0@localhost">
<pre wrap="">-jiri
At 08:54 AM 12/21/2003, Jim Burwell wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.</pre>
</blockquote>
<br>
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. <br>
<br>
What I'd like to do is just have them simply enter
<a class="moz-txt-link-rfc2396E" href="sip:myusername@domain.tld">"sip:myusername@domain.tld"</a> 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 <a class="moz-txt-link-rfc2396E" href="sip:user@domain">"sip:user@domain"</a> as a contact
for the 'group AOR' results in voice mail failure for various reasons
I'll try to explain below.<br>
<br>
<br>
<blockquote type="cite"
cite="mid6.0.1.1.0.20031221142524.01f09ec0@localhost">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
I'm not aware of anything what would prohibit you from doing so.</pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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; }<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<blockquote type="cite"
cite="mid6.0.1.1.0.20031221142524.01f09ec0@localhost">
<blockquote type="cite">
<pre wrap="">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,
</pre>
</blockquote>
<pre wrap=""><!---->
Why have you thought of hacking serweb, when contact manipulation is already there?</pre>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid6.0.1.1.0.20031221142524.01f09ec0@localhost">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">but then realized that they'd have to update this every time they turned off a phone, added a new phone, etc.
</pre>
</blockquote>
<pre wrap=""><!---->
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.</pre>
</blockquote>
<br>
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. <br>
<br>
<blockquote type="cite"
cite="mid6.0.1.1.0.20031221142524.01f09ec0@localhost">
<pre wrap="">For examples, <a class="moz-txt-link-abbreviated" href="mailto:jiri@iptel.org">jiri@iptel.org</a> may be provisioned to link to contacts:
- <a class="moz-txt-link-freetext" href="sip:jiri@10.0.0.1">sip:jiri@10.0.0.1</a> (my phone)</pre>
</blockquote>
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.<br>
<blockquote type="cite"
cite="mid6.0.1.1.0.20031221142524.01f09ec0@localhost">
<pre wrap="">
- <a class="moz-txt-link-freetext" href="sip:secretary@iptel.org">sip:secretary@iptel.org</a> (calls to jiri should ring there too -- note
a contact address may ne another AOR)</pre>
</blockquote>
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.<br>
<br>
<blockquote type="cite"
cite="mid6.0.1.1.0.20031221142524.01f09ec0@localhost">
<pre wrap="">
- <a class="moz-txt-link-freetext" href="sip:1234@iptel.org">sip:1234@iptel.org</a> (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.
</pre>
<blockquote type="cite">
<pre wrap="">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"><mailto:user1@domain.tld></a><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"><mailto:user2@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-rfc2396E" href="mailto:main@domain.tld"><mailto:main@domain.tld></a><a
class="moz-txt-link-abbreviated" href="mailto:main@domain.tld">main@domain.tld</a> -> <a class="moz-txt-link-rfc2396E" href="mailto:user1@domain.tld"><mailto:user1@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.
</pre>
</blockquote>
<pre wrap=""><!---->
That's the way to do it. If you think there is an error, then come up
with a case.</pre>
</blockquote>
<br>
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.<br>
<br>
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. <br>
<br>
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:<br>
<br>
<blockquote>INVITE -> SER forks to destination set, no failure_route
set up -> forked branch enters SER, failure_route set up -> relay
to branch contact.<br>
<br>
</blockquote>
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.<br>
<br>
<br>
<blockquote type="cite"
cite="mid6.0.1.1.0.20031221142524.01f09ec0@localhost">
<blockquote type="cite">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap=""><!---->
Sounds like a SER miconfiguration. That's however hard to judge without seeing
message dumps, config files. See <a class="moz-txt-link-abbreviated" href="http://www.iptel.org/ser/problems/">www.iptel.org/ser/problems/</a> 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.</pre>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote type="cite"
cite="mid6.0.1.1.0.20031221142524.01f09ec0@localhost">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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 class="moz-txt-link-abbreviated" href="mailto:a@10.0.0.1">a@10.0.0.1</a>
---INVITE----> SER ---+--------------> ringing < 180
| <a class="moz-txt-link-abbreviated" href="mailto:b@10.0.0.1">b@10.0.0.1</a>
+---------------> offline < 404
| <a class="moz-txt-link-abbreviated" href="mailto:c@iptel.org">c@iptel.org</a>
+-----------+
|
+----------------------|
|
+--------------------------> 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.
</pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid6.0.1.1.0.20031221142524.01f09ec0@localhost">
<pre wrap="">
-jiri
</pre>
</blockquote>
<br>
- Jim<br>
<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>