9 Jan
2006
9 Jan
'06
4:54 a.m.
Hi,Philipp
Thanks for your help !!!!!! You show me what I need .thanks!!!
======= 2006-01-07 03:15:05 �������������=======
Send Users mailing list submissions to
users(a)openser.org
To subscribe or unsubscribe via the World Wide Web, visit
http://openser.org/cgi-bin/mailman/listinfo/users
or, via email, send a message with subject or body 'help' to
users-request(a)openser.org
You can reach the person managing the list at
users-owner(a)openser.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Users digest..."
Today's Topics:
1. uac_replace_from function (unplug)
2. Re: NAT+uac_replace_from (Daniel-Constantin Mierla)
3. Re: uac_replace_from function (Daniel-Constantin Mierla)
4. Re: OpenSER and Solaris (Daniel-Constantin Mierla)
5. Re: OpenSER and transport selection (SRV and NAPTR) (Greg Fausak)
6. Re: help: what's tls_ca tls_privat-key tls_calist
(Alexander Philipp Lintenhofer)
7. contact field port problem when behind nats (Jack Wei)
----------------------------------------------------------------------
Message: 1
Date: Fri, 6 Jan 2006 19:08:34 +0800
From: unplug <maillisting(a)gmail.com>
Subject: [Users] uac_replace_from function
To: users(a)openser.org
Message-ID:
<6fbb529e0601060308p5a0eab32wafce0fcc5f04b286(a)mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
I am using uac_replace_from function as below.
# replace only display and do not touch uri
uac_replace_from("35418474","");
After running uac_replace_from function, I get the following message.
U 203.193.4.242:5060 -> 203.193.4.226:5060
SIP/2.0 183 Session Progress.
Via: SIP/2.0/UDP
203.193.4.226;branch=z9hG4bKaed7.46cc4101.0,SIP/2.0/UDP
10.0.0.52:5060;rport=5060;received=210.184.4.31;branch=z9hG4bKHNHpldVsKca6IYUS.
From: "35418474"<sip:882754853589@ow01.owtel.com>;tag=sBl2gLH6O1myyqL5.
To: "92588819" <sip:92588819@ow01.owtel.com>;tag=47C61DF4-26CD.
Date: Fri, 06 Jan 2006 10:41:17 GMT.
Call-ID: yTCQvS56ZCZXCHgt(a)10.0.0.52.
Server: Cisco-SIPGateway/IOS-12.x.
In the normal message, sip message, there is a space between display
name and uri.
ie. From: "35418474" <sip:882754853589@ow01.owtel.com>
However, after I apply uac_replace_from function, there is a space
there. How can I add a space such that it looks like a normal sip
message? Does the space will affect the caller display?
------------------------------
Message: 2
Date: Fri, 06 Jan 2006 13:28:52 +0200
From: Daniel-Constantin Mierla <daniel(a)voice-system.ro>
Subject: Re: [Users] NAT+uac_replace_from
To: unplug <maillisting(a)gmail.com>
Cc: users(a)openser.org
Message-ID: <43BE5474.4010400(a)voice-system.ro>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Send me the network traces for this case to see what is wrong. The uac
module has a mode when it should do automatic replacement in subsequent
requests.
Daniel
On 01/06/06 04:37, unplug wrote:
= = = = = = = = = = = = = = = = = = = =
������������������
��
����������������Kenny Yeh
����������������kenny(a)artdio.com.tw
��������������������2006-01-09
Thanks for your reply. According to your reply,
I add the following
code for the PRACK.
if (method=="PRACK") {
if (avp_db_load("$from/uri","s:alias")) {
xlog("L_INFO","sip408: have alias -
[$avp(s:alias)]\n");
uac_replace_from("anonymous","sip:$avp(s:alias)@$si");
} else {
xlog("L_INFO","sip411: no alias\n");
};
}
The result is the same as before. It seems there is a conflict in the
from header and it causes the 481 error. To be more precise, below is
the protocol flow.
UA1 server1 server2
fromtag:taga -----from username:9000 INVITE----->
fromtag:taga <----from username:9000 100 trying---
after uac_replace_from("1234","sip:1234@$si")
fromtag:taga ------from username:1234 INVITE ---->
(callee rings but caller drops)
fromtag:taga <-----from username:1234 100 trying----
(callee still rings until answers the call)
fromtag:taga <----from username:1234 session progress 183---
fromtag:taga <-----from username:9000 session prgress 183----
fromtag:taga -----from username:9000 PRACK----------->
fromtag:taga ----------from username:9000 PRACK--->
fromtag:taga <----from username:9000 481 call leg -----
fromtag:taga <----from username:9000 481 call leg -----
On 1/5/06, Daniel-Constantin Mierla <daniel(a)voice-system.ro> wrote:
------------------------------
Message: 3
Date: Fri, 06 Jan 2006 13:33:32 +0200
From: Daniel-Constantin Mierla <daniel(a)voice-system.ro>
Subject: Re: [Users] uac_replace_from function
To: unplug <maillisting(a)gmail.com>
Cc: users(a)openser.org
Message-ID: <43BE558C.70404(a)voice-system.ro>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
It might be a bug in the module, please send the original SIP reply as
well, to be able to trace the problem quicker.
Daniel
On 01/06/06 13:08, unplug wrote:
Hello,
"SIP/2.0 481 Call Leg/Transaction Does Not Exist" is for PRACK, because you do
not change the From header for it. You have to do the same translation for all requests
within the dialog. See the documentation of uac module: .
http://openser.org/docs/modules/1.1.x/uac.html
Cheers,
Daniel
On 01/04/06 12:21, unplug wrote:
> Actually, I am replacing the username of the uri with the alias that
> stored in the database. In my configuration file, it is using
> mediaproxy for NAT function (features-callfwd.5.0.cfg from getting
> started). I also add the following codes in the very first of the
> route routine for alias replacing purpose.
>
> route {
> ...
> if (!has_totag() && method=="INVITE") {
> if (avp_db_load("$from/uri","s:alias")) {
> xlog("L_INFO","sip408: have alias -
[$avp(s:alias)]\n");
>
uac_replace_from("anonymous","sip:$avp(s:alias)@$si");
> } else {
> xlog("L_INFO","sip411: no alias\n");
> };
> };
> ...
> }
>
> When I make a call from a phone to the PSTN phone, the caller drops
> the ring when the callee rings. Callee hangs up and callee rings
> again few seconds after. You can find an error message "SIP/2.0 481
> Call Leg/Transaction Does Not Exist" in line 180. I wonder if there
> is any thing wrong with the above code or my concept is wrong. Please
> help. Below is the sip message.
> [...]
>
>
I am using uac_replace_from function as below.
# replace only display and do not touch uri
uac_replace_from("35418474","");
After running uac_replace_from function, I get the following message.
U 203.193.4.242:5060 -> 203.193.4.226:5060
SIP/2.0 183 Session Progress.
Via: SIP/2.0/UDP
203.193.4.226;branch=z9hG4bKaed7.46cc4101.0,SIP/2.0/UDP
10.0.0.52:5060;rport=5060;received=210.184.4.31;branch=z9hG4bKHNHpldVsKca6IYUS.
From: "35418474"<sip:882754853589@ow01.owtel.com>;tag=sBl2gLH6O1myyqL5.
To: "92588819" <sip:92588819@ow01.owtel.com>;tag=47C61DF4-26CD.
Date: Fri, 06 Jan 2006 10:41:17 GMT.
Call-ID: yTCQvS56ZCZXCHgt(a)10.0.0.52.
Server: Cisco-SIPGateway/IOS-12.x.
In the normal message, sip message, there is a space between display
name and uri.
ie. From: "35418474" <sip:882754853589@ow01.owtel.com>
However, after I apply uac_replace_from function, there is a space
there. How can I add a space such that it looks like a normal sip
message? Does the space will affect the caller display?
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
------------------------------
Message: 4
Date: Fri, 06 Jan 2006 19:41:19 +0200
From: Daniel-Constantin Mierla <daniel(a)voice-system.ro>
Subject: Re: [Users] OpenSER and Solaris
To: martin(a)campus-merseburg.de
Cc: users(a)openser.org
Message-ID: <43BEABBF.3090302(a)voice-system.ro>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hello,
thanks for reporting, I have renamed the internal structure meminfo to
mem_info to avoid this conflict. Please take the latest 1.0.0 from cvs
and let me know if it works.
Here are the commands to get the stable version from cvs:
# export CVSROOT=:pserver:anonymous@cvs.sourceforge.net:/cvsroot/openser
# cvs login - for password simply press the Enter key.
# cvs -z3 checkout -r rel_1_0_0 sip-server
Cheers,
Daniel
On 01/06/06 12:45, martin(a)campus-merseburg.de wrote:
Hi,
does anyone use OpenSER under Solaris?
I get this error when compiling:
gcc -g -O9 -funroll-loops -Wall -mcpu=ultrasparc -mtune=ultrasparc
-DNAME='"openser"' -DVERSION='"1.0.0"'
-DARCH='"sparc64"'
-DOS='"solaris"' -DCOMPILER='"gcc 3.4"'
-D__CPU_sparc64
-D__OS_solaris -DCFG_DIR='"/usr/local/etc/openser/"' -DPKG_MALLOC
-DSHM_MEM -DSHM_MMAP -DDNS_IP_HACK -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP
-DDISABLE_NAGLE -DHAVE_RESOLV_RES -DF_MALLOC -DFAST_LOCK
-DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DHAVE_GETIPNODEBYNAME
-DHAVE_SYS_SOCKIO_H -DHAVE_SCHED_YIELD -DHAVE_ALLOCA_H -c action.c -o
action.o
In file included from mem/f_malloc.h:40,
from mem/mem.h:54,
from action.c:50:
mem/meminfo.h:33: error: redefinition of `struct meminfo'
gmake: *** [action.o] Error 1
any idea for fixing this?
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
------------------------------
Message: 5
Date: Fri, 6 Jan 2006 12:06:42 -0600
From: Greg Fausak <lgfausak(a)gmail.com>
Subject: [Users] Re: OpenSER and transport selection (SRV and NAPTR)
To: users(a)openser.org
Message-ID:
<8c7b802f0601061006p373d8949we5e48c9953eb8dc9(a)mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Howdy guys,
I completely missed this thread.
How is this going?
I just read the roadmap which indicates NAPTR lookup
is on the list. I've been maintaining NAPTR and SRV records
looking forward to the day when t_relay() forwards using NAPTR (and
SRV). Does that mean that the t_relay() will maintain the state, slogging
through the NAPTR/SRV records appropriately, without me having
to do additional logic??? Specifically, I'm keen on the SRV serial forking.
-g
Hi Bogdan,
I meant t_reply() will keep its behaviour as
looking into URI for the
destination - but it will incorporate the NAPTR lookup.
Great - this answers my question.
to response also to on earlier question,
regarding the timing
- I say 3 months are more than enough ;).
Excellent.
Many thanks for your help (and patience ;)
--Joachim
Joachim Fabini wrote:
--
Greg Fausak
greg(a)thursday.com
------------------------------
Message: 6
Date: Fri, 06 Jan 2006 19:47:10 +0100
From: Alexander Philipp Lintenhofer <lintenhofer(a)aon.at>
Subject: Re: [Users] help: what's tls_ca tls_privat-key tls_calist
To: users(a)openser.org
Message-ID: <20060106194710.x2agnokfltq8ok4s(a)liho.dyndns.org>
Content-Type: text/plain; charset=UTF-8; format="flowed"
Hi Kenny,
It would be a big deal first to acquire knowledge about the theoretical
background before installing this service.
So please read following (and related) sites:
http://www.tech-invite.com/Ti-sip-security.html
http://www.tech-invite.com/Ti-SSL.html
The definitive documentation about OpenSER/TLS
(http://openser.org/docs/tls.html) is very good and therefore easy to
understand in succession!
regards,
Philipp
Hi Bogdan,
indeed, there was a misunderstanding :) .t_relay()
with no
param will be kept with the current functionality.
Or you suggest to be able to specify only a different proto
or port from the RURI?
I did not yet find the primitive which is supposed to
statefully relay and do the following:
1. NAPTR query on the transport to use PLUS
2. _exactly_ what t_relay() does now for the
transport returned by the NAPTR query.
You say that t_relay() is kept with the current functionality.
Does this mean no NAPTR, or will t_relay() be extended to use
NAPTR before SRV/A query? If the latter then everything is OK.
Otherwise we have the alternatives:
t_relay() -> Stateful relaying according to destination
address using the incoming transport (no NAPTR).
t_relay_to() -> Stateful relaying to a specific host (you said
that <host> is mandatory here) using NAPTR to
determine the transport.
To summarize:
My point is that none of these two primitives covers the case
when the message is to be relayed to the next hop based only
on the destination address _and_ using the transport selected
by the destination proxy (determined via NAPTR query).
Except if either a) t_relay() does NAPTR or b) the host
parameter in t_relay_to() is optional.
--Joachim
Hello all,
I have tested tls with openser by SIPp,but I donn't understant
the flows of TLS ctreated,who can show me the flow about TLS
handshake.
When I test tls by SIPp,I put the ca,private-key to it's
DIR,that's fils created by openssl ,and add these files path to cfg
of openser.the same files used.I want to know what's mean is tls_ca
tls_privatekey tls_calist,and how there files work. Client need
what's ca and private-key for creating tls connection? Is it the same
with openssl? to create ssl connection?
======= 2006-01-05 19:01:27 您在来信中写道：=======
------------------------------
Message: 7
Date: Fri, 6 Jan 2006 11:14:14 -0800 (PST)
From: Jack Wei <cowlemon(a)yahoo.com>
Subject: [Users] contact field port problem when behind nats
To: users(a)openser.org
Message-ID: <20060106191415.56473.qmail(a)web50008.mail.yahoo.com>
Content-Type: text/plain; charset=iso-8859-1
Hi,
I'm having a problem when an UAC is behind NAT and has a public port other than
5060. The public port isn't present in the contact field so when an ACK for an
INVITE is sent to the UAC, it's directed to the default port of 5060. I'm
currently using v1.0.0 w/ the NATHELPER module. The UAC is SJphone. Any help
would be greatly appreciated.
NAT part of my openser.cfg :
if (nat_uac_test("19"))
{
if ( method == "REGISTER" )
{
fix_nated_register();
force_rport();
}
else
{
force_rport();
fix_nated_contact();
if (method == "INVITE")
{
fix_nated_sdp("1");
};
};
append_hf( "P-hint: NAT traversal\r\n" );
}
the sip proxy is voip.somewhere.com and 1.1.1.1
the pstn gateway is 2.2.2.2
the caller is from pstn and the callee is the uac.
Here's a log of SIP msgs:
#
U 2.2.2.2:5060 -> 1.1.1.1:5060
INVITE sip:2139435286@voip.somewhere.com:5060;user=phone SIP/2.0.
t: <sip:2139435286@voip.somewhere.com:5060;user=phone>.
f: <sip:2139961998@2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
Remote-Party-Id:
<sip:2139961998@2.2.2.2:5060;user=phone>;screen=no;id-type=subscriber;party=calling;privacy=off.
i: dfc2b0e2-380-1e20393a(a)2.2.2.2.
CSeq: 7528304 INVITE.
v: SIP/2.0/UDP 2.2.2.2:5060.
Max-Forwards: 70.
m: <sip:2139961998@2.2.2.2:5060;user=phone>.
k: replaces.
c: application/sdp.
Accept: application/sdp.
Accept-Encoding: .
Accept-Language: en.
User-Agent: Lucent-Universal-Gateway.
l: 244.
.
v=0.
o=VTX-SIP-TNT01 505428282 505428282 IN IP4 2.2.2.2.
s=Session SDP.
c=IN IP4 2.2.2.2.
t=0 0.
m=audio 41788 RTP/AVP 0 101.
a=silenceSupp:off.
a=ecan:b on g168.
a=ptime:20.
a=rtpmap:101 telephone-event/8000.
a=rtpmap:0 PCMU/8000.
#
U 1.1.1.1:5060 -> 2.2.2.2:5060
SIP/2.0 100 trying -- your call is important to us.
t: <sip:2139435286@voip.somewhere.com:5060;user=phone>.
f: <sip:2139961998@2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
i: dfc2b0e2-380-1e20393a(a)2.2.2.2.
CSeq: 7528304 INVITE.
v: SIP/2.0/UDP 2.2.2.2:5060.
Server: OpenSer (1.0.0-tls (i386/linux)).
Content-Length: 0.
.
#
U 1.1.1.1:5060 -> 64.77.236.227:32883
INVITE sip:2139435286@64.77.236.227 SIP/2.0.
Record-Route:
<sip:2139435286@voip.somewhere.com;ftag=20712b63-1e20393a-83ef4d40;lr=on>.
t: <sip:2139435286@voip.somewhere.com:5060;user=phone>.
f: <sip:2139961998@2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
Remote-Party-Id:
<sip:2139961998@2.2.2.2:5060;user=phone>;screen=no;id-type=subscriber;party=calling;privacy=off.
i: dfc2b0e2-380-1e20393a(a)2.2.2.2.
CSeq: 7528304 INVITE.
Via: SIP/2.0/UDP voip.somewhere.com;branch=z9hG4bK8325.35c96c63.0.
v: SIP/2.0/UDP 2.2.2.2:5060.
Max-Forwards: 69.
m: <sip:2139961998@2.2.2.2:5060;user=phone>.
k: replaces.
c: application/sdp.
Accept: application/sdp.
Accept-Encoding: .
Accept-Language: en.
User-Agent: Lucent-Universal-Gateway.
l: 244.
P-hint: VOIP OUTBOUND.
.
v=0.
o=VTX-SIP-TNT01 505428282 505428282 IN IP4 2.2.2.2.
s=Session SDP.
c=IN IP4 2.2.2.2.
t=0 0.
m=audio 41788 RTP/AVP 0 101.
a=silenceSupp:off.
a=ecan:b on g168.
a=ptime:20.
a=rtpmap:101 telephone-event/8000.
a=rtpmap:0 PCMU/8000.
#
U 64.77.236.227:32883 -> 1.1.1.1:5060
SIP/2.0 100 Trying.
v: SIP/2.0/UDP
voip.somewhere.com;received=1.1.1.1;branch=z9hG4bK8325.35c96c63.0,SIP/2.0/UDP
2.2.2.2:5060.
f: <sip:2139961998@2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
t:
""<sip:2139435286@voip.somewhere.com:5060;user=phone>;tag=71451719939.
i: dfc2b0e2-380-1e20393a(a)2.2.2.2.
CSeq: 7528304 INVITE.
l: 0.
Server: SJphone/1.61.306c (SJ Labs).
.
#
U 64.77.236.227:32883 -> 1.1.1.1:5060
SIP/2.0 200 OK.
v: SIP/2.0/UDP
voip.somewhere.com;received=1.1.1.1;branch=z9hG4bK8325.35c96c63.0,SIP/2.0/UDP
2.2.2.2:5060.
f: <sip:2139961998@2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
t: "Jack
Wei"<sip:2139435286@voip.somewhere.com:5060;user=phone>;tag=71451719939.
m: <sip:2139435286@64.77.236.227>.
i: dfc2b0e2-380-1e20393a(a)2.2.2.2.
CSeq: 7528304 INVITE.
l: 217.
c: application/sdp.
Server: SJphone/1.61.306c (SJ Labs).
Record-Route:
<sip:2139435286@voip.somewhere.com;ftag=20712b63-1e20393a-83ef4d40;lr=on>.
.
v=0.
o=- 3345559486 3345559486 IN IP4 64.77.236.227.
s=SJphone.
c=IN IP4 64.77.236.227.
t=0 0.
a=setup:active.
m=audio 49154 RTP/AVP 0 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-11,16.
#
U 1.1.1.1:5060 -> 2.2.2.2:5060
SIP/2.0 200 OK.
v: SIP/2.0/UDP 2.2.2.2:5060.
f: <sip:2139961998@2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
t: "Jack
Wei"<sip:2139435286@voip.somewhere.com:5060;user=phone>;tag=71451719939.
m: <sip:2139435286@64.77.236.227>.
i: dfc2b0e2-380-1e20393a(a)2.2.2.2.
CSeq: 7528304 INVITE.
l: 217.
c: application/sdp.
Server: SJphone/1.61.306c (SJ Labs).
Record-Route:
<sip:2139435286@voip.somewhere.com;ftag=20712b63-1e20393a-83ef4d40;lr=on>.
.
v=0.
o=- 3345559486 3345559486 IN IP4 64.77.236.227.
s=SJphone.
c=IN IP4 64.77.236.227.
t=0 0.
a=setup:active.
m=audio 49154 RTP/AVP 0 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-11,16.
#
U 2.2.2.2:5060 -> 1.1.1.1:5060
ACK sip:2139435286@voip.somewhere.com;ftag=20712b63-1e20393a-83ef4d40;lr=on
SIP/2.0.
t: <sip:2139435286@voip.somewhere.com:5060;user=phone>;tag=71451719939.
f: <sip:2139961998@2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
i: dfc2b0e2-380-1e20393a(a)2.2.2.2.
CSeq: 7528304 ACK.
v: SIP/2.0/UDP 2.2.2.2:5060.
Max-Forwards: 70.
Route: <sip:2139435286@64.77.236.227>.
User-Agent: Lucent-Universal-Gateway.
l: 0.
.
#
U 1.1.1.1:5060 -> 64.77.236.227:5060
ACK sip:2139435286@64.77.236.227 SIP/2.0.
Record-Route:
<sip:2139435286@voip.somewhere.com;ftag=20712b63-1e20393a-83ef4d40;lr=on>.
t: <sip:2139435286@voip.somewhere.com:5060;user=phone>;tag=71451719939.
f: <sip:2139961998@2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
i: dfc2b0e2-380-1e20393a(a)2.2.2.2.
CSeq: 7528304 ACK.
Via: SIP/2.0/UDP voip.somewhere.com;branch=0.
v: SIP/2.0/UDP 2.2.2.2:5060.
Max-Forwards: 69.
User-Agent: Lucent-Universal-Gateway.
l: 0.
P-hint: rr-enforced.
.
#
U 64.77.236.227:32883 -> 1.1.1.1:5060
SIP/2.0 200 OK.
v: SIP/2.0/UDP
voip.somewhere.com;received=1.1.1.1;branch=z9hG4bK8325.35c96c63.0,SIP/2.0/UDP
2.2.2.2:5060.
f: <sip:2139961998@2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
t: "Jack
Wei"<sip:2139435286@voip.somewhere.com:5060;user=phone>;tag=71451719939.
m: <sip:2139435286@64.77.236.227>.
i: dfc2b0e2-380-1e20393a(a)2.2.2.2.
CSeq: 7528304 INVITE.
l: 217.
c: application/sdp.
Server: SJphone/1.61.306c (SJ Labs).
Record-Route:
<sip:2139435286@voip.somewhere.com;ftag=20712b63-1e20393a-83ef4d40;lr=on>.
.
v=0.
o=- 3345559486 3345559486 IN IP4 64.77.236.227.
s=SJphone.
c=IN IP4 64.77.236.227.
t=0 0.
a=setup:active.
m=audio 49154 RTP/AVP 0 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-11,16.
#
U 1.1.1.1:5060 -> 2.2.2.2:5060
SIP/2.0 200 OK.
v: SIP/2.0/UDP 2.2.2.2:5060.
f: <sip:2139961998@2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
t: "Jack
Wei"<sip:2139435286@voip.somewhere.com:5060;user=phone>;tag=71451719939.
m: <sip:2139435286@64.77.236.227>.
i: dfc2b0e2-380-1e20393a(a)2.2.2.2.
CSeq: 7528304 INVITE.
l: 217.
c: application/sdp.
Server: SJphone/1.61.306c (SJ Labs).
Record-Route:
<sip:2139435286@voip.somewhere.com;ftag=20712b63-1e20393a-83ef4d40;lr=on>.
.
v=0.
o=- 3345559486 3345559486 IN IP4 64.77.236.227.
s=SJphone.
c=IN IP4 64.77.236.227.
t=0 0.
a=setup:active.
m=audio 49154 RTP/AVP 0 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-11,16.
#
U 2.2.2.2:5060 -> 1.1.1.1:5060
ACK sip:2139435286@voip.somewhere.com;ftag=20712b63-1e20393a-83ef4d40;lr=on
SIP/2.0.
t: <sip:2139435286@voip.somewhere.com:5060;user=phone>;tag=71451719939.
f: <sip:2139961998@2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
i: dfc2b0e2-380-1e20393a(a)2.2.2.2.
CSeq: 7528304 ACK.
v: SIP/2.0/UDP 2.2.2.2:5060.
Max-Forwards: 70.
Route: <sip:2139435286@64.77.236.227>.
User-Agent: Lucent-Universal-Gateway.
l: 0.
.
#
U 1.1.1.1:5060 -> 64.77.236.227:5060
ACK sip:2139435286@64.77.236.227 SIP/2.0.
Record-Route:
<sip:2139435286@voip.somewhere.com;ftag=20712b63-1e20393a-83ef4d40;lr=on>.
t: <sip:2139435286@voip.somewhere.com:5060;user=phone>;tag=71451719939.
f: <sip:2139961998@2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
i: dfc2b0e2-380-1e20393a(a)2.2.2.2.
CSeq: 7528304 ACK.
Via: SIP/2.0/UDP voip.somewhere.com;branch=0.
v: SIP/2.0/UDP 2.2.2.2:5060.
Max-Forwards: 69.
User-Agent: Lucent-Universal-Gateway.
l: 0.
P-hint: rr-enforced.
.
................<REPEAT OKs and ACKs>........................
#
U 64.77.236.227:32883 -> 1.1.1.1:5060
BYE sip:2139961998@2.2.2.2:5060;user=phone SIP/2.0.
v: SIP/2.0/UDP
192.168.0.100;rport;branch=z9hG4bKc0a800640000002243beb15e0000571700000028.
f: "Jack
Wei"<sip:2139435286@voip.somewhere.com:5060;user=phone>;tag=71451719939.
t: <sip:2139961998@2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
i: dfc2b0e2-380-1e20393a(a)2.2.2.2.
CSeq: 1 BYE.
Max-Forwards: 70.
User-Agent: SJphone/1.61.306c (SJ Labs).
l: 0.
Route:
<sip:2139435286@voip.somewhere.com;ftag=20712b63-1e20393a-83ef4d40;lr=on>.
.
#
U 1.1.1.1:5060 -> 2.2.2.2:5060
BYE sip:2139961998@2.2.2.2:5060;user=phone SIP/2.0.
Record-Route: <sip:2139961998@voip.somewhere.com;ftag=71451719939;lr=on>.
Via: SIP/2.0/UDP voip.somewhere.com;branch=z9hG4bK4f59.28705173.0.
v: SIP/2.0/UDP
192.168.0.100;received=64.77.236.227;rport=32883;branch=z9hG4bKc0a800640000002243beb15e0000571700000028.
f: "Jack
Wei"<sip:2139435286@voip.somewhere.com:5060;user=phone>;tag=71451719939.
t: <sip:2139961998@2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
i: dfc2b0e2-380-1e20393a(a)2.2.2.2.
CSeq: 1 BYE.
Max-Forwards: 69.
User-Agent: SJphone/1.61.306c (SJ Labs).
l: 0.
P-hint: NAT traversal.
P-hint: rr-enforced.
.
#
U 2.2.2.2:5060 -> 1.1.1.1:5060
SIP/2.0 200 OK.
v: SIP/2.0/UDP voip.somewhere.com;branch=z9hG4bK4f59.28705173.0.
v: SIP/2.0/UDP
192.168.0.100;received=64.77.236.227;rport=32883;branch=z9hG4bKc0a800640000002243beb15e0000571700000028.
t: <sip:2139961998@2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
f: "Jack Wei"
<sip:2139435286@voip.somewhere.com:5060;user=phone>;tag=71451719939.
i: dfc2b0e2-380-1e20393a(a)2.2.2.2.
CSeq: 1 BYE.
Server: Lucent-Universal-Gateway.
User-Agent: Lucent-Universal-Gateway.
l: 0.
.
#
U 1.1.1.1:5060 -> 64.77.236.227:32883
SIP/2.0 200 OK.
v: SIP/2.0/UDP
192.168.0.100;received=64.77.236.227;rport=32883;branch=z9hG4bKc0a800640000002243beb15e0000571700000028.
t: <sip:2139961998@2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
f: "Jack Wei"
<sip:2139435286@voip.somewhere.com:5060;user=phone>;tag=71451719939.
i: dfc2b0e2-380-1e20393a(a)2.2.2.2.
CSeq: 1 BYE.
Server: Lucent-Universal-Gateway.
User-Agent: Lucent-Universal-Gateway.
l: 0.
.
Jack Wei
__________________________________________
Yahoo! DSL ?Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com
------------------------------
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
End of Users Digest, Vol 8, Issue 14
************************************
Send Users mailing list submissions to
users(a)openser.org
To subscribe or unsubscribe via the World Wide Web, visit
http://openser.org/cgi-bin/mailman/listinfo/users
or, via email, send a message with subject or body 'help' to
users-request(a)openser.org
You can reach the person managing the list at
users-owner(a)openser.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Users digest..."
Today's Topics:
1. Re: deactivate an account (Helge Waastad)
----------------------------------------------------------------------
Message: 1
Date: Thu, 05 Jan 2006 11:23:30 +0100
From: Helge Waastad <helge(a)smartnet.no>
Subject: Re: [Users] deactivate an account
To: maillisting(a)gmail.com
Cc: users(a)openser.org
Message-ID: <1136456610.11157.10.camel(a)localhost.localdomain>
Content-Type: text/plain
Hi,
In the openserctl script there are acl options static configured
(free-pstn etc).
Just add inactive on the same line, and it should work
br hw
There is an error when I issue acl grant
openserctl acl grant myname(a)mydomain.com inactive
Invalid privilege: inactive ignored
--
Mvh/Br
Helge Waastad
Senior Engineer
Systemavdelingen
Smartnet
------------------------------
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
End of Users Digest, Vol 8, Issue 11
************************************
= = = = = = = = = = = = = = = = = = = =
�?
礼！
Kenny Yeh
kenny(a)artdio.com.tw
2006-01-06