_______________________________
Hi!
On the pattons you can create Error Messages when no circuit channel is available And on Ser you have to register a Failure Route to the route of the first patton and the failure route point to the second Patton.
-----------------------------------------------------------
PATTON1:
profile sip default
map cause to-sip no-circuit-channel-available to 486
map cause to-sip resources-unavailable to 486
service hunt-group HUNT-BRI
cyclic
timeout 1
drop-cause normal-unspecified
drop-cause no-circuit-channel-available
drop-cause network-out-of-order
drop-cause temporary-failure
drop-cause switching-equipment-congestion
drop-cause access-info-discarded
drop-cause circuit-channel-not-available
drop-cause resources-unavailable
route call 1 dest-interface ISDN_01
route call 2 dest-interface ISDN_02
route call 3 dest-interface ISDN_03
---------------------------------------------------
SER:
Ser.cfg:
if ( uri=~".*sip:012345" ) # Patton 1
{ t_on_failure("1");
t_relay_to_udp("11.11.11.10", "5060");
break;
}
---------------------------------------------------
failure_route[1]
{
if (method=="INVITE")
{
if (t_check_status ("600|486")) #### ErrorCode from Patton 1
{
#####call from Patton 1 -- 486 (Busy) ret -- call switch to Patton 2 ######
if ( uri=~".*sip:012345" ) # Costumer xy
{
append_branch();
t_relay_to_udp("11.11.11.11", "5060"); ##Unterroute ist hier nicht notwendig,
break; ##da sich die Verrechnung hier nicht aendert
}
}
}
---------------------------------------
I hope it help!
Hannes
_______________________________
Johannes Wagner-Meingassner
-----Ursprüngliche Nachricht-----
Von: serusers-bounces(a)lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] Im Auftrag von pokerino76
Gesendet: Mittwoch, 8. August 2007 18:43
An: serusers
Betreff: [Serusers] SER+ PATTON1 + PATTON2
Wichtigkeit: Hoch
I have 2 patton from 8 channels everyone. I must make the sum of the channels 8+8=16. The patton they are connects to with the SER. How to make the switch of the channels when one of the two is saturate?
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
__________________________________________________________________________________
Dieses Mail wurde vom Infotech SecureMail Service ueberprueft und fuer sicher befunden.
Fuer weitere Informationen zu Infotech SecureMail Service waehlen Sie bitte: www.infotech.at
This email has been scanned by Infotech SecureMail Service and it has been classified as secure.
For more information on Infotech SecureMail direct your web browser to: www.infotech.at
Hello all.
We are facing some problems in our deployment of OpenSER, related to NAT
Traversal solution using MediaProxy.
In our scenario, using the the sample configuration NAT detection works
right for REGISTER method, and for INVITE's sent from clients behind NAT,
but, incoming calls originated from transparent clients, directed to clients
behind NAT do not work, and do not pass through MediaProxy. Services based
on re-INVITES do not work either.
To solve that issue, we tried to intercept the 200 OK answer coming from NAT
client, so that we could call use_media_proxy(), but, we get the error:
"Empty Response from media_proxy()"
Our configuration is more or less like this:
# In the beginning of the main route
if(client_nat_test("7"))
{
setflag(2);
fix_contact();
};
.....
if(is_method("INVITE"))
{
if(isflagset(2))
{
use_media_proxy();
};
t_on_reply("1");
}
....
on_reply_route[1]
{
if (status =~ "(18[0-3])|(2[0-9][0-9])|(1[0-9][0-9])")
{
if (client_nat_test("3"))
{
fix_contact();
use_media_proxy();
}
}
}
That is a very brief configuration fragment, but it is more or less the
schema of configuration we are using. So far, our solution to be able to
have the whole services working is marking all the calls so that they pass
through the mediaproxy, but we are not sure if that is a good solution.
Thanks in advance for every hint or suggestion.
Kind regards
*Sergio Armando Gutiérrez Betancur*
*S**ubdirección **A**plicaciones **de **S**ervicios **C**onvergentes**
UNE - EPM Telecomunicaciones
* *Tel: 054 3802956*
*Email: saguti(a)gmail.com*
I have 2 patton from 8 channels everyone. I must make the sum of the channels 8+8=16. The patton they are connects to with the SER. How to make the switch of the channels when one of the two is saturate?
Hi Inaki,
Why would you leave out the "4" flag test in nat_uac_test() for the replies?
Of course if I leave out the "2" test then my example works (I have tested it) but I am afraid that this will break some other NATed senario. And if leave out the "2" test, should I also leave out the "16" test?
Best regards
George
> ------------------------------
>
> Message: 4
> Date: Wed, 8 Aug 2007 11:53:46 +0200
> From: I?aki Baz Castillo <ibc(a)in.ilimit.es>
> Subject: Re: [OpenSER-Users] NAT question
> To: users(a)openser.org
> Message-ID: <200708081153.46621.ibc(a)in.ilimit.es>
> Content-Type: text/plain; charset="iso-8859-1"
>
> El Wednesday 08 August 2007 10:30:54 Papadopoulos Georgios escribiσ:
> > Hi Bogdan,
> >
> > I understand that 200 OK should not be fixed by proxyA. Maybe what I
> > don't understand is what nat_uac_test("2") does and when to use it.
> >
> > Following is an example where
> > clientA = demo1(a)altecnet.gr
> > clientB = sip_test_1(a)i-call.gr
> > proxyA = 213.5.43.4
> > proxyB = 213.5.43.134
> >
> > When proxyA goes in the onreply_route for the 200 OK,
> nat_uac_test("23")
> > returns true (I guess because of the "2" flag) and proxyA fixes the
> > contact again which is wrong. So, would it be safe to use
> > nat_uac_test("23") for the requests and nat_uac_test("21") for the
> > replies? I am afraid this would break the simple case with 2 NATed
> > clients and only one proxy:
> > clientA ------> proxyA ------> clientC
>
>
> Good point. As I think, the correct NAT test for replies is:
> nat_uac_test("1")
> so we just check if <Contact:> header does contain an RFC1918
> IP address
> (private IP address).
>
> In your case it will work since the <Contact> modified by
> proxyB will contain
> a non private IP so the NAT check (nat_uac_test("1")) in
> proxyA wont detect
> the repliy as behind NAT.
>
> Maybe others test could be done, but I think they should no
> valid test that
> just compare the received IP with the IP of the contact since
> both could be
> public IP but different, in which case shouldn't be
> applied "fix_nat_contact".
>
>
> Regards.
>
>
>
> --
> Iρaki Baz Castillo
> ibc(a)in.ilimit.es
>
Disclaimer
The information in this e-mail and any attachments is confidential. It is intended solely for the attention and use of the named addressee(s). If you are not the intended recipient, or person responsible for delivering this information to the intended recipient, please notify the sender immediately. Unless you are the intended recipient or his/her representative you are not authorized to, and must not, read, copy, distribute, use or retain this message or any part of it. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
to do this you need to substitute the value of the From Header with
anonymous.
try to use textops module
cheers
tomasz
dciepiel(a)orange.pl pisze:
> I mean, to hide the number the person who is calling, like in GSM. U
> can hide the number and the person who answering your call doesn`t see
> who is calling. See the attachment.
>
> cheers,
>
> Daniel
>
>
> ---Oryginalna wiadomość---
> Nadawca:tzieleniewski <tzieleniewski(a)o2.pl>
> Do:dciepiel@orange.pl
> Otrzymana:2007-08-08 13:43
> Temat:Re: [Serusers] ODP:Re: Instant messaging.
> do you mean call blocking at SIP Proxy??
>
> dciepiel(a)orange.pl pisze:
>
>> Thanx Tomasz, It is very helpful. I have one more question. Do you
>> know how to implement CLIR (Calling Line Identification Restriction)
>> service?
>>
>> cheers,
>>
>> Daniel
>>
>> ---Oryginalna wiadomość---
>> Nadawca:tzieleniewski <tzieleniewski(a)o2.pl>
>> Do:dciepiel@orange.pl
>> Otrzymana:2007-08-08 11:18
>> Temat:Re: [Serusers] Instant messaging.
>> use msilo module for this
>>
>> cheers tomasz
>>
>> dciepiel(a)orange.pl pisze:
>>
>>
>>> Hi,
>>>
>>> I have a short question. Does SER support Instant messaging? If yes, I
>>> will be gratefull for any quidelines how to set up it.
>>>
>>>
>>> cheers,
>>>
>>> Daniel
>>>
>>>
>>>
> ------------------------------------------------------------------------
>
>>> _______________________________________________
>>> 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
>>
>>
>
>
>
> ------------------------------------------------------------------------
>
Thanx Tomasz, It is very helpful. I have one more question. Do you
know how to implement CLIR (Calling Line Identification Restriction)
service?
cheers,
Daniel
---Oryginalna wiadomość---
Nadawca:tzieleniewski <tzieleniewski(a)o2.pl>
Do:dciepiel@orange.pl
Otrzymana:2007-08-08 11:18
Temat:Re: [Serusers] Instant messaging.
use msilo module for this
cheers tomasz
dciepiel(a)orange.pl pisze:
> Hi,
>
> I have a short question. Does SER support Instant messaging? If yes, I
> will be gratefull for any quidelines how to set up it.
>
>
> cheers,
>
> Daniel
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Serusers mailing list
> Serusers(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
Hi Bogdan,
I understand that 200 OK should not be fixed by proxyA. Maybe what I
don't understand is what nat_uac_test("2") does and when to use it.
Following is an example where
clientA = demo1(a)altecnet.gr
clientB = sip_test_1(a)i-call.gr
proxyA = 213.5.43.4
proxyB = 213.5.43.134
When proxyA goes in the onreply_route for the 200 OK, nat_uac_test("23")
returns true (I guess because of the "2" flag) and proxyA fixes the
contact again which is wrong. So, would it be safe to use
nat_uac_test("23") for the requests and nat_uac_test("21") for the
replies? I am afraid this would break the simple case with 2 NATed
clients and only one proxy:
clientA ------> proxyA ------> clientC
thank you for your help
George
#
U 2007/08/08 10:11:34.233164 213.5.43.134:5060 -> 213.5.43.4:5060
SIP/2.0 200 Ok.
Via: SIP/2.0/UDP 213.5.43.4;rport=5060;branch=z9hG4bK322.eea78413.0.
Via: SIP/2.0/UDP
192.168.1.39;received=213.5.17.226;rport=5060;branch=z9hG4bKc0a801270000
002c46b96cbb000000a000000087.
Record-Route: <sip:213.5.43.134;lr=on;ftag=109517115931019>.
Record-Route: <sip:213.5.43.4;lr=on;ftag=109517115931019>.
From: "222" <sip:demo1@altecnet.gr>;tag=109517115931019.
To: <sip:sip_test_1@i-call.gr>;tag=0r8u9ziv3g.
Call-ID: 000029DD-5407-0000-3452-00006A3B0000(a)192.168.1.39.
CSeq: 2 INVITE.
Contact: <sip:sip_test_1@213.5.17.236:5060;transport=udp;line=9yt55o5b>.
User-Agent: snom190-3.56w.
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE,
PRACK, MESSAGE, INFO.
Allow-Events: talk, hold, refer.
Supported: timer, 100rel, replaces.
Content-Type: application/sdp.
Content-Length: 208.
.
v=0.
o=root 1592588598 1592588598 IN IP4 213.5.17.236.
s=call.
c=IN IP4 213.5.17.236.
t=0 0.
m=audio 10116 RTP/AVP 8 101.
a=rtpmap:8 pcma/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=sendrecv.
#
U 2007/08/08 10:11:34.234013 213.5.43.4:5060 -> 213.5.17.226:5060
SIP/2.0 200 Ok.
Via: SIP/2.0/UDP
192.168.1.39;received=213.5.17.226;rport=5060;branch=z9hG4bKc0a801270000
002c46b96cbb000000a000000087.
Record-Route: <sip:213.5.43.134;lr=on;ftag=109517115931019>.
Record-Route: <sip:213.5.43.4;lr=on;ftag=109517115931019>.
From: "222" <sip:demo1@altecnet.gr>;tag=109517115931019.
To: <sip:sip_test_1@i-call.gr>;tag=0r8u9ziv3g.
Call-ID: 000029DD-5407-0000-3452-00006A3B0000(a)192.168.1.39.
CSeq: 2 INVITE.
Contact: <sip:sip_test_1@213.5.43.134:5060;transport=udp;line=9yt55o5b>.
User-Agent: snom190-3.56w.
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE,
PRACK, MESSAGE, INFO.
Allow-Events: talk, hold, refer.
Supported: timer, 100rel, replaces.
Content-Type: application/sdp.
Content-Length: 208.
P-hint: NATed reply.
.
v=0.
o=root 1592588598 1592588598 IN IP4 213.5.17.236.
s=call.
c=IN IP4 213.5.17.236.
t=0 0.
m=audio 10116 RTP/AVP 8 101.
a=rtpmap:8 pcma/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=sendrecv.
> -----Original Message-----
> From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro]
> Sent: Wednesday, August 08, 2007 9:50 AM
> To: Papadopoulos Georgios
> Cc: users(a)openser.org
> Subject: Re: [OpenSER-Users] NAT question
>
> Hi George,
>
> each proxy should fix what it detects. ProxyA will take care
> of the traffic related to A (since it detects A as NATed) and
> ProxyB should take care of traffic for B (as it sees B as
> nated). So, the 200 OK must be fixed only by proxyB.
>
> Regards,
> bogdan
>
> Papadopoulos Georgios wrote:
> > Hello all,
> >
> > I need some advice from all you NAT experts. Assume that we
> have two
> > OpenSER proxies serving two different domains and they both use
> > nathelper. Also assume that their configuration is
> identical and looks
> > roughly like:
> >
> > route {
> > ...
> > record_route();
> >
> > if (nat_uac_test("23")) {
> > if (method!="REGISTER" &&
> > !is_present_hf("Record-Route")) {
> > fix_nated_contact();
> > }
> > }
> >
> > t_on_reply("1");
> > }
> >
> > onreply_route[1] {
> > if (nat_uac_test("23")) {
> > fix_nated_contact();
> > };
> > }
> > clientA and clientB are both behind NAT. clientA@domainA
> > <mailto:clientA@domainA> sends an INVITE to clientB@domainB
> > <mailto:clientB@domainB> through proxyA:
> >
> > clientA@domainA <mailto:clientA@domainA> -----> ProxyA
> -----> ProxyB
> > ------> clientB@domainB <mailto:clientB@domainB>
> >
> > ProxyA detects that clientA is behind NAT and fixes the contact.
> > ProxyB finds the Record-Route header, so it does not fix
> the contact.
> > My question is about how to handle the 200 OK. With this
> configuration
> > both proxies detect that clientB is behind NAT and the contact gets
> > fixed twice. Is there a way to avoid this?
> >
> > thank you
> >
> > George
> >
> >
> >
> >
> >
> >
> > Disclaimer
> >
> > The information in this e-mail and any attachments is
> confidential. It
> > is intended solely for the attention and use of the named
> > addressee(s). If you are not the intended recipient, or person
> > responsible for delivering this information to the intended
> recipient,
> > please notify the sender immediately. Unless you are the intended
> > recipient or his/her representative you are not authorized to, and
> > must not, read, copy, distribute, use or retain this message or any
> > part of it. E-mail transmission cannot be guaranteed to be
> secure or
> > error-free as information could be intercepted, corrupted, lost,
> > destroyed, arrive late or incomplete, or contain viruses.
> >
> >
> ----------------------------------------------------------------------
> > --
> >
> > _______________________________________________
> > Users mailing list
> > Users(a)openser.org
> > http://openser.org/cgi-bin/mailman/listinfo/users
> >
>
>
Hi all,
Is there any way in SER thru which i can maintain the message counters
(Performance Counters), i.e. counts of each and every request and
response...