Hi Adrian,
a call to pstn is 012345@localdomain
a call to iptel is 012345@remotedomain
Now, the iptel-invite should not be touched and forwarded straight, the pstn
invite must be rewritten to +4912345@localdomain.
Now the problem is if the UA initiating the call is sending an ACK. It will
send the ACK with Request-URI 012345@finaldestination and several route
header fields to traverse the proxy chain.
This 012345@finaldestination must not be touched if the initial call was for
a remote domain (To will be 012345@remotedomain), but it must be rewritten
do +4912345@finaldestination for a PSTN call (To will be
012345@localdomain). Thus there is the need to look after the To value.
Thanks for your feedback,
regards,
Martin
----- Original Message -----
From: Adrian Georgescu
To: Martin Koenig [toplink-plannet GmbH]
Sent: Wednesday, September 08, 2004 5:28 PM
Subject: Re: [Serusers] Domain and To header fields
I understand better now. But why would you do that? If I understand maybe
some idea pops up.
On Sep 8, 2004, at 5:15 PM, Martin Koenig [toplink-plannet GmbH] wrote:
Hi Adrian,
the URI will not be local, it will be the remote target as defined for loose
routing.
Regards,
Martin
----- Original Message -----
From: Adrian Georgescu
To: Martin Koenig
Cc: serusers(a)lists.iptel.org
Sent: Tuesday, September 07, 2004 10:41 PM
Subject: [Serusers] Domain and To header fields
Martin, try is_uri_host_local()
Adrian
>>>>>>>>>>>>>>
Hi List,
I have a multi domain ser setup with the domain module operating, and I need
to check whether the TO header field contains a local domain or not.
Can this be done with is_domain_local()? If yes how?
Or do i need to write a new function based on is_from_local() to achieve
such a goal.
The Problem is that there is no possiblity to distinguish between our user
calling 012345 at
iptel.org (Remote SIP desination) or 012345 at
domain.com
(PSTN
target) after (!) the initial INVITE, especially with loose routing. This is
important because Request-URIs to the PSTN have to be transformed (add f.e.
+49), but requests to other sip destinations have to not be touched.
Thanks for your input,
regards,