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@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@openser.org
You can reach the person managing the list at users-owner@openser.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Users digest..."
Today's Topics:
- uac_replace_from function (unplug)
- Re: NAT+uac_replace_from (Daniel-Constantin Mierla)
- Re: uac_replace_from function (Daniel-Constantin Mierla)
- Re: OpenSER and Solaris (Daniel-Constantin Mierla)
- Re: OpenSER and transport selection (SRV and NAPTR) (Greg Fausak)
- Re: help: what's tls_ca tls_privat-key tls_calist (Alexander Philipp Lintenhofer)
- contact field port problem when behind nats (Jack Wei)
Message: 1 Date: Fri, 6 Jan 2006 19:08:34 +0800 From: unplug maillisting@gmail.com Subject: [Users] uac_replace_from function To: users@openser.org Message-ID: 6fbb529e0601060308p5a0eab32wafce0fcc5f04b286@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@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@voice-system.ro Subject: Re: [Users] NAT+uac_replace_from To: unplug maillisting@gmail.com Cc: users@openser.org Message-ID: 43BE5474.4010400@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:
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 server2fromtag: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@voice-system.ro 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. [...]
Message: 3 Date: Fri, 06 Jan 2006 13:33:32 +0200 From: Daniel-Constantin Mierla daniel@voice-system.ro Subject: Re: [Users] uac_replace_from function To: unplug maillisting@gmail.com Cc: users@openser.org Message-ID: 43BE558C.70404@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:
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@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@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@voice-system.ro Subject: Re: [Users] OpenSER and Solaris To: martin@campus-merseburg.de Cc: users@openser.org Message-ID: 43BEABBF.3090302@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@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@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@gmail.com Subject: [Users] Re: OpenSER and transport selection (SRV and NAPTR) To: users@openser.org Message-ID: 8c7b802f0601061006p373d8949we5e48c9953eb8dc9@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:
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:
- NAPTR query on the transport to use PLUS
- _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
-- Greg Fausak greg@thursday.com
Message: 6 Date: Fri, 06 Jan 2006 19:47:10 +0100 From: Alexander Philipp Lintenhofer lintenhofer@aon.at Subject: Re: [Users] help: what's tls_ca tls_privat-key tls_calist To: users@openser.org Message-ID: 20060106194710.x2agnokfltq8ok4s@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
Hello all,
I have tested tls with openser by SIPp,but I donn't understantthe 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'sDIR,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 您在来信中写道：=======
Send Users mailing list submissions to users@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@openser.org
You can reach the person managing the list at users-owner@openser.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Users digest..."
Today's Topics:
- Re: deactivate an account (Helge Waastad)
Message: 1 Date: Thu, 05 Jan 2006 11:23:30 +0100 From: Helge Waastad helge@smartnet.no Subject: Re: [Users] deactivate an account To: maillisting@gmail.com Cc: users@openser.org Message-ID: 1136456610.11157.10.camel@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@mydomain.com inactive Invalid privilege: inactive ignored
-- Mvh/Br Helge Waastad Senior Engineer Systemavdelingen Smartnet
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
End of Users Digest, Vol 8, Issue 11
= = = = = = = = = = = = = = = = = = = =
�? 礼！
Kenny Yeh kenny@artdio.com.tw 2006-01-06
Message: 7 Date: Fri, 6 Jan 2006 11:14:14 -0800 (PST) From: Jack Wei cowlemon@yahoo.com Subject: [Users] contact field port problem when behind nats To: users@openser.org Message-ID: 20060106191415.56473.qmail@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
End of Users Digest, Vol 8, Issue 14
= = = = = = = = = = = = = = = = = = = =
������������������ ��
����������������Kenny Yeh ����������������kenny@artdio.com.tw ��������������������2006-01-09