[Users] Re: Users Digest, Vol 8, Issue 14

Kenny Yeh kenny at artdio.com.tw
Mon Jan 9 03:54:45 CET 2006


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 at 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 at openser.org
>
>You can reach the person managing the list at
>	users-owner at 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 at gmail.com>
>Subject: [Users] uac_replace_from function
>To: users at openser.org
>Message-ID:
>	<6fbb529e0601060308p5a0eab32wafce0fcc5f04b286 at 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 at ow01.owtel.com>;tag=sBl2gLH6O1myyqL5.
>To: "92588819" <sip:92588819 at ow01.owtel.com>;tag=47C61DF4-26CD.
>Date: Fri, 06 Jan 2006 10:41:17 GMT.
>Call-ID: yTCQvS56ZCZXCHgt at 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 at 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 at voice-system.ro>
>Subject: Re: [Users] NAT+uac_replace_from
>To: unplug <maillisting at gmail.com>
>Cc: users at openser.org
>Message-ID: <43BE5474.4010400 at 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			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 at 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 at voice-system.ro>
>Subject: Re: [Users] uac_replace_from function
>To: unplug <maillisting at gmail.com>
>Cc: users at openser.org
>Message-ID: <43BE558C.70404 at 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 at ow01.owtel.com>;tag=sBl2gLH6O1myyqL5.
>> To: "92588819" <sip:92588819 at ow01.owtel.com>;tag=47C61DF4-26CD.
>> Date: Fri, 06 Jan 2006 10:41:17 GMT.
>> Call-ID: yTCQvS56ZCZXCHgt at 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 at 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 at 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 at voice-system.ro>
>Subject: Re: [Users] OpenSER and Solaris
>To: martin at campus-merseburg.de
>Cc: users at openser.org
>Message-ID: <43BEABBF.3090302 at 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 at 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 at 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 at 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 at gmail.com>
>Subject: [Users] Re: OpenSER and transport selection (SRV and NAPTR)
>To: users at openser.org
>Message-ID:
>	<8c7b802f0601061006p373d8949we5e48c9953eb8dc9 at 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:
>> >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
>> >
>> >
>> >
>> >
>>
>--
>Greg Fausak
>greg at thursday.com
>
>
>
>------------------------------
>
>Message: 6
>Date: Fri, 06 Jan 2006 19:47:10 +0100
>From: Alexander Philipp Lintenhofer <lintenhofer at aon.at>
>Subject: Re: [Users] help: what's tls_ca  tls_privat-key tls_calist
>To: users at openser.org
>Message-ID: <20060106194710.x2agnokfltq8ok4s at 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 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 您在来信中写道:=======
>>
>>> Send Users mailing list submissions to
>>> 	users at 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 at openser.org
>>>
>>> You can reach the person managing the list at
>>> 	users-owner at 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 at smartnet.no>
>>> Subject: Re: [Users] deactivate an account
>>> To: maillisting at gmail.com
>>> Cc: users at openser.org
>>> Message-ID: <1136456610.11157.10.camel at 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 at mydomain.com inactive
>>> Invalid privilege: inactive ignored
>>>
>>>
>>>
>>> --
>>> Mvh/Br
>>> Helge Waastad
>>> Senior Engineer
>>> Systemavdelingen
>>> Smartnet
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at openser.org
>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>> End of Users Digest, Vol 8, Issue 11
>>> ************************************
>>
>> = = = = = = = = = = = = = = = = = = = =
>>
>>
>>         �
>> 礼!
>>
>>
>>         Kenny Yeh
>>         kenny at artdio.com.tw
>>           2006-01-06
>>
>>
>
>
>
>
>
>
>------------------------------
>
>Message: 7
>Date: Fri, 6 Jan 2006 11:14:14 -0800 (PST)
>From: Jack Wei <cowlemon at yahoo.com>
>Subject: [Users] contact field port problem when behind nats
>To: users at openser.org
>Message-ID: <20060106191415.56473.qmail at 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 at voip.somewhere.com:5060;user=phone SIP/2.0.
>t:   <sip:2139435286 at voip.somewhere.com:5060;user=phone>.
>f: <sip:2139961998 at 2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
>Remote-Party-Id:
><sip:2139961998 at 2.2.2.2:5060;user=phone>;screen=no;id-type=subscriber;party=calling;privacy=off.
>i: dfc2b0e2-380-1e20393a at 2.2.2.2.
>CSeq: 7528304 INVITE.
>v: SIP/2.0/UDP 2.2.2.2:5060.
>Max-Forwards: 70.
>m: <sip:2139961998 at 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 at voip.somewhere.com:5060;user=phone>.
>f: <sip:2139961998 at 2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
>i: dfc2b0e2-380-1e20393a at 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 at 64.77.236.227 SIP/2.0.
>Record-Route:
><sip:2139435286 at voip.somewhere.com;ftag=20712b63-1e20393a-83ef4d40;lr=on>.
>t:   <sip:2139435286 at voip.somewhere.com:5060;user=phone>.
>f: <sip:2139961998 at 2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
>Remote-Party-Id:
><sip:2139961998 at 2.2.2.2:5060;user=phone>;screen=no;id-type=subscriber;party=calling;privacy=off.
>i: dfc2b0e2-380-1e20393a at 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 at 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 at 2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
>t: ""<sip:2139435286 at voip.somewhere.com:5060;user=phone>;tag=71451719939.
>i: dfc2b0e2-380-1e20393a at 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 at 2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
>t: "Jack
>Wei"<sip:2139435286 at voip.somewhere.com:5060;user=phone>;tag=71451719939.
>m: <sip:2139435286 at 64.77.236.227>.
>i: dfc2b0e2-380-1e20393a at 2.2.2.2.
>CSeq: 7528304 INVITE.
>l: 217.
>c: application/sdp.
>Server: SJphone/1.61.306c (SJ Labs).
>Record-Route:
><sip:2139435286 at 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 at 2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
>t: "Jack
>Wei"<sip:2139435286 at voip.somewhere.com:5060;user=phone>;tag=71451719939.
>m: <sip:2139435286 at 64.77.236.227>.
>i: dfc2b0e2-380-1e20393a at 2.2.2.2.
>CSeq: 7528304 INVITE.
>l: 217.
>c: application/sdp.
>Server: SJphone/1.61.306c (SJ Labs).
>Record-Route:
><sip:2139435286 at 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 at voip.somewhere.com;ftag=20712b63-1e20393a-83ef4d40;lr=on
>SIP/2.0.
>t:   <sip:2139435286 at voip.somewhere.com:5060;user=phone>;tag=71451719939.
>f: <sip:2139961998 at 2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
>i: dfc2b0e2-380-1e20393a at 2.2.2.2.
>CSeq: 7528304 ACK.
>v: SIP/2.0/UDP 2.2.2.2:5060.
>Max-Forwards: 70.
>Route: <sip:2139435286 at 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 at 64.77.236.227 SIP/2.0.
>Record-Route:
><sip:2139435286 at voip.somewhere.com;ftag=20712b63-1e20393a-83ef4d40;lr=on>.
>t:   <sip:2139435286 at voip.somewhere.com:5060;user=phone>;tag=71451719939.
>f: <sip:2139961998 at 2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
>i: dfc2b0e2-380-1e20393a at 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 at 2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
>t: "Jack
>Wei"<sip:2139435286 at voip.somewhere.com:5060;user=phone>;tag=71451719939.
>m: <sip:2139435286 at 64.77.236.227>.
>i: dfc2b0e2-380-1e20393a at 2.2.2.2.
>CSeq: 7528304 INVITE.
>l: 217.
>c: application/sdp.
>Server: SJphone/1.61.306c (SJ Labs).
>Record-Route:
><sip:2139435286 at 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 at 2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
>t: "Jack
>Wei"<sip:2139435286 at voip.somewhere.com:5060;user=phone>;tag=71451719939.
>m: <sip:2139435286 at 64.77.236.227>.
>i: dfc2b0e2-380-1e20393a at 2.2.2.2.
>CSeq: 7528304 INVITE.
>l: 217.
>c: application/sdp.
>Server: SJphone/1.61.306c (SJ Labs).
>Record-Route:
><sip:2139435286 at 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 at voip.somewhere.com;ftag=20712b63-1e20393a-83ef4d40;lr=on
>SIP/2.0.
>t:   <sip:2139435286 at voip.somewhere.com:5060;user=phone>;tag=71451719939.
>f: <sip:2139961998 at 2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
>i: dfc2b0e2-380-1e20393a at 2.2.2.2.
>CSeq: 7528304 ACK.
>v: SIP/2.0/UDP 2.2.2.2:5060.
>Max-Forwards: 70.
>Route: <sip:2139435286 at 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 at 64.77.236.227 SIP/2.0.
>Record-Route:
><sip:2139435286 at voip.somewhere.com;ftag=20712b63-1e20393a-83ef4d40;lr=on>.
>t:   <sip:2139435286 at voip.somewhere.com:5060;user=phone>;tag=71451719939.
>f: <sip:2139961998 at 2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
>i: dfc2b0e2-380-1e20393a at 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 at 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 at voip.somewhere.com:5060;user=phone>;tag=71451719939.
>t: <sip:2139961998 at 2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
>i: dfc2b0e2-380-1e20393a at 2.2.2.2.
>CSeq: 1 BYE.
>Max-Forwards: 70.
>User-Agent: SJphone/1.61.306c (SJ Labs).
>l: 0.
>Route:
><sip:2139435286 at voip.somewhere.com;ftag=20712b63-1e20393a-83ef4d40;lr=on>.
>.
>
>#
>U 1.1.1.1:5060 -> 2.2.2.2:5060
>BYE sip:2139961998 at 2.2.2.2:5060;user=phone SIP/2.0.
>Record-Route: <sip:2139961998 at 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 at voip.somewhere.com:5060;user=phone>;tag=71451719939.
>t: <sip:2139961998 at 2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
>i: dfc2b0e2-380-1e20393a at 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 at 2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
>f: "Jack Wei"
><sip:2139435286 at voip.somewhere.com:5060;user=phone>;tag=71451719939.
>i: dfc2b0e2-380-1e20393a at 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 at 2.2.2.2:5060;user=phone>;tag=20712b63-1e20393a-83ef4d40.
>f: "Jack Wei"
><sip:2139435286 at voip.somewhere.com:5060;user=phone>;tag=71451719939.
>i: dfc2b0e2-380-1e20393a at 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 at openser.org
>http://openser.org/cgi-bin/mailman/listinfo/users
>
>
>End of Users Digest, Vol 8, Issue 14
>************************************

= = = = = = = = = = = = = = = = = = = =
			

¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ÖÂ
Àñ£¡
 
				 
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Kenny Yeh
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡kenny at artdio.com.tw
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2006-01-09



More information about the Users mailing list