If you know in advance the IP of 1002 and it is
static, you can use serctl to add it's contact. This way doing a
lookup("location") for 1003 will return both contacts...it's not a nice
solution but it whould work.
Samuel.
Unclassified.
Hi Samuel,
That's a very good detailed explanation! That's exactly what happened.
In my existing config, I have the logic to deal with the second ring
to 1003(a)test.com. It forks to itself and creates another ser
transaction. I'd like to make it simpler by doing it in a single
transaction.
One way I am thinking about, but haven't tried yet, is when 1003
registers, ser adds its location to both 1002 and 1003. So when ser
does lookup("location") for 1002, the real location for 1003 shows up.
Not sure that it is feasible.
Thanks,
Richard
On 8/2/05, Samuel Osorio Calvo <samuel.osorio(a)nl.thalesgroup.com> wrote:
Just one remark: only one of the two URI will be
translated to the contact.
I'll try to explain...
imagine the incoming Req-URI is 1001(a)test.com. When it passes the first lookup,
lookup("aliases");
SER will retrieve the two aliases and put one of them as the new req-uri and the other as
branch.
Req-URI: 1002(a)test.com
branch: 1003(a)test.com
Doing the second lookup,
lookup("location");
will put the contact of 1002(a)test.com as Req-URI (if more than one contact is present,
the subsequent bindings will be added as branches) and the 1003(a)test.com will be left as
branch untouched.
Req-URI: 1002(a)10.1.1.102
branch: 1003(a)test.com
This happens because lookup() only takes as input the req-URI.
The result is that SER makes a DNS query for
test.com, to send the request to
1003(a)test.com, instead of the end-point. If the DNS is properly configured,
test.com
should point to SER itself, making SER sending the message to itself via the network.
Depending on the config file, it can work but you should check the logs to see what is
exactly happening.
User 1002 will get the message without any problem.
NOTE: depending on the order in the database, 1003 and 1002 can exchange roles in upper
explanation.
As SER is now coded, above can not be changed (as far as I know)....
Hope it helps,
Samuel.
Unclassified.
>> "Zeus Ng"
<zeus.ng(a)isquare.com.au> 08/03/05 01:51AM >>>
You would need two
steps here, looup("aliases"), then lookup("location").
Zeus
-----Original Message-----
From: serusers-bounces(a)lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Richard Z
Sent: Wednesday, 3 August 2005 3:33 AM
To: Atle Samuelsen
Cc: serusers(a)lists.iptel.org
Subject: Re: [Serusers] lookup 2 uri
Hi Atle,
Alias doesn't replace uri with its real location. I'd like to use
lookup("location") to find out its real location. For
example, if 102(a)test.com is at 102(a)10.1.1.102 and
103(a)test.com is at 103(a)10.1.1.103. I'd like to replace all
uris with 102(a)10.1.1.102 and 103(a)10.1.1.103 in a single ser
transaction logic. Would it be possible?
Thanks,
Richard
On 8/1/05, Atle Samuelsen <clona(a)camaro.no> wrote:
Hi,
you could do something like :
serctl alias add 101 sip:102@test.com
serctl alias add 101 sip:103@test.com
This way the invite would be forked to both 102 and 103,
just remember to have both lookup("aliases"); and
save("aliases"); in
your config at the right spot :-)
-Atle
* Richard Z <rzheng(a)gmail.com> [050802 04:34]:
> Hi,
>
> I am trying to implement a feature to ring two ip phones
> simultaneously. For example, when I call 101(a)test.com, it
rings both
> 101(a)test.com and 102(a)test.com. In this case,
the ruri is
> 101(a)test.com. I can use append_branch 102(a)test.com, but
is there a
> way to lookup the locations of both 101 and
102?
>
> Thanks,
> Richard
>
> _______________________________________________
> Serusers mailing list
> serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
>
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers