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@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,