Replace FROM header

Discuss any topic about Brekeke SIP Server.

Moderator: Brekeke Support Team

Post Reply
kk
Posts: 5
Joined: Mon Nov 26, 2012 4:16 pm
Location: Australia

Replace FROM header

Post by kk »

1. Brekeke Product Name and Version: SIP server 3.0.3

2. Java version:1.7.0_09

3. OS type and the version:windows server 2003

4. UA (phone), gateway or other hardware/software involved: Nortel - Brekeke - Cisco

5. Your problem: The external caller 54321769 calls Nortel. Nortel recogises that it should call Brekeke sip server to put the call through. Brekeke in turn puts the call through to Cisco as per the dial plan. Ring works, Voice works. But I want the Brekeke to put a prefix of 0 before the Calling Number receved from Nortel so the Cisco extension should read the caller as 054321769. Brekeke keeps sending the calling number information received from nortel i.e. 54321769 and ignores the deployed FROM header in the dial plan.

Original fields from Nortel :
$request = ^INVITE
To = sip:67(.+);(.+)@(.+)
From = sip:(.+);phone-context=National.e164@(.+)


Deployed fields before sending the call to Cisco:
To = sip:%1@192.168.93.2
$auth = false
$target = 192.168.93.2
$replaceuri = true
&net.sip.replacesdp.multipart = true
$rtp = false
From = "external"<sip:0%4@192.168.93.2>

The From field does not get modfied.
Nortel-Brekeke-Cisco
Tata
Posts: 223
Joined: Sun Jan 27, 2008 1:03 pm

Post by Tata »

I tested your DialPlan rule without any issue.
Have you pushed the [Apply Rules] button after you edited the rule?
Are there any other rules before the above rule? If so, they might affect..
kk
Posts: 5
Joined: Mon Nov 26, 2012 4:16 pm
Location: Australia

Post by kk »

hi Tata thanks,
The rule is Applied and running.
I have also tested by making it priority number 1.
No benefit. Rest of the rule works but not From.
so if you can suggest something else I might have missed.
regards
Nortel-Brekeke-Cisco
Tata
Posts: 223
Joined: Sun Jan 27, 2008 1:03 pm

Post by Tata »

Try the simple rule like a following.
--------------------------
[Matching Patterns]
$request = ^INVITE
From = sip:(.+)@

[Deploy Patterns]
From = "external" <sip:0%1@192.168.93.2>
--------------------------

Does the above rule replace the From header?
kk
Posts: 5
Joined: Mon Nov 26, 2012 4:16 pm
Location: Australia

Post by kk »

hi Tata,
I need to have 67 in the rules as Nortel sends the call with 67 prefix to Brekeke. But have been able to simplify the rule as follows:

matching:
$request = ^INVITE
To = sip:67(.+);.+@.+

deploy:
To = sip:%1@192.168.93.2
$target = 192.168.93.2
$auth = false
From = "external"<sip:7777@192.168.93.2>

With above I expect the Cisco extension to show the caller number as 7777 but it still shows the caller number as 54321769 that Nortel sent to Brekeke and sent onward to Cisco.

Whatever I do with From field has no effect except when I change it to some stupid values the call starts failing.

Any help much appreciated. - regards
Nortel-Brekeke-Cisco
Tata
Posts: 223
Joined: Sun Jan 27, 2008 1:03 pm

Post by Tata »

Are you sure that the Nortel's To-URI matches "sip:67(.+);.+@.+"?
Can you paste Nortel's INVITE packet here?
kk
Posts: 5
Joined: Mon Nov 26, 2012 4:16 pm
Location: Australia

Post by kk »

i hope this is what you asked for:

Extract from Brekeke logs:

sid:
333

from-uri:
sip:54321769;phone-context=National.e164@abc.net.au

to-uri:
sip:7468@192.168.93.2

Nortel sends 67(7468) to Brekeke so to-uri in the logs seems to show the to-uri where Brekeke is forwarding the call i.e. to Cisco.

I suspect that the phone context= National.e164... has something to do with the FROM not getting modified.
Because in another rule given below I am able to replace FROM successfully:
Matching
From=(.+)anonymous@(.+)
Deploy
From="UNKNOWN"<sip:9@%3
in this case the Cisco sees the caller number as 9 as intended.

regards
Nortel-Brekeke-Cisco
Tata
Posts: 223
Joined: Sun Jan 27, 2008 1:03 pm

Post by Tata »

kk,

I've tested sip:54321769;phone-context=National.e164@abc.net.au as the From URI. But there are no issue in the replacing the header with DialPlan.

I'm not sure why the issue happens in your environment.

Let you try the following Matching Pattern. It may avoid the issue.

Matching Patterns
$request = ^INVITE
To = sip:67(.+);(.+)@(.+)
$getUri(From) = sip:([0-9]+).+@(.+)
Post Reply