Re: OpenH323 digest, Vol 1 #4119 - 4 msgs

openh323-request@xxxxxxxxxxxx wrote:

> Send OpenH323 mailing list submissions to
>         openh323@xxxxxxxxxxxx
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://www.openh323.org/mailman/listinfo/openh323
> or, via email, send a message with subject or body 'help' to
>         openh323-request@xxxxxxxxxxxx
>
> You can reach the person managing the list at
>         openh323-admin@xxxxxxxxxxxx
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OpenH323 digest..."
>
> Today's Topics:
>
>    1. Re: is there an open source IVR which plays pre-recorded video? (Leo)
>    2. Two excellent activex control to implement audio/video conference 
> easily. (=?gb2312?B?wdYguqPMzg==?=)
>    3. RE: Problem with SIP CANCEL in Opal (Damien Sandras)
>    4. Re: Proxy settings in Opal/SIP (Damien Sandras)
>
> --__--__--
>
> Message: 1
> Date: Fri, 18 Feb 2005 19:24:00 -0800 (PST)
> From: Leo <chihangl@xxxxxxxxx>
> Subject: Re: [OpenH323]is there an open source IVR which plays pre-recorded 
> video?
> To: openh323@xxxxxxxxxxxx
> Reply-To: openh323@xxxxxxxxxxxx
>
> You may want to take a look at
> H323_RTPChannel::Receive and ::Transmit, which should
> give you some ideas
>
> Actually, asterisk is another IVR that can achieve it
>
> leo
>
> Derek Li wrote:
>
> >
> > Could you give us some hints to achieve it?
> >
> > Thanks,
> > Derek
> >
> > On Fri, 18 Feb 2005 17:29:20 -0500 (EST), Dean
> Anderson <dean@xxxxxxx>  wrote:
> >
> >> OpenAM could probably be adapted to send video
> pretty easily.
> >>
> >> If you aren't up to it yourself, I (and others) can
> probably be employed
> >> to make the necessary adaptation.
> >>
> >>         --Dean
> >>
> >> On Fri, 18 Feb 2005, Thomas Earl wrote:
> >>
> >>> Derek,
> >>>
> >>> I haven't found one, but if you do PLEASE let me
> know. I'm really  looking
> >>> for one too!
> >>>
> >>> Thanks,
> >>>
> >>> Tom
> >>
> >>
> >
> >
>
>
> __________________________________
> Do you Yahoo!?
> All your favorites on one personal page ? Try My Yahoo!
> http://my.yahoo.com
>
> --__--__--
>
> Message: 2
> From: =?gb2312?B?wdYguqPMzg==?= <linht263@xxxxxxxxxxx>
> To: openh323@xxxxxxxxxxxx
> Date: Sat, 19 Feb 2005 14:33:19 +0000
> Subject: [OpenH323]Two excellent activex control to implement audio/video 
> conference easily.
> Reply-To: openh323@xxxxxxxxxxxx
>
> Hi,all
>
> I found a good website(http://www.lht2000.com) that can download
> audio/video activex control. You can use these acitvex to implement
> audio/video conference application or web application very easily.
>
> Josh
>
> --__--__--
>
> Message: 3
> Subject: RE: [OpenH323]Problem with SIP CANCEL in Opal
> From: Damien Sandras <dsandras@xxxxxxxxxxx>
> To: openh323@xxxxxxxxxxxx
> Cc: nick.hoath@xxxxxxxxxxxxxxxx
> Date: Sat, 19 Feb 2005 23:27:01 +0100
> Reply-To: openh323@xxxxxxxxxxxx
>
> Hello,
>
> I have fixed that in CVS.
>
> Le mardi 07 décembre 2004 à 13:36 +0000, Nick Hoath a écrit :
> > Robert,
> >
> >    I don't know whether you missed something in my explanation, or
> > that the phone I'm using isn't properly compliant. However, let me
> > expand a bit more on the problem.
> >     The INVITE and the CANCEL come from the same SIP phone. The ;tag=
> > is added by the OPAL SIP stack to the stored INVITE. The CANCEL then
> > arrives after the INVITE, so the SIP phone has no way to know about
> > the ;tag field that has been added to the copy of INVITE that the
> > SIPConnection keeps. It is therefore sending the same To field in the
> > CANCEL as it did in the INVITE.
> >    The problems is not that the tag that doesn't match - the tag is
> > not present in the CANCEL. As you can see from the messages below, the
> > messages match, but because the OPAL/SIP stack adds the ;tag= to the
> > To field (round about line 836 os sipcon.cxx), they don't match
> > internally.
> >
> > Here are copies of the two messages:
> >
> > ---------------------------------
> > INVITE sip:123 SIP/2.0
> > CSeq: 20 INVITE
> > Via: SIP/2.0/UDP 169.254.127.11:5060;branch=z9hG4bK859379897
> > From: <sip:10000@xxxxxxxxxxxxxx>;tag=2744102775
> > Call-ID: 2809317454@xxxxxxxxxxxxxx
> > To: <sip:123>
> > Contact: <sip:10000@xxxxxxxxxxxxxx>
> > Allow: INVITE,ACK,CANCEL,BYE,REFER,NOTIFY,INFO,REGISTER
> > Content-Type: application/sdp
> > Content-Length: 269
> > User-Agent: Clipcomm CP-101 v1.1.48 (041108)
> > Max-Forwards: 70
> >
> > v=0
> > o=10000 123456 654321 IN IP4 169.254.127.11
> > s=A conversation
> > c=IN IP4 169.254.127.11
> > t=0 0
> > m=audio 7080 RTP/AVP 4 0 8 18 101
> > a=rtpmap:4 G723/8000/1
> > a=rtpmap:0 PCMU/8000/1
> > a=rtpmap:8 PCMA/8000/1
> > a=rtpmap:18 G729/8000/1
> > a=rtpmap:101 telephone-event/8000/1
> >
> > ------------------------------------------
> > CANCEL sip:123 SIP/2.0
> > CSeq: 20 CANCEL
> > Via: SIP/2.0/UDP 169.254.127.11:5060;branch=z9hG4bK859379897
> > From: <sip:10000@xxxxxxxxxxxxxx>;tag=2744102775
> > Call-ID: 2809317454@xxxxxxxxxxxxxx
> > To: <sip:123>
> > Contact: <sip:10000@xxxxxxxxxxxxxx>
> > Allow: INVITE,ACK,CANCEL,BYE,REFER,NOTIFY,INFO,REGISTER
> > Content-Length: 0
> > User-Agent: Clipcomm CP-101 v1.1.48 (041108)
> > Max-Forwards: 70
> > -----------------------------------
> >
> >
> > Nick Hoath
> > Embedded Systems Development Manager
> > ISDN Communications Ltd
> >
> >
> >         -----Original Message-----
> >         From: Joegen E. Baclor [mailto:joegen@xxxxxxxxxxx]
> >         Sent: 07 December 2004 12:41
> >         To: openh323@xxxxxxxxxxxx
> >         Subject: Re: [OpenH323]Problem with SIP CANCEL in Opal
> >
> >
> >         Hi Nick,
> >
> >         If the SIP Phone does not send the same tag in CANCEL as it
> >         did in the original INVITE that opened the IST, then the
> >         client is uncompliant and CANCEL should be ignored.
> >
> >         I would construct CANCEL like this
> >
> >         1.  Check if final response is not received ( 2xx-6xx)
> >         2.  Clone the original Request URI of the INVITE and change
> >         the method to CANCEL
> >         3.  Clone the CSeq and set the CSeq method to "CANCEL"
> >         4.  Clone Original To:  header ( Including tag )
> >         5.  Clone Original From: Header
> >         6.  Clone Original Route Header Fields
> >         7.  Clone the Original Via.
> >
> >
> >         So unless, I missed something in your explanation, a tag
> >         mismatch, indeed, needs to be ignored.  This ensures that
> >         CANCEL is paired properly to the request being canceled since
> >         at this point a dialog may still be none existent.
> >
> >         Joegen
> >
> >                 ----- Original Message -----
> >                 From: Nick Hoath
> >                 To: openh323@xxxxxxxxxxxx
> >                 Sent: Tuesday, December 07, 2004 6:08 PM
> >                 Subject: [OpenH323]Problem with SIP CANCEL in Opal
> >
> >
> >                 Hi all,
> >
> >                    I've come across a slight oddity in the way the
> >                 CANCEL message in the SIP stack are handled. The
> >                 scenario is as follows:
> >
> >
> >                      SIP Phone
> >                 OPAL/SIP
> >
> >                         INVITE            
> > ------------------------------------>
> >                         CANCEL
> >                 ------------------------------------>
> >
> >                 When the CANCEL is received it is passed to the
> >                 SIPConnection::OnReceivedCANCEL method, where it is
> >                 checked against the stored INVITE (originalInvite) to
> >                 see if it is the originator cancelling the call.
> >                 However the stored INVITE has had
> >                 the ;tag=XXXXXXX added to the 'To' field, which means
> >                 that it doesn't match. There are a number of possible
> >                 solutions to the problem, but as I don't know enough
> >                 about SIP I'm not sure which is the correct one:
> >                     - Strip the ;tag off the To field in the stored
> >                 INVITE when doing the comparison.
> >                     - Add the ;tag to the To field in the CANCEL when
> >                 doing the comparison.
> >                    (These two would achieve the same end, but in
> >                 different ways)
> >                     - Compare the To fields as they currently are, and
> >                 if they don't match then try one of the above tests.
> >                 Would the CANCEL ever be received with the ;tag on it?
> >
> >                    This may of course only be happening as I haven't
> >                 yet put in the code to send a response to the INVITE,
> >                 but it may cause problems further down the line.
> >                 Nick Hoath
> >                 Embedded Systems Development Manager
> >                 ISDN Communications Ltd
> >
> >
> >                         -----Original Message-----
> >                         From: Ludovic Tant
> >                         [mailto:ludovic.tant@xxxxxxxxxxxxxx]
> >                         Sent: 07 December 2004 09:15
> >                         To: openh323@xxxxxxxxxxxx
> >                         Subject: Re: [OpenH323]OpenH323 thread model
> >
> >
> >                         Hello Yong,
> >
> >                         Before the incoming connection, there is one
> >                         thread (which waits for a call).
> >
> >                         After the connection is established, there are
> >                         two threads if you do only audio communication
> >                         (one sending audio frame and one receiving),
> >                         and four if you do audio and video.
> >
> >                         Between the beginning of the incoming call and
> >                         the end of negociation between your endpoint
> >                         and the caller, I don't know ;-(
> >
> >                         If you read the logs (use -t, -tt, -ttt etc.
> >                         when using openphone), you can see the thread
> >                         that write the current log line:
> >                         ...
> >                         0:00.842                 OpenPhone 0x8096c00
> >                         config.cxx(74)
> >                         ConfigFile::HasValue>end:h323.xxxx.Version
> >                         1.1.17 by OpenH323 Project on Unix Linux
> >                         (2.4.26-i686)
> >                           0:00.844        H323 Listener:80c4e90
> >                         0x80c4e90         transports.cxx(1354)  H323
> >                         Awaiting TCP connections on port 1720
> >                           0:11.485        H323 Listener:80c4e90
> >                         0x80c4e90         transports.cxx(1505)
> >                         H323TCP Started connection:
> >                         host=172.18.130.64:2523,
> >                         if=172.18.131.75:1720, handle=48
> >                           0:11.499          H225 Answer:80c3a30
> >                         0x80c3a30         connection.cxx(28)
> >                         XXXH323Connection::XXXH323Connection >
> >                           0:11.502          H225 Answer:80c3a30
> >                         0x80c3a30         connection.cxx(49)
> >                         XXXH323Connection::XXXH323Connection >
> >                         creating application
> >                           0:11.504          H225 Answer:80c3a30
> >                         0x80c3a30        application.cxx(33)
> >                         Application::Application(XXXH323Connection) >
> >                         ...
> >                         0x8096c00, 0x80c4e90 and 0x80c3a30 are the
> >                         addresses of differents threads.
> >
> >                         As far I am concerned, there isn't thread
> >                         pooling.
> >
> >                         I hope that it helps you,
> >
> >                         /ludovic
> >
> >                         Le lun 06/12/2004 à 09:01, GamersWand a
> >                         écrit :
> >                         > Hello group,
> >                         >
> >                         > I am wondering how thread is used in OpenH323. Is 
> > there one thread per
> >                         > connection, or other more sophisticated scheme 
> > involved? Does OpenH323 use
> >                         > thread pooling?
> >                         >
> >                         > TIA,
> >                         >
> >                         > Yong
> >                         >
> >                         > 
> > ------------------------------------------------------------------------
> >                         > Check the FAQ before asking! - 
> > http://www.openh323.org/~openh323/fom.cgi
> >                         > The OpenH323 Project mailing list, using Mailman. 
> > To unsubscribe or
> >                         > change your subscription options, goto
> >                         > http://www.openh323.org/mailman/listinfo/openh323
> >                         > Maintained by Quicknet Technologies, Inc - 
> > http://www.quicknet.net
> >                         > 
> > ------------------------------------------------------------------------
> --
>  _      Damien Sandras
> (o-     GnomeMeeting: http://www.gnomemeeting.org/
> //\     FOSDEM 2005 : http://www.fosdem.org
> v_/_    H.323 phone : callto:ils.seconix.com/dsandras@xxxxxxxxxxx
>
> --__--__--
>
> Message: 4
> Subject: Re: [OpenH323]Proxy settings in Opal/SIP
> From: Damien Sandras <dsandras@xxxxxxxxxxx>
> To: openh323@xxxxxxxxxxxx
> Cc: hadeel taha <hadeeltaha@xxxxxxxxx>
> Date: Sat, 19 Feb 2005 23:38:05 +0100
> Reply-To: openh323@xxxxxxxxxxxx
>
> Some PDU's were not sent to the proxy when one was specified. It should
> be fixed in CVS.
>
> Le vendredi 03 décembre 2004 à 01:55 -0800, hadeel taha a écrit :
> > Dear Robert,
> >
> > Here is a level 4 trace of what I said about not going
> > through proxy rather contacting the calling party
> > directly.
> >
> > in this example sip:444@xxxxxxxxxxxx SIPsoft telephon
> > calls sip:hadeel@xxxxxxxxxxxx which is simpleOpal app.
> > sip:141.19.97.36 is the Server address.
> >
> > I have noticed in my application that when I use
> >
> > SetProxy("sip:141.19.47.36");
> > I never receive a success registration from the server
> > after calling
> > Register(proxyName, userName, password);
> > while if I don't use
> > SetProxy("sip:141.19.47.36");
> >
> > the registration is OK.
> >
> > Here is the trace , first with
> > SetProxy("sip:141.19.47.36"); You can see that
> > simpleOpal is ignoring duplicate INVITE messages
> > coming from the server
> >
> >
> > 2004/12/03 10:36:51.765               main.cxx(87)    Level 4
> > Trace
> > 2004/12/03 10:36:51.765               main.cxx(88)    Level 3
> > Trace
> > 2004/12/03 10:36:51.765               main.cxx(89)    Level 2
> > Trace
> > 2004/12/03 10:36:51.765               main.cxx(90)    Level 1
> > Trace
> >   0:00.147                 SimpleOPAL
> > osutils.cxx(891)      SimpleOPAL      Version 1.0.0 by Open
> > Phone Abstraction Library on Windows 2000
> > (v5.0.2195-i586) at 2004/12/3 10:36:51.765
> >   0:00.219                 SimpleOPAL
> > transports.cxx(1752)  OpalUDP Started connect to
> > 141.19.47.36:5060
> >   0:00.224                 SimpleOPAL
> > sippdu.cxx(832)       SIP     No authentication information
> > available
> >   0:00.224       SIP Transport:2fee60
> > sipep.cxx(210)        SIP     Read thread started.
> >   0:38.676       Opal Listener:2fe6b0
> > sdp.cxx(175)  SDP     Attempt to set fmtp attributes for
> > unknown meda type g729
> >   0:38.686         SIP Handler:f83698
> > sipcon.cxx(1088)      SIP     PDU handler thread started.
> >   0:38.691       Opal Listener:2fe6b0
> > sdp.cxx(175)  SDP     Attempt to set fmtp attributes for
> > unknown meda type g729
> >   0:38.692         SIP Handler:f83698
> > sipcon.cxx(824)       SIP     OnIncomingConnection succeeded for
> > INVITE from sip:hadeel@xxxxxxxxxxxx;transport=udp for
> > Call[1]-EP<sip>[call-1102066619-1@xxxxxxxxxxxx]
> >   0:38.692         SIP Handler:f83698
> > sipcon.cxx(335)       SIP     SetAlerting
> >   0:38.693         SIP Handler:f83698
> > sipcon.cxx(790)       SIP     Ignoring duplicate INVITE from
> > sip:hadeel@xxxxxxxxxxxx;transport=udp for
> > Call[1]-EP<sip>[call-1102066619-1@xxxxxxxxxxxx]
> >   0:40.690       Opal Listener:2fe6b0
> > sdp.cxx(175)  SDP     Attempt to set fmtp attributes for
> > unknown meda type g729
> >   0:40.691         SIP Handler:f83698
> > sipcon.cxx(790)       SIP     Ignoring duplicate INVITE from
> > sip:hadeel@xxxxxxxxxxxx;transport=udp for
> > Call[1]-EP<sip>[call-1102066619-1@xxxxxxxxxxxx]
> >   0:43.615                 SimpleOPAL
> > sipcon.cxx(354)       SIP     SetConnected
> >   0:43.615                 SimpleOPAL
> > sdp.cxx(446)  SIP     RTP payload type [pt=96] not matched
> > to audio codec
> >   0:43.615                 SimpleOPAL
> > sdp.cxx(446)  SIP     RTP payload type [pt=97] not matched
> > to audio codec
> >   0:43.615                 SimpleOPAL
> > sdp.cxx(448)  SIP     RTP payload type PCMU matched to
> > audio codec G.711-uLaw-64k
> >   0:43.616                 SimpleOPAL
> > sdp.cxx(448)  SIP     RTP payload type PCMA matched to
> > audio codec G.711-ALaw-64k
> >   0:43.616                 SimpleOPAL
> > sdp.cxx(448)  SIP     RTP payload type G729 matched to
> > audio codec G.729
> >   0:43.616                 SimpleOPAL
> > sdp.cxx(448)  SIP     RTP payload type [pt=98] matched to
> > audio codec UserInput/RFC2833
> >   0:43.622                 SimpleOPAL
> > rtp.cxx(1639) RTP_UDP Session 1 created:
> > 141.19.96.42:5000-5001 ssrc=2745363192
> >   0:43.622                 SimpleOPAL
> > rtp.cxx(1437) RTP     Adding session RTP_UDP
> >   0:43.622                 SimpleOPAL
> > call.cxx(411) Call    OpenSourceMediaStreams for session
> > 1 with media
> > G.729,G.711-uLaw-64k,G.711-ALaw-64k,UserInput/RFC2833
> >   0:43.633                 SimpleOPAL
> > sipcon.cxx(387)       SIP     Could not find matching media type
> >   0:43.648                 SimpleOPAL
> > call.cxx(411) Call    OpenSourceMediaStreams for session
> > 1 with media G.711-uLaw-64k,G.711-ALaw-64k,PCM-16
> >   0:43.648                 SimpleOPAL
> > call.cxx(411) Call    OpenSourceMediaStreams for session
> > 2 with media PCM-16,G.711-uLaw-64k,G.711-ALaw-64k
> >   0:43.648                 SimpleOPAL
> > connection.cxx(419)   OpalCon OpenSourceMediaStream
> > session 2, could not find compatible media format:
> >   source formats=PCM-16,RGB24,RGB32,YUV420P
> >    sink  formats=PCM-16,G.711-uLaw-64k,G.711-ALaw-64k
> >   0:43.662                 SimpleOPAL
> > call.cxx(411) Call    OpenSourceMediaStreams for session
> > 1 with media G.711-uLaw-64k,G.711-ALaw-64k,PCM-16
> >   0:43.662                 SimpleOPAL
> > call.cxx(411) Call    OpenSourceMediaStreams for session
> > 2 with media G.711-uLaw-64k,G.711-ALaw-64k,PCM-16
> >   0:43.662                 SimpleOPAL
> > connection.cxx(419)   OpalCon OpenSourceMediaStream
> > session 2, could not find compatible media format:
> >   source
> > formats=G.729,G.711-uLaw-64k,G.711-ALaw-64k,UserInput/RFC2833
> >    sink  formats=G.711-uLaw-64k,G.711-ALaw-64k,PCM-16
> >   0:43.665         Media Patch:f95e80
> > jitter.cxx(285)       RTP     Jitter buffer created: size=51
> > delay=400-2000/400 (50ms) obj=0x00F8CC30
> >   0:43.667                 SimpleOPAL
> > connection.cxx(508)   OpalCon Media stream threads
> > started.
> >   0:43.667                 SimpleOPAL
> > connection.cxx(508)   OpalCon Media stream threads
> > started.
> >   0:43.696         SIP Handler:f83698
> > sipcon.cxx(832)       SIP     ACK received
> >   0:43.696         SIP Handler:f83698
> > connection.cxx(508)   OpalCon Media stream threads
> > started.
> >   0:43.866          RTP Jitter:f8cc30
> > rtp.cxx(1003) RTP     First data: ver=2 pt=PCMU psz=160
> > m=0 x=0 seq=64845 ts=2652339948 src=1728076108 ccnt=0
> >   0:43.904         SIP Handler:f83698
> > sipcon.cxx(844)       SIP     OPTIONS not yet supported
> >   0:44.697       Opal Listener:2fe6b0
> > sdp.cxx(175)  SDP     Attempt to set fmtp attributes for
> > unknown meda type g729
> >   0:44.698         SIP Handler:f83698
> > sipcon.cxx(790)       SIP     Ignoring duplicate INVITE from
> > sip:hadeel@xxxxxxxxxxxx;transport=udp for
> > Call[1]-EP<sip>[call-1102066619-1@xxxxxxxxxxxx]
> >   0:45.698         Media Patch:f83f48
> > rtp.cxx(966)  RTP     Transmit statistics:  packets=101
> > octets=16160 avgTime=20 maxTime=40 minTime=10
> >   0:45.914          RTP Jitter:f8cc30
> > rtp.cxx(1103) RTP     Receive statistics:  packets=101
> > octets=16160 lost=0 tooLate=0 order=0 avgTime=20
> > maxTime=76 minTime=14 jitter=0 maxJitter=8
> >   0:47.672         Media Patch:f83f48
> > rtp.cxx(966)  RTP     Transmit statistics:  packets=201
> > octets=32160 avgTime=19 maxTime=24 minTime=10
> >   0:47.915          RTP Jitter:f8cc30
> > rtp.cxx(1103) RTP     Receive statistics:  packets=201
> > octets=32160 lost=0 tooLate=0 order=0 avgTime=20
> > maxTime=21 minTime=19 jitter=0 maxJitter=8
> >   0:48.702       Opal Listener:2fe6b0
> > sdp.cxx(175)  SDP     Attempt to set fmtp attributes for
> > unknown meda type g729
> >   0:48.703         SIP Handler:f83698
> > sipcon.cxx(790)       SIP     Ignoring duplicate INVITE from
> > sip:hadeel@xxxxxxxxxxxx;transport=udp for
> > Call[1]-EP<sip>[call-1102066619-1@xxxxxxxxxxxx]
> >   0:49.647         Media Patch:f83f48
> > rtp.cxx(966)  RTP     Transmit statistics:  packets=301
> > octets=48160 avgTime=19 maxTime=22 minTime=10
> >   0:49.915          RTP Jitter:f8cc30
> > rtp.cxx(1103) RTP     Receive statistics:  packets=301
> > octets=48160 lost=0 tooLate=0 order=0 avgTime=20
> > maxTime=21 minTime=19 jitter=0 maxJitter=8
> >   0:51.622         Media Patch:f83f48
> > rtp.cxx(966)  RTP     Transmit statistics:  packets=401
> > octets=64160 avgTime=19 maxTime=25 minTime=10
> >   0:51.915          RTP Jitter:f8cc30
> > rtp.cxx(1103) RTP     Receive statistics:  packets=401
> > octets=64160 lost=0 tooLate=0 order=0 avgTime=20
> > maxTime=21 minTime=19 jitter=1 maxJitter=8
> >   0:52.707       Opal Listener:2fe6b0
> > sdp.cxx(175)  SDP     Attempt to set fmtp attributes for
> > unknown meda type g729
> >   0:52.708         SIP Handler:f83698
> > sipcon.cxx(790)       SIP     Ignoring duplicate INVITE from
> > sip:hadeel@xxxxxxxxxxxx;transport=udp for
> > Call[1]-EP<sip>[call-1102066619-1@xxxxxxxxxxxx]
> >   0:53.597         Media Patch:f83f48
> > rtp.cxx(966)  RTP     Transmit statistics:  packets=501
> > octets=80160 avgTime=19 maxTime=22 minTime=9
> >   0:53.916          RTP Jitter:f8cc30
> > rtp.cxx(1103) RTP     Receive statistics:  packets=501
> > octets=80160 lost=0 tooLate=0 order=0 avgTime=20
> > maxTime=21 minTime=19 jitter=0 maxJitter=8
> >   0:54.694         SIP Handler:f83698
> > sipcon.cxx(850)       SIP     BYE received for call
> > call-1102066619-1@xxxxxxxxxxxx
> >   0:54.708           OnRelease:f85d58
> > mediastrm.cxx(605)    Media   Closing raw media stream
> > OpalAudioMediaStream-Sink-PCM-16
> >   0:54.711         SIP Handler:f83698
> > sipcon.cxx(850)       SIP     BYE received for call
> > call-1102066619-1@xxxxxxxxxxxx
> >   0:54.796         SIP Handler:f83698
> > sipcon.cxx(1108)      SIP     PDU handler thread finished.
> >   0:54.799           OnRelease:f632b8
> > mediastrm.cxx(605)    Media   Closing raw media stream
> > OpalAudioMediaStream-Source-PCM-16
> >   0:54.799           OnRelease:f632b8
> > mediastrm.cxx(605)    Media   Closing raw media stream
> > OpalAudioMediaStream-Source-PCM-16
> >   0:54.799           OnRelease:f632b8
> > mediastrm.cxx(605)    Media   Closing raw media stream
> > OpalAudioMediaStream-Sink-PCM-16
> >   0:55.236                OpalGarbage
> > rtp.cxx(784)  RTP     Final statistics:
> >     packetsSent       = 556
> >     octetsSent        = 88960
> >     averageSendTime   = 19
> >     maximumSendTime   = 22
> >     minimumSendTime   = 9
> >     packetsReceived   = 540
> >     octetsReceived    = 86400
> >     packetsLost       = 0
> >     packetsTooLate    = 0
> >     packetsOutOfOrder = 0
> >     averageReceiveTime= 20
> >     maximumReceiveTime= 21
> >     minimumReceiveTime= 19
> >     averageJitter     = 0
> >     maximumJitter     = 8
> >   0:56.714       Opal Listener:2fe6b0
> > sdp.cxx(175)  SDP     Attempt to set fmtp attributes for
> > unknown meda type g729
> >   0:56.717         SIP Handler:f4da28
> > sipcon.cxx(1088)      SIP     PDU handler thread started.
> >   0:56.719         SIP Handler:f4da28
> > sipcon.cxx(824)       SIP     OnIncomingConnection succeeded for
> > INVITE from sip:hadeel@xxxxxxxxxxxx;transport=udp for
> > Call[2]-EP<sip>[call-1102066619-1@xxxxxxxxxxxx]
> >   1:00.720       Opal Listener:2fe6b0
> > sdp.cxx(175)  SDP     Attempt to set fmtp attributes for
> > unknown meda type g729
> >   1:00.721         SIP Handler:f4da28
> > sipcon.cxx(790)       SIP     Ignoring duplicate INVITE from
> > sip:hadeel@xxxxxxxxxxxx;transport=udp for
> > Call[2]-EP<sip>[call-1102066619-1@xxxxxxxxxxxx]
> >
> >
> >
> > ------------------------------------------------
> > ------------------------------------------------
> > ------------------------------------------------
> >
> > Trace without
> > SetProxy("sip:141.19.47.36");
> >
> > 2004/12/03 10:39:44.843               main.cxx(87)    Level 4
> > Trace
> > 2004/12/03 10:39:44.843               main.cxx(88)    Level 3
> > Trace
> > 2004/12/03 10:39:44.843               main.cxx(89)    Level 2
> > Trace
> > 2004/12/03 10:39:44.843               main.cxx(90)    Level 1
> > Trace
> >   0:00.014                 SimpleOPAL
> > osutils.cxx(891)      SimpleOPAL      Version 1.0.0 by Open
> > Phone Abstraction Library on Windows 2000
> > (v5.0.2195-i586) at 2004/12/3 10:39:44.843
> >   0:00.075                 SimpleOPAL
> > transports.cxx(1752)  OpalUDP Started connect to
> > 141.19.97.36:5060
> >   0:00.077       SIP Transport:2fed70
> > sipep.cxx(210)        SIP     Read thread started.
> >   0:00.079                 SimpleOPAL
> > sippdu.cxx(832)       SIP     No authentication information
> > available
> >   0:00.083       SIP Transport:2fed70
> > sipep.cxx(449)        SIP     Received Authentication Required
> > response
> >   0:00.085       SIP Transport:2fed70
> > sippdu.cxx(836)       SIP     Adding authentication information
> >   0:00.090       SIP Transport:2fed70
> > sipep.cxx(479)        SIP     Received REGISTER OK response
> >   0:04.238       Opal Listener:2fe4f8
> > sdp.cxx(175)  SDP     Attempt to set fmtp attributes for
> > unknown meda type g729
> >   0:04.241         SIP Handler:f85078
> > sipcon.cxx(1088)      SIP     PDU handler thread started.
> >   0:04.246         SIP Handler:f85078
> > sipcon.cxx(824)       SIP     OnIncomingConnection succeeded for
> > INVITE from sip:hadeel@xxxxxxxxxxxx;transport=udp for
> > Call[1]-EP<sip>[call-1102066759-2@xxxxxxxxxxxx]
> >   0:04.247         SIP Handler:f85078
> > sipcon.cxx(335)       SIP     SetAlerting
> >   0:04.649       Opal Listener:2fe4f8
> > sdp.cxx(175)  SDP     Attempt to set fmtp attributes for
> > unknown meda type g729
> >   0:04.650         SIP Handler:f85078
> > sipcon.cxx(790)       SIP     Ignoring duplicate INVITE from
> > sip:hadeel@xxxxxxxxxxxx;transport=udp for
> > Call[1]-EP<sip>[call-1102066759-2@xxxxxxxxxxxx]
> >   0:06.652       Opal Listener:2fe4f8
> > sdp.cxx(175)  SDP     Attempt to set fmtp attributes for
> > unknown meda type g729
> >   0:06.653         SIP Handler:f85078
> > sipcon.cxx(790)       SIP     Ignoring duplicate INVITE from
> > sip:hadeel@xxxxxxxxxxxx;transport=udp for
> > Call[1]-EP<sip>[call-1102066759-2@xxxxxxxxxxxx]
> >   0:07.270                 SimpleOPAL
> > sipcon.cxx(354)       SIP     SetConnected
> >   0:07.270                 SimpleOPAL
> > sdp.cxx(446)  SIP     RTP payload type [pt=96] not matched
> > to audio codec
> >   0:07.270                 SimpleOPAL
> > sdp.cxx(446)  SIP     RTP payload type [pt=97] not matched
> > to audio codec
> >   0:07.270                 SimpleOPAL
> > sdp.cxx(448)  SIP     RTP payload type PCMU matched to
> > audio codec G.711-uLaw-64k
> >   0:07.270                 SimpleOPAL
> > sdp.cxx(448)  SIP     RTP payload type PCMA matched to
> > audio codec G.711-ALaw-64k
> >   0:07.270                 SimpleOPAL
> > sdp.cxx(448)  SIP     RTP payload type G729 matched to
> > audio codec G.729
> >   0:07.270                 SimpleOPAL
> > sdp.cxx(448)  SIP     RTP payload type [pt=98] matched to
> > audio codec UserInput/RFC2833
> >   0:07.277                 SimpleOPAL
> > rtp.cxx(1639) RTP_UDP Session 1 created:
> > 141.19.96.42:5000-5001 ssrc=1058930976
> >   0:07.277                 SimpleOPAL
> > rtp.cxx(1437) RTP     Adding session RTP_UDP
> >   0:07.277                 SimpleOPAL
> > call.cxx(411) Call    OpenSourceMediaStreams for session
> > 1 with media
> > G.729,G.711-uLaw-64k,G.711-ALaw-64k,UserInput/RFC2833
> >   0:07.288                 SimpleOPAL
> > sipcon.cxx(387)       SIP     Could not find matching media type
> >   0:07.303                 SimpleOPAL
> > call.cxx(411) Call    OpenSourceMediaStreams for session
> > 1 with media G.711-uLaw-64k,G.711-ALaw-64k,PCM-16
> >   0:07.303                 SimpleOPAL
> > call.cxx(411) Call    OpenSourceMediaStreams for session
> > 2 with media PCM-16,G.711-uLaw-64k,G.711-ALaw-64k
> >   0:07.303                 SimpleOPAL
> > connection.cxx(419)   OpalCon OpenSourceMediaStream
> > session 2, could not find compatible media format:
> >   source formats=PCM-16,RGB24,RGB32,YUV420P
> >    sink  formats=PCM-16,G.711-uLaw-64k,G.711-ALaw-64k
> >   0:07.317                 SimpleOPAL
> > call.cxx(411) Call    OpenSourceMediaStreams for session
> > 1 with media G.711-uLaw-64k,G.711-ALaw-64k,PCM-16
> >   0:07.317                 SimpleOPAL
> > call.cxx(411) Call    OpenSourceMediaStreams for session
> > 2 with media G.711-uLaw-64k,G.711-ALaw-64k,PCM-16
> >   0:07.317                 SimpleOPAL
> > connection.cxx(419)   OpalCon OpenSourceMediaStream
> > session 2, could not find compatible media format:
> >   source
> > formats=G.729,G.711-uLaw-64k,G.711-ALaw-64k,UserInput/RFC2833
> >    sink  formats=G.711-uLaw-64k,G.711-ALaw-64k,PCM-16
> >   0:07.320         Media Patch:f8eea8
> > jitter.cxx(285)       RTP     Jitter buffer created: size=51
> > delay=400-2000/400 (50ms) obj=0x00F8EAD0
> >   0:07.322                 SimpleOPAL
> > connection.cxx(508)   OpalCon Media stream threads
> > started.
> >   0:07.323                 SimpleOPAL
> > connection.cxx(508)   OpalCon Media stream threads
> > started.
> >   0:07.341         SIP Handler:f85078
> > sipcon.cxx(832)       SIP     ACK received
> >   0:07.341         SIP Handler:f85078
> > connection.cxx(508)   OpalCon Media stream threads
> > started.
> >   0:07.387          RTP Jitter:f8ead0
> > rtp.cxx(1003) RTP     First data: ver=2 pt=PCMU psz=160
> > m=0 x=0 seq=65387 ts=2284361626 src=2919243114 ccnt=0
> >   0:07.404         SIP Handler:f85078
> > sipcon.cxx(844)       SIP     OPTIONS not yet supported
> >   0:09.355         Media Patch:f481c8
> > rtp.cxx(966)  RTP     Transmit statistics:  packets=101
> > octets=16160 avgTime=20 maxTime=40 minTime=10
> >   0:09.427          RTP Jitter:f8ead0
> > rtp.cxx(1103) RTP     Receive statistics:  packets=101
> > octets=16160 lost=0 tooLate=0 order=0 avgTime=20
> > maxTime=70 minTime=6 jitter=0 maxJitter=10
> >   0:10.658       Opal Listener:2fe4f8
> > sdp.cxx(175)  SDP     Attempt to set fmtp attributes for
> > unknown meda type g729
> >   0:10.659         SIP Handler:f85078
> > sipcon.cxx(790)       SIP     Ignoring duplicate INVITE from
> > sip:hadeel@xxxxxxxxxxxx;transport=udp for
> > Call[1]-EP<sip>[call-1102066759-2@xxxxxxxxxxxx]
> >   0:11.329         Media Patch:f481c8
> > rtp.cxx(966)  RTP     Transmit statistics:  packets=201
> > octets=32160 avgTime=19 maxTime=29 minTime=10
> >   0:11.427          RTP Jitter:f8ead0
> > rtp.cxx(1103) RTP     Receive statistics:  packets=201
> > octets=32160 lost=0 tooLate=0 order=0 avgTime=20
> > maxTime=27 minTime=13 jitter=0 maxJitter=10
> >   0:13.303         Media Patch:f481c8
> > rtp.cxx(966)  RTP     Transmit statistics:  packets=301
> > octets=48160 avgTime=19 maxTime=22 minTime=10
> >   0:13.428          RTP Jitter:f8ead0
> > rtp.cxx(1103) RTP     Receive statistics:  packets=301
> > octets=48160 lost=0 tooLate=0 order=0 avgTime=20
> > maxTime=21 minTime=19 jitter=0 maxJitter=10
> >   0:14.664       Opal Listener:2fe4f8
> > sdp.cxx(175)  SDP     Attempt to set fmtp attributes for
> > unknown meda type g729
> >   0:14.665         SIP Handler:f85078
> > sipcon.cxx(790)       SIP     Ignoring duplicate INVITE from
> > sip:hadeel@xxxxxxxxxxxx;transport=udp for
> > Call[1]-EP<sip>[call-1102066759-2@xxxxxxxxxxxx]
> >   0:14.678         SIP Handler:f85078
> > sipcon.cxx(850)       SIP     BYE received for call
> > call-1102066759-2@xxxxxxxxxxxx
> >   0:14.702           OnRelease:f5c980
> > mediastrm.cxx(605)    Media   Closing raw media stream
> > OpalAudioMediaStream-Sink-PCM-16
> >   0:14.786         SIP Handler:f85078
> > sipcon.cxx(1108)      SIP     PDU handler thread finished.
> >   0:14.787           OnRelease:f62df0
> > mediastrm.cxx(605)    Media   Closing raw media stream
> > OpalAudioMediaStream-Source-PCM-16
> >   0:14.787           OnRelease:f62df0
> > mediastrm.cxx(605)    Media   Closing raw media stream
> > OpalAudioMediaStream-Source-PCM-16
> >   0:14.787           OnRelease:f62df0
> > mediastrm.cxx(605)    Media   Closing raw media stream
> > OpalAudioMediaStream-Sink-PCM-16
> >   0:15.084                OpalGarbage
> > rtp.cxx(784)  RTP     Final statistics:
> >     packetsSent       = 370
> >     octetsSent        = 59200
> >     averageSendTime   = 19
> >     maximumSendTime   = 22
> >     minimumSendTime   = 10
> >     packetsReceived   = 363
> >     octetsReceived    = 58080
> >     packetsLost       = 0
> >     packetsTooLate    = 0
> >     packetsOutOfOrder = 0
> >     averageReceiveTime= 20
> >     maximumReceiveTime= 21
> >     minimumReceiveTime= 19
> >     averageJitter     = 0
> >     maximumJitter     = 10
> >
> >
> > Thank you very much for your support
> >
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Meet the all-new My Yahoo! - Try it today!
> > http://my.yahoo.com
> >
> >
> > ------------------------------------------------------------------------
> > Check the FAQ before asking! - http://www.openh323.org/~openh323/fom.cgi
> > The OpenH323 Project mailing list, using Mailman. To unsubscribe or
> > change your subscription options, goto
> > http://www.openh323.org/mailman/listinfo/openh323
> > Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
> > ------------------------------------------------------------------------
> --
>  _      Damien Sandras
> (o-     GnomeMeeting: http://www.gnomemeeting.org/
> //\     FOSDEM 2005 : http://www.fosdem.org
> v_/_    H.323 phone : callto:ils.seconix.com/dsandras@xxxxxxxxxxx
>
> --__--__--
>
> _______________________________________________
> OpenH323 mailing list
> OpenH323@xxxxxxxxxxxx
> http://www.openh323.org/mailman/listinfo/openh323
>
> End of OpenH323 Digest


------------------------------------------------------------------------
Check the FAQ before asking! - http://www.openh323.org/~openh323/fom.cgi
The OpenH323 Project mailing list, using Mailman. To unsubscribe or
change your subscription options, goto
http://www.openh323.org/mailman/listinfo/openh323
Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
------------------------------------------------------------------------