Hi All,
I have something like this in my script:
...
if (loose_route())
{
...
t_relay("udp:mydomain2.com");
...
}
...
The idea is that the initial INVITE message can be relayed to one
destination (mydomain1.com). But later, for the BYE message, if that
destination becomes unavailable and we know about that, then we send the
message to mydomain2.com. The problem is that it does not work that way.
Even if mydomain2.com is passed to t_relay, the message is still sent to
mydomain1.com. It looks like the parameter is ignored when loose routing
is done. Is it a bug or a feature? If it is a feature, then the
documentation for the t_relay function should mention that the parameter
is ignored when loose routing is done.
Another question is, how to make it send the message to mydomain2.com?
Do I have to modify the message (like, modify the Route header)?
Thanks,
--------
Anatoly.
Please let me know how can i configure this sip max session timer on the openser?
(SIP max timer) - If the openser doesn’t receive any BYE message from the origination or termination equipment than the SIP max timer will forcefully kill the call by generating the BYE on its own.
Thanks
Kchris
---------------------------------
Explore your hobbies and interests. Click here to begin.
I've tried setting flags on INVITE, ACK & BYE all.
On Mon, Jun 9, 2008 at 4:01 PM, David Villasmil <
david.villasmil.work(a)gmail.com> wrote:
> have you set the flag on INVITES as well?
>
> On Mon, Jun 9, 2008 at 11:01 AM, Ruchir Lists <ruchir.lists(a)gmail.com>
> wrote:
>
>> Hi All,
>>
>> I'm trying to configure OpenSER with multi-leg accounting. I'm using
>> OpenSER 1.2 & radius. I'm using acc_radius table for writing cdr records.
>> I've searched through several articles and mailing list posts about
>> configuring multi-leg accounting and everywhere they talk about setting up
>> multi-leg-info parameter of acc module to configure leg source & destination
>> and setting up accounting flag. But this is not working for me. I get only
>> BYE record in table if I use this way to write multiple records for one call
>> in call forwarding scenario. I managed to get multiple records by calling
>> acc_rad_request on INVITE, ACK, BYE & CANCEL. For instance, I have 4 users;
>> 90001, 90002, 90003, 90004. The call forwarding is setup as below:
>> 90004 -> 90001 -> 90003.
>>
>> I dial 90004 from 90002 user and it forwards the call to 90001 & then
>> 90003 and they're connected properlry. However I don't get leg
>> source/destination properly and also I get 7-8 bye records for this call.
>> Can anyone guide me in right direction if I'm doing anything wrong.
>>
>> Regards,
>> Ruchir
>>
>> _______________________________________________
>> Users mailing list
>> Users(a)lists.openser.org
>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>
>>
>
We have done some basic development using OpenSER, now it is time to
build a production system. The first application will be an alias_db
application (using mySQL) to do call forwarding. We do expect to develop
other applications in the future. We have some brand new Dell server
class boxes for the project so we have plenty of hardware capacity. We
do not have a lot of UNIX knowledge, so we would like to take advantage
of a package based environment. What variant of Linux would you
recommend for this system?
E-MAIL CONFIDENTIALITY NOTICE:
The contents of this e-mail message and
any attachments are intended solely for the
addressee(s) and may contain confidential
and/or legally privileged information. If you
are not the intended recipient of this message
or if this message has been addressed to you
in error, please alert the sender immediately
by reply e-mail and then delete this message
and any attachments. If you are not the
intended recipient, you are notified that
any use, dissemination, distribution, copying,
or storage of this message or any attachment
is strictly prohibited.
Disclaimer added by CodeTwo Exchange Rules
http://www.codetwo.com
hi
i manage the Cisco BTS 10200 system, and now i am assigned a task to work with the Radius
i choose the FreeRadius to work with Cisco BTS system
modify some config in radiusd.conf & clients.conf
first, BTS send message Access Request to FreeRadius and then Freeradius send message Access Accept, they working properly
when BTS send message Account Start to Radius, there are a lot attribute and freeradius save them in the radacct table
the messages flow:
BTS FreeRadius
-----Service Authorize------>
<-------Access Accept--------
-----Service Start----------->
<-----Account Respone ----
----Service ReAuthorize---->
<-------Account Accept------>
-----Service Stop------------->
<-------Account Respone----
but in radacct , there some columm doesn't match with the message Account Start, i want to change the name of some columm to match the message
Should i need to edit the sql.conf for this issue
On the CDR Tool, should i need to edit to working properly
Attribute
Vendo
Sub
Status
Attribute Name
Type
Value
ID
ID
Attribut
M-
User-Name
String
ANI
1
ID
M-
NAS-IP-Address
IP ddres
BTS IP address
4
M-
Service-Type
Integer
Service Type = Outbound
6
C+
Class
String
CLASS Attribute
25
M-
h323-incoming-conf-id=value
String
A unique number for identifying a calling session on a gateway, where a session is closed when the calling party hangs up.
26
9
1
M-
h323-conf-id
String
Unique call identifier generated by
the BTS. Used to distinguish the separate billable events (calls) within a single calling session.
26
9
24
M-
h323-setup-time
String
hh:mm:ss.mmm ZON DDD MMM
## YYYY Setup time in NTP format.
26
9
25
M+
h323-connect-time
String
hh:mm:ss.mmm ZON DDD MMM
## YYYY Connect time in NTP format.
26
9
28
C-
h323-call-type
String
Telephony,VOIP
30
27
C+
Called-Station-ID
String
DNIS
31
M+
Calling-Station-ID
Integer
ANI
40
M+
Acct-Status-Type
String
Acct-Status-Type = Start (1)
44
M+
Acct-Session-ID
Integer
Accounting Session ID
55
M-
Event-Timestamp
Integer
Event Time Stamp
61
M-
NAS-Port-Type
Integer
Ethernet (15)
Thanks
Ha`
Hi I?aki,
At first, I repied the PRACK without Route header but contian the to tag.
I added the Route header after receive your opinion. But also failed.
I attached my SIP message, could you please take a look them and give me some suggestion?
Thank you!
Best regards,
Steven Wu
UDP Data send to: 10.57.39.120:5060
INVITE sip:1141@10.57.39.120 SIP/2.0
Via: SIP/2.0/UDP 10.57.39.33:5060
From: sip:6846@10.57.39.120;tag=032baj647
To: sip:1141@10.57.39.120
Call-ID: asdbasdb3-asdb552
CSeq: 899 INVITE
Contact: sip:6846@10.57.39.33
Max-Forwards: 70
Content-Type: application/sdp
Expires: 180
Accept-Contact: *;+mckoppa
Supported: precondition, 100Rel
Require: precondition
Content-Length: 392
v=0
o=Inviter2007 63241204263093750 132223800 IN IP4 10.57.39.33
s=-
c=IN IP4 10.57.39.33
t=0 0
m=audio 5000 RTP/AVP 106 8 0
a=sendrecv
a=rtpmap:106 AMR/8000
a=ptime:160
a=maxptime:200
a=fmtp:106 octet-align=1; mode-set=7
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
UDP Data received from: 10.57.39.120:5060
SIP/2.0 183 Session Progress
Record-Route: <sip:10.57.39.120;lr=on>
Via: SIP/2.0/UDP 10.57.39.33:5060
Require: 100Rel
To: <sip:1141@10.57.39.120>;tag=53m9f85odqq1uld83vs6
Contact: <sip:0y9N9S0dFpYtlSrLGwwF@10.57.39.114>
From: <sip:6846@10.57.39.120>;tag=032baj647
Supported: 100Rel,precondition
RSeq: 2956138
Call-ID: asdbasdb3-asdb552
CSeq: 899 INVITE
Allow: UPDATE,PRACK,SUBSCRIBE,REFER,NOTIFY,INVITE,ACK,CANCEL,OPTIONS,BYE
Content-Type: application/sdp
Content-Length: 465
v=0
o=1141 63380817057795000 63380817057795000 IN IP4 10.57.39.114
s=-
c=IN IP4 10.57.39.114
t=0 0
m=audio 5000 RTP/AVP 106 8 0
a=sendrecv
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=conf:qos remote sendrecv
a=rtcp:5001 IN IP4 10.57.39.114
a=rtpmap:106 AMR/8000
a=ptime:160
a=maxptime:200
a=fmtp:106 octet-align=1; mode-set=7
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
UDP Data send to: 10.57.39.120:5060
PRACK sip:1141@10.57.39.120 SIP/2.0
Via: SIP/2.0/UDP 10.57.39.33:5060
From: sip:6846@10.57.39.120;tag=032baj647
To: sip:1141@10.57.39.120;tag=53m9f85odqq1uld83vs6
Call-ID: asdbasdb3-asdb552
CSeq: 89951 PRACK
Contact: sip:6846@10.57.39.33
Max-Forwards: 70
Route: <sip:10.57.39.120;lr=on>
Content-Type: application/sdp
Expires: 180
Accept-Contact: *;+mckoppa
Supported: precondition, 100Rel
Require: precondition
RAck:2956138 899 INVITE
Content-Length: 278
v=0
o=Inviter2007 63241204263093750 132223801 IN IP4 10.57.39.33
s=-
c=IN IP4 10.57.39.33
t=0 0
m=audio 5000 RTP/AVP 106
a=rtpmap:106 AMR/8000
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
If added a route rule 'if ( is_method("PRACK") ) { t_relay(); exit;} ' , I'll receive the 483 response.
Otherwise, receive 404 Not here
UDP Data received from: 10.57.39.120:5060
SIP/2.0 483 Too Many Hops
Via: SIP/2.0/UDP 10.57.39.33:5060
From: sip:6846@10.57.39.120;tag=032baj647
To: sip:1141@10.57.39.120;tag=53m9f85odqq1uld83vs6
Call-ID: asdbasdb3-asdb552
CSeq: 89951 PRACK
Server: OpenSER (1.3.1-notls (i386/linux))
Content-Length: 0
________________________________
From: users-bounces(a)lists.openser.org 代表 I?aki Baz Castillo
Sent: 2008-6-3 (星期二) 17:26
To: users(a)lists.openser.org
Subject: Re: [OpenSER-Users] how to configure to support PRACK
El Tuesday 03 June 2008 11:02:39 Steven Wu escribi:
> Hi All,
>
> Could someone tell me how to config openser 1.3.x route to support PRACK?
OpenSer doesn't need to do nothing to support PRACK (they are the endpoints
who support it or not).
PRACK is an in-dialog request, just it.
I suppose that the 183 OpenSer forwards to UAC contains a Record-Route added
by OpenSer in the INVITE, so the PRACK must contain a Route header and also
the To tag received in the 183. Then "has_totag" and "loose_route" return
true so a simple t_relay must work.
Nothing special must be done, I sure it by experience.
Regards.
--
Iaki Baz Castillo
ibc(a)in.ilimit.es
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
Hello Everyone, I was using openser for some time as a proxy registrar only with excellent results, now I need to do a more complex application.
The scenario is:
PSTN--DS3 Connection--CISCO AS5400 ----Openser
We have a Cisco AS5400 connected with a DS3 to the PSTN and need to terminate some traffic, however we need to block about 5,000 out of 120,000 possible destinations based in the first 6 digits of destination dialed.
For example, destination dialed is 13054941678. First, the leading 1 is removed, then if 305494 is in blacklist some message is sent back to sender (503 Service Unavailable). If 305494 is not in blacklist the call is routed to Cisco AS5400.
How do you think I can accomplish this without adding appreciable post-dial-delay and having 1 call per second?
Thank you for reading my post.
JP
Hello:
I am considering using OpenSER to implement Bridged Line Appearance (BLA) with Busy Lamp Field (BLF) using Polycom phones. The challenge is that I have other phones which I would like to include in a BLA configuration. Does anyone on this list have documentation showing how the "pua_bla" capability works including methods used, protocol flow, phones supported, etc?
Thanks,
Steve
Senior Network Engineer,
Information Systems and Computing
Networking and Telecommunications , Suite 221A /6228
University of Pennsylvania
Voice:215-573-8396
FAX:215-898-9348
Hey
I've got some openser servers running in db-only mode on the same database. Load for them is balanced using srv records, and they can handle exactly the same traffic -> standard clustering.
I wonder about procedure of shutting them down if something fails. Assuming that a new openser will be started with the same ip on another host if old one fails, should I allow old openser to shutdown as cleanly as it can, or should I cut the communication as soon as possible? What I worry about most, is -> does shutting down openser which handles a dialog at the moment cause it to send any packets that I wouldn't like to be sent in this scenario?
I think it works this way:
- If I cut the communication and kill all openser processes (kill, not term), I can assign the new ip faster because old host is in unknown/failed state anyways. But it may leave some unused stuff in database.
- If I allow it to close properly, it may cleanup it's state it database. But it may remove too much dialog data (which could be used by the backup host).
Which one is more likely?
Thanks,
Stan