From sip-bounces@ietf.org Mon Jan 01 02:00:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1H85-0008Jz-GG; Mon, 01 Jan 2007 01:58:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1H84-0008Ju-KS for sip@ietf.org; Mon, 01 Jan 2007 01:58:40 -0500 Received: from [67.15.60.3] (helo=mail.aftek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1H82-00019r-JK for sip@ietf.org; Mon, 01 Jan 2007 01:58:40 -0500 Received: (qmail 535 invoked by uid 510); 1 Jan 2007 01:12:48 -0600 Received: from annasagaram.vamsi@aftek.com by plain.ev1servers.net by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.75.1. perlscan: 1.25-st-qms. Clear:RC:0(59.95.41.72):SA:0(-102.4/1.7):. Processed in 5.009438 secs); 01 Jan 2007 07:12:48 -0000 X-Spam-Status: No, hits=-102.4 required=1.7 X-Antivirus-MYDOMAIN-Mail-From: annasagaram.vamsi@aftek.com via plain.ev1servers.net X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:0(59.95.41.72):SA:0(-102.4/1.7):. Processed in 5.009438 secs Process 523) Received: from unknown (HELO annasagaramv) (annasagaram.vamsi@aftek.com@59.95.41.72) by mail.aftek.com with SMTP; 1 Jan 2007 01:12:43 -0600 From: "vamsi" To: "'Charles Kristofek'" , Subject: RE: [Sip] SMS via VoIP Date: Mon, 1 Jan 2007 12:35:53 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <07BB842D3E28D411804900508BAC02BD06FDA8E5@ams1> Thread-Index: AcctCDoIecMTWlWrSHSoSgUuT0LSXQAadqvA X-Antivirus-MYDOMAIN-Message-ID: <1167635564835523@plain.ev1servers.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Message-Id: Yes, now I am clear with the MESSAGE concept of paging mode and session mode. Thank you for your information. Is there any specific restriction for how long a MESSAGE should be sent in paging mode? -----Original Message----- From: Charles Kristofek [mailto:ckristofek@airnetcom.com] Sent: Sunday, December 31, 2006 11:35 PM To: 'vamsi'; sip@ietf.org Subject: RE: [Sip] SMS via VoIP Yes, the UAC can send/convey information one way to the UAS. This information flow feels like sending a message to a pager or sending an sms to a mobile. Previous discussion on instant message, SMS, MMS interworking: ---------------------------------------------------------------------- Message: 1 Date: Thu, 25 May 2006 15:37:15 +0200 From: "Jesus Javier Arauz \(E2/EEM\)" Subject: [Sipping] Re: Multi-media messaging and SIP To: Message-ID: <33D71F0FC0684C4C8A3BB76989EDED9C01C2138D@eesmdmw020.eemea.ericsson.se> Content-Type: text/plain; charset="us-ascii" OK, forget it. It's already done: draft-ietf-sipping-uri-list-conferencing-07 ---------------------------------------------------------------------- Message: 2 Date: Mon, 22 May 2006 12:04:03 +0200 From: "Jesus Javier Arauz \(E2/EEM\)" Subject: [Sipping] Multi-media messaging and SIP To: Message-ID: <33D71F0FC0684C4C8A3BB76989EDED9C01B82B3B@eesmdmw020.eemea.ericsson.se> Content-Type: text/plain; charset="us-ascii" Hi, In the SIP messaging specifications, the usage of MESSAGE is limited to small, short messages while for longer messages like e.g. multi-media messages including video, pictures etc. MSRP must be used instead. MESSAGE has been retro-fitted with a capability that enables a user to specify multiple destinations for a short message (see draft-ietf-sipping-uri-list-message-07). This capabilty needs a messaging server that explodes the list of destinations and sends the short message to each destination. However, SIP-based MSRP does not define that capability. The INVITE that initiates the MSRP session cannot be targeted to mutiple invitees by the inviting user. The UA must initiate the sessions individually to each destination and then send the message to all the destinations. This may lead to either more complex messaging client implementations in UA or cumbersome usage in comparison to the short messaging client. One case where this lack of capability is notorious is in SMS/MMS/IMPS interworking with IMS. When a GSM user sends an SMS to multiple destinations this can be directly mapped by the interworking function to a MESSAGE request including all the destinations in the request. However, when a GPRS user sends an MMS to multiple destinations, the interworking function must take care of initiating the SIP and MSRP sessions, send the message over all sessions and then releasing those sessions. The same goes for IMPS. I think it would be advantageous to retro-fit session-based messaging with the same capability as short messaging. One possible alternative would be to allow the same MIME body defined in draft-ietf-sipping-uri-list-message-07 in INVITE requests for MSRP sessions. However this may not seem appropriate since it impacts a rather basic message of the SIP specification. Any other alternative would require defining a new mechanism specific for long, multi-media messages, like e.g. content indirection. I wonder if there've been some discussions on this issue already? What's the oppinion of the sipping community on it? Best regards, /Javier Arauz ------------------------------ Message: 3 Date: Mon, 22 May 2006 09:34:56 -0400 From: "Dale R. Worley" Subject: Re: [Sipping] Multi-media messaging and SIP To: Sipping Message-ID: <1148304897.11977.10.camel@niagra.pingtel.com> Content-Type: text/plain On Mon, 2006-05-22 at 12:04 +0200, Jesus Javier Arauz (E2/EEM) wrote: > MESSAGE has been retro-fitted with a capability that enables a user to > specify multiple destinations for a short message (see draft-ietf- > sipping-uri-list-message-07). This capabilty needs a messaging server > that explodes the list of destinations and sends the short message to > each destination. However, SIP-based MSRP does not define that > capability. The INVITE that initiates the MSRP session cannot be > targeted to mutiple invitees by the inviting user. The UA must > initiate the sessions individually to each destination and then send > the message to all the destinations. This may lead to either more > complex messaging client implementations in UA or cumbersome usage in > comparison to the short messaging client. I'm not familiar with the details of MSRP, but I do not see why a forked INVITE cannot carry an MSRP set-up offer to more than one destination, each of which will reply with an MSRP set-up answer, thus setting up a set of MSRP sessions. (In exactly the same way that a single INVITE can establish multiple SDP sessions.) Oops, well, yes, you have to make sure the proxies that do the forking do not attempt to cancel all-but-one successful branch of the fork. But that's a known problem that applies to a lot more situations than setting up MSRP sessions. See, e.g., draft-worley-sipping-forking-00 for a discussion, especially section 3.6. Dale ------------------------------ Message: 5 Date: Mon, 22 May 2006 11:23:47 -0400 From: Richard Barnes Subject: Re: [Sipping] Multi-media messaging and SIP To: "Jesus Javier Arauz (E2/EEM)" Cc: sipping@ietf.org Message-ID: <4471D783.8080407@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed > However, when a GPRS user sends an MMS to multiple destinations, the > interworking function must take care of initiating the SIP and MSRP > sessions, send the message over all sessions and then releasing those > sessions. The same goes for IMPS. Beacuse MSRP is inherently session-oriented, I don't think you're going to get around having to initiate and release SIP/MSRP sessions. To simplify the internetworking function, perhaps what needs to be done is to define a way for MSRP relays to act as URI-list services. That way, the internetworking function could: 1. Send a forked INVITE to all recipients 2. Gather responses and construct URI-list 3. Send message and URI-list to URI-list Service The URI-list Service could then forward the message to all the recipients and relay MSRP REPORTs back to the internetworking function, who could then send BYE requests to close the SIP sessions. Given the constraints that MSRP is session-oriented (hence requires initiation/release), I think that's about as simple as it can get. (Actually, adding such a URI-list capability to MSRP relays seems like a good idea in general, since it would simplify the implementation of multi-party chat.) Hope this helps, --Richard > > I think it would be advantageous to retro-fit session-based messaging > with the same capability as short messaging. One possible alternative > would be to allow the same MIME body defined in > draft-ietf-sipping-uri-list-message-07 in INVITE requests for MSRP > sessions. However this may not seem appropriate since it impacts a > rather basic message of the SIP specification. Any other alternative > would require defining a new mechanism specific for long, multi-media > messages, like e.g. content indirection. > > I wonder if there've been some discussions on this issue already? > What's the oppinion of the sipping community on it? > > Best regards, > /Javier Arauz > > > > > ---------------------------------------------------------------------- End of Sipping Digest, Vol 25, Issue 28 *************************************** -----Original Message----- From: vamsi [mailto:annasagaram.vamsi@aftek.com] Sent: Sunday, December 31, 2006 7:13 AM To: 'Charles Kristofek'; sip@ietf.org Subject: RE: [Sip] SMS via VoIP In RFC 3428, section 3, " MESSAGE requests do not establish dialogs". Does "Paging mode" mean that with out establishing a actual/voice session, UA client can send IM to UA server? -----Original Message----- From: Charles Kristofek [mailto:ckristofek@airnetcom.com] Sent: Sunday, December 31, 2006 2:52 AM To: 'sip@ietf.org' Subject: RE: [Sip] SMS via VoIP There are 2 models in SIP for sending IMs (paging and session). Paging mode has the UA client sending the MESSAGE method to pass the information. Please refer to RFC 3428. Session mode has the UA client sending the INVITE method to establish a session first. For SMS via SIP, the MESSAGE method carrying the text within the body of the method to the SMSC (or application server) mimics 2G. The establishment of a session via INVITE mimics IM where peer information can be relayed, such as "typing". Chuck K. ------------------------------ Date: Fri, 29 Dec 2006 23:10:27 -0500 From: Dale.Worley@comcast.net Subject: Re: [Sip] SMS via VoIP To: sip@ietf.org Message-ID: <200612300410.kBU4ARqG023818@dragon.ariadne.com> From: "vamsi" Thanks for the message. But for MESSAGE conversation, what kind of codec is used, that is audio codec or any other specified codec? As per RFC 3551 Audio and video codecs are specified. A MESSAGE request contains the text content directly. See RFC 3438 for details. (I don't think anyone has specified how to carry recorded audio segments as messages.) For extended interchange of messages, as Fenar says, you set up a dialog (using INVITE) and specify the use of MSRP in the SDP. As others have noted, if you want to interoperage with 3GPP, its specificaitons are available. Dale ------------------------------ THIS E-MAIL MAY CONTAIN PRIVILEGED, CONFIDENTIAL, COPYRIGHTED, OR OTHER LEGALLY PROTECTED INFORMATION. IF YOU ARE NOT THE INTENDED RECIPIENT (EVEN IF THE E-MAIL ADDRESS ABOVE IS YOURS), YOU MAY NOT USE, COPY OR RETRANSMIT IT. IF YOU HAVE RECEIVED THIS BY MISTAKE, OR WISH TO BE REMOVED FROM A MAILING LIST, PLEASE NOTIFY US BY RETURN E-MAIL AT POSTMASTER@AIRNETCOM.COM, THEN DELETE. THANK YOU. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip THIS E-MAIL MAY CONTAIN PRIVILEGED, CONFIDENTIAL, COPYRIGHTED, OR OTHER LEGALLY PROTECTED INFORMATION. IF YOU ARE NOT THE INTENDED RECIPIENT (EVEN IF THE E-MAIL ADDRESS ABOVE IS YOURS), YOU MAY NOT USE, COPY OR RETRANSMIT IT. IF YOU HAVE RECEIVED THIS BY MISTAKE, OR WISH TO BE REMOVED FROM A MAILING LIST, PLEASE NOTIFY US BY RETURN E-MAIL AT POSTMASTER@AIRNETCOM.COM, THEN DELETE. THANK YOU. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 01 06:42:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1LXw-0006V6-Nj; Mon, 01 Jan 2007 06:41:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1LXu-0006Ux-DC for sip@ietf.org; Mon, 01 Jan 2007 06:41:38 -0500 Received: from web52802.mail.yahoo.com ([206.190.48.245]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H1LXr-0004Kt-MC for sip@ietf.org; Mon, 01 Jan 2007 06:41:38 -0500 Received: (qmail 72029 invoked by uid 60001); 1 Jan 2007 11:41:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DFUOX0uFygT7S7q2h7hoWX7BEpJnIephGOG0YWwEEkssk6qdvV4gCQV+2wtE5bMcWbGiFJAtUBlUZbUuxNGZOmu3le1TGXaKQV32qKq6PvB9Mje4zoIBMC+JHal4sYQUGIxUCUOMoijpJF8KKcXuMtGAYmMgJJPam4JWQ1cH8qk= ; Message-ID: <20070101114135.72027.qmail@web52802.mail.yahoo.com> Received: from [85.97.100.132] by web52802.mail.yahoo.com via HTTP; Mon, 01 Jan 2007 03:41:35 PST Date: Mon, 1 Jan 2007 03:41:35 -0800 (PST) From: =?iso-8859-1?Q?Fatih_Ey=FCp_NAR?= Subject: Re: [Sip] SMS via VoIP To: vamsi , Charles Kristofek , sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org RFC 3261 18.1.1=0A=0AIf a request is within 200 bytes of the path MTU, or i= f it is larger=0A than 1300 bytes and the path MTU is unknown, the reques= t MUST be sent=0A using an RFC 2914 [43] congestion controlled transport = protocol, such=0A as TCP. If this causes a change in the transport protoc= ol from the=0A one indicated in the top Via, the value in the top Via MUS= T be=0A changed. This prevents fragmentation of messages over UDP and=0A= provides congestion control for larger messages. However,=0A implemen= tations MUST be able to handle messages up to the maximum=0A datagram pac= ket size. For UDP, this size is 65,535 bytes, including=0A IP and UDP he= aders.=0A=0A=0A----- Original Message ----=0AFrom: vamsi =0ATo: Charles Kristofek ; sip@ietf.or= g=0ASent: Monday, January 1, 2007 9:05:53 AM=0ASubject: RE: [Sip] SMS via V= oIP=0A=0A=0AYes, now I am clear with the MESSAGE concept of paging mode and= session=0Amode. Thank you for your information. =0AIs there any specific= restriction for how long a MESSAGE should be sent in=0Apaging mode? =0A= =0A-----Original Message-----=0AFrom: Charles Kristofek [mailto:ckristofek@= airnetcom.com] =0ASent: Sunday, December 31, 2006 11:35 PM=0ATo: 'vamsi'; s= ip@ietf.org=0ASubject: RE: [Sip] SMS via VoIP=0A=0AYes, the UAC can send/co= nvey information one way to the UAS.=0AThis information flow feels like sen= ding a message to a pager or sending an=0Asms to a mobile.=0A=0APrevious di= scussion on instant message, SMS, MMS interworking:=0A=0A------------------= ----------------------------------------------------=0A=0AMessage: 1=0ADate= : Thu, 25 May 2006 15:37:15 +0200=0AFrom: "Jesus Javier Arauz \(E2/EEM\)"= =0A =0ASubject: [Sipping] Re: Multi-m= edia messaging and SIP=0ATo: =0AMessage-ID:=0A <33D71= F0FC0684C4C8A3BB76989EDED9C01C2138D@eesmdmw020.eemea.ericsson.se>=0AContent= -Type: text/plain; charset=3D"us-ascii"=0A=0AOK, forget it. It's alread= y done:=0Adraft-ietf-sipping-uri-list-conferencing-07=0A=0A----------------= ------------------------------------------------------=0A=0AMessage: 2=0ADa= te: Mon, 22 May 2006 12:04:03 +0200=0AFrom: "Jesus Javier Arauz \(E2/EEM\)"= =0A =0ASubject: [Sipping] Multi-media= messaging and SIP=0ATo: =0AMessage-ID:=0A<33D71F0FC0684C= 4C8A3BB76989EDED9C01B82B3B@eesmdmw020.eemea.ericsson.se>=0AContent-Type: te= xt/plain; charset=3D"us-ascii"=0A=0AHi,=0AIn the SIP messaging specificatio= ns, the usage of MESSAGE is limited to=0Asmall, short messages while for lo= nger messages like e.g. multi-media=0Amessages including video, pictures et= c. MSRP must be used instead.=0A=0AMESSAGE has been retro-fitted with a cap= ability that enables a user to=0Aspecify multiple destinations for a short = message (see=0Adraft-ietf-sipping-uri-list-message-07). This capabilty need= s a messaging=0Aserver that explodes the list of destinations and sends the= short message to=0Aeach destination. However, SIP-based MSRP does not defi= ne that capability.=0AThe INVITE that initiates the MSRP session cannot be = targeted to mutiple=0Ainvitees by the inviting user. The UA must initiate t= he sessions=0Aindividually to each destination and then send the message to= all the=0Adestinations. This may lead to either more complex messaging cli= ent=0Aimplementations in UA or cumbersome usage in comparison to the short= =0Amessaging client.=0A=0AOne case where this lack of capability is notorio= us is in SMS/MMS/IMPS=0Ainterworking with IMS. When a GSM user sends an SMS= to multiple destinations=0Athis can be directly mapped by the interworking= function to a MESSAGE=0Arequest including all the destinations in the requ= est.=0A=0AHowever, when a GPRS user sends an MMS to multiple destinations, = the=0Ainterworking function must take care of initiating the SIP and MSRP= =0Asessions, send the message over all sessions and then releasing those=0A= sessions. The same goes for IMPS.=0A=0AI think it would be advantageous to = retro-fit session-based messaging with=0Athe same capability as short messa= ging. One possible alternative would be to=0Aallow the same MIME body defin= ed in=0Adraft-ietf-sipping-uri-list-message-07 in INVITE requests for MSRP = sessions.=0AHowever this may not seem appropriate since it impacts a rather= basic=0Amessage of the SIP specification. Any other alternative would requ= ire=0Adefining a new mechanism specific for long, multi-media messages, lik= e e.g.=0Acontent indirection.=0A=0AI wonder if there've been some discussio= ns on this issue already? What's the=0Aoppinion of the sipping community on= it?=0A=0ABest regards,=0A/Javier Arauz=0A------------------------------=0A= Message: 3=0ADate: Mon, 22 May 2006 09:34:56 -0400=0AFrom: "Dale R. Worley"= =0ASubject: Re: [Sipping] Multi-media messaging and S= IP=0ATo: Sipping =0AMessage-ID: <1148304897.11977.10.came= l@niagra.pingtel.com>=0AContent-Type: text/plain=0A=0AOn Mon, 2006-05-22 at= 12:04 +0200, Jesus Javier Arauz (E2/EEM) wrote:=0A> MESSAGE has been retro= -fitted with a capability that enables a user to =0A> specify multiple dest= inations for a short message (see draft-ietf- =0A> sipping-uri-list-message= -07). This capabilty needs a messaging server =0A> that explodes the list o= f destinations and sends the short message to =0A> each destination. Howeve= r, SIP-based MSRP does not define that =0A> capability. The INVITE that ini= tiates the MSRP session cannot be =0A> targeted to mutiple invitees by the = inviting user. The UA must =0A> initiate the sessions individually to each = destination and then send =0A> the message to all the destinations. This ma= y lead to either more =0A> complex messaging client implementations in UA o= r cumbersome usage in =0A> comparison to the short messaging client.=0A=0AI= 'm not familiar with the details of MSRP, but I do not see why a forked=0AI= NVITE cannot carry an MSRP set-up offer to more than one destination, each= =0Aof which will reply with an MSRP set-up answer, thus setting up a set of= =0AMSRP sessions. (In exactly the same way that a single INVITE can establ= ish=0Amultiple SDP sessions.)=0A=0AOops, well, yes, you have to make sure t= he proxies that do the forking do=0Anot attempt to cancel all-but-one succe= ssful branch of the fork. But that's=0Aa known problem that applies to a l= ot more situations than setting up MSRP=0Asessions. See, e.g., draft-worle= y-sipping-forking-00 for a discussion,=0Aespecially section 3.6.=0A=0ADale= =0A------------------------------=0AMessage: 5=0ADate: Mon, 22 May 2006 11:= 23:47 -0400=0AFrom: Richard Barnes =0ASubject: Re: [Sippin= g] Multi-media messaging and SIP=0ATo: "Jesus Javier Arauz (E2/EEM)" =0ACc: sipping@ietf.org=0AMessage-ID: <4471D783.= 8080407@bbn.com>=0AContent-Type: text/plain; charset=3DISO-8859-1; format= =3Dflowed=0A=0A> However, when a GPRS user sends an MMS to multiple destina= tions, the =0A> interworking function must take care of initiating the SIP = and MSRP =0A> sessions, send the message over all sessions and then releasi= ng those =0A> sessions. The same goes for IMPS.=0A=0ABeacuse MSRP is inhere= ntly session-oriented, I don't think you're going to=0Aget around having to= initiate and release SIP/MSRP sessions.=0A=0ATo simplify the internetworki= ng function, perhaps what needs to be done is=0Ato define a way for MSRP re= lays to act as URI-list services. That way, the=0Ainternetworking function= could:=0A1. Send a forked INVITE to all recipients 2. Gather responses and= construct=0AURI-list 3. Send message and URI-list to URI-list Service The = URI-list=0AService could then forward the message to all the recipients and= relay MSRP=0AREPORTs back to the internetworking function, who could then = send BYE=0Arequests to close the SIP sessions. Given the constraints that = MSRP is=0Asession-oriented (hence requires initiation/release), I think tha= t's about=0Aas simple as it can get.=0A(Actually, adding such a URI-list ca= pability to MSRP relays seems like a=0Agood idea in general, since it would= simplify the implementation of=0Amulti-party chat.)=0A=0AHope this helps,= =0A--Richard=0A> =0A> I think it would be advantageous to retro-fit session= -based messaging =0A> with the same capability as short messaging. One poss= ible alternative =0A> would be to allow the same MIME body defined in=0A> d= raft-ietf-sipping-uri-list-message-07 in INVITE requests for MSRP =0A> sess= ions. However this may not seem appropriate since it impacts a =0A> rather = basic message of the SIP specification. Any other alternative =0A> would re= quire defining a new mechanism specific for long, multi-media =0A> messages= , like e.g. content indirection.=0A> =0A> I wonder if there've been some di= scussions on this issue already? =0A> What's the oppinion of the sipping co= mmunity on it?=0A> =0A> Best regards,=0A> /Javier Arauz=0A> =0A> =0A> =0A> = =0A> ----------------------------------------------------------------------= =0AEnd of Sipping Digest, Vol 25, Issue 28=0A=0A***************************= ************=0A=0A-----Original Message-----=0AFrom: vamsi [mailto:annasaga= ram.vamsi@aftek.com]=0ASent: Sunday, December 31, 2006 7:13 AM=0ATo: 'Charl= es Kristofek'; sip@ietf.org=0ASubject: RE: [Sip] SMS via VoIP=0A=0A=0AIn RF= C 3428, section 3, " MESSAGE requests do not establish dialogs".=0A=0ADoes = "Paging mode" mean that with out establishing a actual/voice session,=0AUA = client can send IM to UA server? =0A=0A=0A-----Original Message-----=0AFro= m: Charles Kristofek [mailto:ckristofek@airnetcom.com]=0ASent: Sunday, Dece= mber 31, 2006 2:52 AM=0ATo: 'sip@ietf.org'=0ASubject: RE: [Sip] SMS via VoI= P=0A=0A=0A=0AThere are 2 models in SIP for sending IMs (paging and session)= .=0A=0APaging mode has the UA client sending the MESSAGE method to pass the= =0Ainformation. Please refer to RFC 3428.=0A=0ASession mode has the UA clie= nt sending the INVITE method to establish a=0Asession first.=0A=0AFor SMS v= ia SIP, the MESSAGE method carrying the text within the body of the=0Ametho= d to the SMSC (or application server) mimics 2G.=0A=0AThe establishment of = a session via INVITE mimics IM where peer information=0Acan be relayed, suc= h as "typing".=0A=0AChuck K.=0A=0A------------------------------=0ADate: Fr= i, 29 Dec 2006 23:10:27 -0500=0AFrom: Dale.Worley@comcast.net=0ASubject: Re= : [Sip] SMS via VoIP=0ATo: sip@ietf.org=0AMessage-ID: <200612300410.kBU4ARq= G023818@dragon.ariadne.com>=0A=0A From: "vamsi" =0A=0A Thanks for the message. But for MESSAGE conversation, what ki= nd of=0A codec is used, that is audio codec or any other specified codec?= =0A As per RFC 3551 Audio and video codecs are specified.=0A=0AA MESSAGE = request contains the text content directly. See RFC 3438 for=0Adetails. (= I don't think anyone has specified how to carry recorded audio=0Asegments a= s messages.)=0A=0AFor extended interchange of messages, as Fenar says, you = set up a dialog=0A(using INVITE) and specify the use of MSRP in the SDP.=0A= =0AAs others have noted, if you want to interoperage with 3GPP, its=0Aspeci= ficaitons are available.=0A=0ADale=0A=0A=0A=0A-----------------------------= -=0A=0A=0ATHIS E-MAIL MAY CONTAIN PRIVILEGED, CONFIDENTIAL, COPYRIGHTED, O= R OTHER=0ALEGALLY PROTECTED INFORMATION. IF YOU ARE NOT THE INTENDED RECIP= IENT (EVEN=0AIF THE E-MAIL ADDRESS ABOVE IS YOURS), YOU MAY NOT USE, COPY O= R RETRANSMIT=0AIT. IF YOU HAVE RECEIVED THIS BY MISTAKE, OR WISH TO BE REM= OVED FROM A=0AMAILING LIST, PLEASE NOTIFY US BY RETURN E-MAIL AT=0APOSTMAST= ER@AIRNETCOM.COM, THEN DELETE. THANK YOU.=0A=0A___________________________= ____________________=0ASip mailing list https://www1.ietf.org/mailman/list= info/sip=0AThis list is for NEW development of the core SIP Protocol Use=0A= sip-implementors@cs.columbia.edu for questions on current sip Use=0Asipping= @ietf.org for new developments on the application of sip=0A=0A=0A=0A=0ATHIS= E-MAIL MAY CONTAIN PRIVILEGED, CONFIDENTIAL, COPYRIGHTED, OR OTHER =0ALE= GALLY PROTECTED INFORMATION. IF YOU ARE NOT THE INTENDED RECIPIENT =0A(EVE= N IF THE E-MAIL ADDRESS ABOVE IS YOURS), YOU MAY NOT USE, COPY =0AOR RETRAN= SMIT IT. IF YOU HAVE RECEIVED THIS BY MISTAKE, OR WISH TO BE=0AREMOVED FRO= M A MAILING LIST, PLEASE NOTIFY US BY RETURN E-MAIL AT=0APOSTMASTER@AIRNETC= OM.COM, THEN DELETE. THANK YOU.=0A=0A=0A=0A=0A____________________________= ___________________=0ASip mailing list https://www1.ietf.org/mailman/listi= nfo/sip=0AThis list is for NEW development of the core SIP Protocol=0AUse s= ip-implementors@cs.columbia.edu for questions on current sip=0AUse sipping@= ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 02 02:46:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1eJM-000722-3K; Tue, 02 Jan 2007 02:43:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1eJK-00071w-IM for sip@ietf.org; Tue, 02 Jan 2007 02:43:50 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1eJH-0007mH-Ra for sip@ietf.org; Tue, 02 Jan 2007 02:43:50 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l027gHdh011028; Tue, 2 Jan 2007 09:42:37 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 09:43:42 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 09:43:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Tue, 2 Jan 2007 09:41:06 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F032CE050@esebe103.NOE.Nokia.com> In-Reply-To: <2CDCB124-109D-40D8-9CDC-3B4A6914D5EF@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Thread-Index: AccsdT4QU8BeWkSzROe/cOROp04J5wByuXCA From: To: X-OriginalArrivalTime: 02 Jan 2007 07:43:42.0484 (UTC) FILETIME=[B997E540:01C72E41] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: sip@ietf.org, audet@nortel.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, While my email contained a lot of questions for you rather than a clear proposal I am not sure if we interpret each others opinion well enough to say we agree. Anyway to clarify my opinion - I agree with the proposal given for the poll: > Proposal 1: Make CRLF the only keepalive mechanism for TCP and TLS > over TCP flow (retain STUN for UDP flows). > > Proposal 2: Make outbound registrations over UDP flows optional for > UAs. > > Proposal 3: Include (in Outbound) the statement that its is > RECOMMENDED that the outbound-proxy-set is configured to result in > registrations over TCP or TLS whenever the UA can't accept incoming > TCP flows.=20 Do you agree with that ? As a summary what that would mean in terms of deployments: - Every Outbound compliant (UA or proxy) implementation MUST=20 support TCP but MAY support UDP too. - It will be up to the deployment to select whether TCP or UDP (or even both) shall be used for that specific deployment. Supporting UDP only would have known limitations and it would also mean that TCP-only implementations could not be used for that deployment. Erkki=20 >-----Original Message----- >From: ext Cullen Jennings [mailto:fluffy@cisco.com]=20 >Sent: 31.December.2006 02:48 >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) >Cc: audet@nortel.com; sip@ietf.org >Subject: Re: [Sip] Question about Poll: Proposal relating to=20 >keepalive, TCP,and UDP usage in draft-ietf-sip-outbound > > >It took me some time to parse through this but sounds like you and I =20 >are in 100% agreement on what an acceptable solution would look like. > > >On Dec 20, 2006, at 12:18 AM, =20 > wrote: > >> >> Hi Cullen, >> >>>> Many PSTN gateways and Softswitches always send large INVITEs for >>>> example, >>>> and they will always fragment. And I might add that many very =20 >>>> popular >>>> NAT/routers don't support UDP fragmentation. >>> >>> Hmm - I wish we had better specifics here - I will point out there >>> are millions of endpoints on well known residential endpoints that >>> are working through NATs and connected to PSTN gw and softwswiches >>> that are working over UDP. >> >> If so, then how would those endpoints get any benefit from Outbound ? >> What would be the value added for those deployments if those=20 >endpoints >> would be changed as Outbound UDP compliant endpoints ? Multiple >> registration support and new types of keepalive messages i.e. some >> added reliability ? >> >> But if those endpoints and proxies anyway have to be either upgraded >> or replaced for Outbound, then why couldn't that upgrade cover TCP >> support as well ? What is the ultimate benefit for using UDP instead >> of TCP for those deployments ? >> >>> Uh, no - I was saying that outbound over UDP is usable in=20 >cases where >>> the policy is to reject messages that are too large for UDP. I agree >>> that limits the functionality of the communications with the UA that >>> registered over this UDP only network but that was that deployments >>> choice. >>> >>> Note what I am talking about here is all about deployments using TCP >>> or UDP. I don't mind about if a UA has to implement both. >> >> Please remember that the proposal that you do not agree with was >> like this: >> >>> Proposal 2: Make outbound registrations over UDP flows optional for >>> UAs. >> >> Outbound over UDP would still be possible and probably supported by >> those UA vendors who get significant gain for it. But some UAs >> targetting to other deployments could just opt to support TCP. >> What is wrong with that ? >> >> If it is the deployments choice to limit the functionality of the >> communications with the UA registered, why could it not be possible >> for the specific closed deployments to administratively (or =20 >> technically) >> limit the deployed UAs to be such that implement UDP ? Why would you >> mandate ALL the implemented UAs to support UDP for Outbound ? Those >> deployments could just tell the users not to aqcuire any UAs which >> only support Outbound with TCP, if the proxies (or operator policy) >> does not support TCP (or does not support persistent TCP=20 >connections). >> >>>> You mean a UA will open two connections, one >>>> for UDP and another for TCP? I fail to see why on earth >>>> anybody would do this instead of just using a single TCP=20 >connection. >>> >>> I think the folks that favor these approach would use a scheme where >>> the UDP connection was long lived and the TCP connection was short >>> lived for the large messages. The advantages of this would be to get >>> the scaleability and reliability schemes that are easier=20 >with UDP yet >>> still be able to do large messages. >> >> Please remember the Outbound draft does make such a scheme possible ! >> If the UA does NOT have a long lived persistent TCP connection >> available, there is no way for the proxy to get the UA to open >> such connection or for the proxy itself open such a TCP connection >> towards the UA via the NAT when a large message arrives destined >> to the UA. So if the UA does not keep the TCP connection open >> all the time, it has to live with the limitation of not being >> able to receive SIP requests bigger than MTU if the NAT discards >> fragmented UDP packets. >> >> P.S. Actually there is such a mechanism for that specified in Marc >> Petit-Huguenin's I-D "Preventing Fragmentation for Client Initiated >> Connections in the Session Initiation Protocol (SIP)" - but that >> is not within the baseline Outbound spec and there is no normative >> binding between those specs either. >> >> Regards, >> >> Erkki > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 02 03:00:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1eZZ-0007se-S3; Tue, 02 Jan 2007 03:00:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1eZY-0007rb-J8 for sip@ietf.org; Tue, 02 Jan 2007 03:00:36 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1eZX-00037p-1I for sip@ietf.org; Tue, 02 Jan 2007 03:00:36 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l027wpXM025333; Tue, 2 Jan 2007 09:58:58 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 10:00:09 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 10:00:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Tue, 2 Jan 2007 09:59:53 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F032CE092@esebe103.NOE.Nokia.com> In-Reply-To: <1125AFAD-C978-40DC-8275-B0676AA5388D@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Thread-Index: AccsfQrkgw8odb+sSJCc5azRkm1KfQBxHA1Q From: To: , X-OriginalArrivalTime: 02 Jan 2007 08:00:11.0596 (UTC) FILETIME=[072668C0:01C72E44] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070102095858-62E1ABB0-20C75F71/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: fluffy@cisco.com, sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Me too: I also agree with #1 and #2. But when Outbound is used for NAT traversal I do not find #3 to add any value to #1. Switchover to=20 TCP (in the presence of NAT) can only be used if the UA always keeps=20 the TCP alive like in #1. The additional UDP flow does not bring=20 any significant value for the deployment. The only case where #3 might make some sense is that if 3GPP wants to support multiregistration of a single UA over different radio network types (cellular and WLAN) with Outbound. That use case=20 does not have anything to do with NAT traversal, so keepalives=20 would not be needed and switchover from UDP to TCP could be made=20 like in RFC 3261.=20 Regards, Erkki=20 >-----Original Message----- >From: ext Ben Campbell [mailto:ben@nostrum.com]=20 >Sent: 31.December.2006 03:41 >To: Adam Roach >Cc: Cullen Jennings; SIP >Subject: Re: [Sip] Question about Poll: Proposal relating to=20 >keepalive, TCP,and UDP usage in draft-ietf-sip-outbound > >I concur with Adam, with the caveat that any unforseen complexities =20 >that might be introduced by the phrase "not have the size limitations =20 >by using switchover" not block the work. That is, if 3 is free, or =20 >cheap, then great--but I would not want to significantly delay 1 and =20 >2 in order to get 3. > >On Dec 30, 2006, at 7:06 PM, Adam Roach wrote: > >> I agree 100% with #1 and #2. I find #3 to be of dubious value, =20 >> although I see no harm in a solution that has that property as well =20 >> (and you seem to get it for free if you satisfy #1 and #2). >> >> /a >> >> >> >> Cullen Jennings wrote: >>> >>> If the people who have been expressing strong opinions on the =20 >>> details of this proposal could comment on if they agree with these =20 >>> high level goals or not, it would be really helpful for trying to =20 >>> get this draft to move forward. >>> >>> On Dec 16, 2006, at 12:33 PM, Cullen Jennings wrote: >>> >>>> Practically speaking given where we are today, I would be a fan =20 >>>> of a solution that meant the following goals: >>>> >>>> 1) allowed deployments that wanted to use TCP to use TCP >>>> >>>> 2) allowed deployments that wanted to use UDP to use only UDP =20 >>>> with the known limitations that the UA would not be able to send =20 >>>> large requests >>>> >>>> 3) allowed deployments that wanted to use both UDP and TCP to do =20 >>>> so and not have the size limitations by using switchover >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 02 06:25:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1hkh-0002sS-4D; Tue, 02 Jan 2007 06:24:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzueW-00043c-0M for sip@ietf.org; Thu, 28 Dec 2006 07:46:32 -0500 Received: from web58306.mail.re3.yahoo.com ([68.142.236.159]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GzueT-0008Vg-MI for sip@ietf.org; Thu, 28 Dec 2006 07:46:31 -0500 Received: (qmail 81222 invoked by uid 60001); 28 Dec 2006 12:46:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=Pr8giaHwwXWcY2DZDQ6DDCBsrcucaUkJNqHQgNVS6/9ot9usR4AGEmmCc5Pf4iMj77Xu8YqgqxWv4ZhxDeW8xhrmUB+ByW6XuyhMeLxywY4VfAPeMmMzTnPR2RDAxBQKxr/r3xyiF9tafh1ss9Jjbub47dcO0jAez5G4HdFLY5M= ; Message-ID: <20061228124629.81220.qmail@web58306.mail.re3.yahoo.com> Received: from [59.95.41.72] by web58306.mail.re3.yahoo.com via HTTP; Thu, 28 Dec 2006 04:46:29 PST Date: Thu, 28 Dec 2006 04:46:29 -0800 (PST) From: saraka radha To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Tue, 02 Jan 2007 06:24:16 -0500 Subject: [Sip] SMS over VoIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0505493889==" Errors-To: sip-bounces@ietf.org --===============0505493889== Content-Type: multipart/alternative; boundary="0-231983650-1167309989=:79424" --0-231983650-1167309989=:79424 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Hi, =0A Can any one give pointers where to start for SMS over VoIP. An= y RFCs? Any pointer from where to start will be highly appreciable. =0A=0At= hanks & regards,=0A radha.=0A=0A___________________________________________= _______=0ADo You Yahoo!?=0ATired of spam? Yahoo! Mail has the best spam pr= otection around =0Ahttp://mail.yahoo.com --0-231983650-1167309989=:79424 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Hi,
=0A
     Can any one= give pointers where to start for SMS over VoIP.  Any RFCs? Any pointe= r from where to start will be highly appreciable.
=0A
 =0A
thanks & regards,
=0A
 radha.

__= ________________________________________________
Do You Yahoo!?
Tired= of spam? Yahoo! Mail has the best spam protection around
http://mail.= yahoo.com --0-231983650-1167309989=:79424-- --===============0505493889== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0505493889==-- From sip-bounces@ietf.org Tue Jan 02 06:25:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1hkg-0002sK-FV; Tue, 02 Jan 2007 06:24:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GznbJ-0004Gp-EK for sip@ietf.org; Thu, 28 Dec 2006 00:14:45 -0500 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GznbI-0000VG-8t for sip@ietf.org; Thu, 28 Dec 2006 00:14:45 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc14) with ESMTP id <2006122805144301400442c0e>; Thu, 28 Dec 2006 05:14:43 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kBS5Eh5M012023 for ; Thu, 28 Dec 2006 00:14:43 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kBS5EgQ2012014; Thu, 28 Dec 2006 00:14:42 -0500 Date: Thu, 28 Dec 2006 00:14:42 -0500 Message-Id: <200612280514.kBS5EgQ2012014@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <1167193977.4934.11.camel@sipx.cornfed.com> (fwmiller@cornfed.com) Subject: Re: [Sip] Routing NOTIFY requests References: <1167193977.4934.11.camel@sipx.cornfed.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-Mailman-Approved-At: Tue, 02 Jan 2007 06:24:15 -0500 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Frank W. Miller" Further assume that the Proxy added a Record-Route header to the SUBSCRIBE request. The dialog is established by the first request, in this case SUBSCRIBE. The route-set of the dialog is established by the Record-Route headers. All further requests in the dialog are routed based on the route-set. This holds regardless of the method of the request that establishes the dialog and the method within the dialog. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 02 06:25:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1hkh-0002sS-4D; Tue, 02 Jan 2007 06:24:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzueW-00043c-0M for sip@ietf.org; Thu, 28 Dec 2006 07:46:32 -0500 Received: from web58306.mail.re3.yahoo.com ([68.142.236.159]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GzueT-0008Vg-MI for sip@ietf.org; Thu, 28 Dec 2006 07:46:31 -0500 Received: (qmail 81222 invoked by uid 60001); 28 Dec 2006 12:46:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=Pr8giaHwwXWcY2DZDQ6DDCBsrcucaUkJNqHQgNVS6/9ot9usR4AGEmmCc5Pf4iMj77Xu8YqgqxWv4ZhxDeW8xhrmUB+ByW6XuyhMeLxywY4VfAPeMmMzTnPR2RDAxBQKxr/r3xyiF9tafh1ss9Jjbub47dcO0jAez5G4HdFLY5M= ; Message-ID: <20061228124629.81220.qmail@web58306.mail.re3.yahoo.com> Received: from [59.95.41.72] by web58306.mail.re3.yahoo.com via HTTP; Thu, 28 Dec 2006 04:46:29 PST Date: Thu, 28 Dec 2006 04:46:29 -0800 (PST) From: saraka radha To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Tue, 02 Jan 2007 06:24:16 -0500 Subject: [Sip] SMS over VoIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0505493889==" Errors-To: sip-bounces@ietf.org --===============0505493889== Content-Type: multipart/alternative; boundary="0-231983650-1167309989=:79424" --0-231983650-1167309989=:79424 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Hi, =0A Can any one give pointers where to start for SMS over VoIP. An= y RFCs? Any pointer from where to start will be highly appreciable. =0A=0At= hanks & regards,=0A radha.=0A=0A___________________________________________= _______=0ADo You Yahoo!?=0ATired of spam? Yahoo! Mail has the best spam pr= otection around =0Ahttp://mail.yahoo.com --0-231983650-1167309989=:79424 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Hi,
=0A
     Can any one= give pointers where to start for SMS over VoIP.  Any RFCs? Any pointe= r from where to start will be highly appreciable.
=0A
 =0A
thanks & regards,
=0A
 radha.

__= ________________________________________________
Do You Yahoo!?
Tired= of spam? Yahoo! Mail has the best spam protection around
http://mail.= yahoo.com --0-231983650-1167309989=:79424-- --===============0505493889== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0505493889==-- From sip-bounces@ietf.org Tue Jan 02 06:25:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1hkg-0002sK-FV; Tue, 02 Jan 2007 06:24:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GznbJ-0004Gp-EK for sip@ietf.org; Thu, 28 Dec 2006 00:14:45 -0500 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GznbI-0000VG-8t for sip@ietf.org; Thu, 28 Dec 2006 00:14:45 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc14) with ESMTP id <2006122805144301400442c0e>; Thu, 28 Dec 2006 05:14:43 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kBS5Eh5M012023 for ; Thu, 28 Dec 2006 00:14:43 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kBS5EgQ2012014; Thu, 28 Dec 2006 00:14:42 -0500 Date: Thu, 28 Dec 2006 00:14:42 -0500 Message-Id: <200612280514.kBS5EgQ2012014@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <1167193977.4934.11.camel@sipx.cornfed.com> (fwmiller@cornfed.com) Subject: Re: [Sip] Routing NOTIFY requests References: <1167193977.4934.11.camel@sipx.cornfed.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-Mailman-Approved-At: Tue, 02 Jan 2007 06:24:15 -0500 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Frank W. Miller" Further assume that the Proxy added a Record-Route header to the SUBSCRIBE request. The dialog is established by the first request, in this case SUBSCRIBE. The route-set of the dialog is established by the Record-Route headers. All further requests in the dialog are routed based on the route-set. This holds regardless of the method of the request that establishes the dialog and the method within the dialog. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 02 14:06:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1oxH-0004su-Jl; Tue, 02 Jan 2007 14:05:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1oxF-0004sn-RY for sip@ietf.org; Tue, 02 Jan 2007 14:05:45 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1oxD-0003kX-Bd for sip@ietf.org; Tue, 02 Jan 2007 14:05:45 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l02J5Yb20698; Tue, 2 Jan 2007 14:05:34 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Tue, 2 Jan 2007 13:05:31 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E8CE2B2@zrc2hxm0.corp.nortel.com> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F032CE050@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Thread-Index: AccsdT4QU8BeWkSzROe/cOROp04J5wByuXCAABgNHLA= From: "Francois Audet" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > As a summary what that would mean in terms of deployments: >=20 > - Every Outbound compliant (UA or proxy) implementation MUST > support TCP but MAY support UDP too. Personally, I think that it would be better if Outbound-compliant UAs (but not Proxies) also had to support UDP. But I can certainly live with either decision. > - It will be up to the deployment to select whether TCP or UDP > (or even both) shall be used for that specific deployment. Correct. A SIP service provider could decide to support TCP or UDP (or both) as they see fit for their deployment. Since clients would support both, it would be entirely a service=20 provider decision. > Supporting UDP only would have known limitations and it would > also mean that TCP-only implementations could not be used for > that deployment. To me, it's more a question of UDP not working in many cases where fragmentation may be an issue.=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 02 15:51:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1qaH-0004dR-KN; Tue, 02 Jan 2007 15:50:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1qaA-0004Do-CF; Tue, 02 Jan 2007 15:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1qaA-0002Sq-3k; Tue, 02 Jan 2007 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 14B0B328DA; Tue, 2 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H1qa9-0002mV-VN; Tue, 02 Jan 2007 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 02 Jan 2007 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-location-conveyance-06.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Session Initiation Protocol Location Conveyance Author(s) : J. Polk, B. Rosen Filename : draft-ietf-sip-location-conveyance-06.txt Pages : 35 Date : 2007-1-2 This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The extension covers end to end conveyance as well as location-based routing, where proxy servers make routing decisions based on the location of the UAC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-location-conveyance-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-location-conveyance-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-2112746.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-location-conveyance-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-location-conveyance-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-2112746.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Tue Jan 02 18:30:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1t4h-00066p-QV; Tue, 02 Jan 2007 18:29:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1t4h-00066a-5n for sip@ietf.org; Tue, 02 Jan 2007 18:29:43 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1t4e-0000TC-Pw for sip@ietf.org; Tue, 02 Jan 2007 18:29:43 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 02 Jan 2007 15:29:35 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l02NTaxL016272 for ; Tue, 2 Jan 2007 15:29:36 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l02NTZ4g026884 for ; Tue, 2 Jan 2007 15:29:35 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 18:29:35 -0500 Received: from jmpolk-wxp.cisco.com ([10.89.16.141]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 18:29:35 -0500 Message-Id: <4.3.2.7.2.20070102163723.03594f08@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 02 Jan 2007 17:29:18 -0600 To: sip@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 02 Jan 2007 23:29:35.0165 (UTC) FILETIME=[DCD3C6D0:01C72EC5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1662; t=1167780576; x=1168644576; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20New=20Location=20Conveyance=20-06=20submitted |Sender:=20; bh=eDVhJSKIW4amOycERPtLfC1MnviZ9wb8Wcl2uE3Rvkg=; b=y5hsvvP8MFZwzDwy7BmgWd8g/w4AL/Mev28cPKHvpNcMaUpeXD9nr8AL8oAYpP5Kec60njVm LlBtHxhjXqJe0mbhnqQKNRxglkQVo7f41AVFZl9xAakJqDJAqo0aR0u+; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Sip] New Location Conveyance -06 submitted X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've submitted the -06 version of Location Conveyance for review http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-06.txt This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The extension covers end to end conveyance as well as location-based routing, where proxy servers make routing decisions based on the location of the UAC. The changes from -05 to -06 are as follows: - cleaned up some inconsistencies wrt the S/MIME example in Section 4.2 - changed the ABNF to include the ability to indicate which SIP element inserted a particular location URI, and how a message routing server indicates which location the message was routed upon (based on the location in the message) - give examples of the above in section 5.3.1 - changed the granular error code from a Reason header indication to a Warning code indication (section 3.4), and IANA registered 14 new Warning codes in this document - As a consequence of the above bullet, changed the specific SIP element behaviors of each SIP element regarding sending or receiving a 424 response with a Warning header - Added rules about indicating which SIP element inserted a particular location into a message (a new Geolocation header parameter), as well as when a server adds another new header parameter indicating the request was routed based on a particular location included in the message Please comment James _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 03 13:33:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2AuD-0001bM-0B; Wed, 03 Jan 2007 13:32:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2AuA-0001aV-VA for sip@ietf.org; Wed, 03 Jan 2007 13:32:02 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Au8-00074A-Nd for sip@ietf.org; Wed, 03 Jan 2007 13:32:02 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l03IVvR02889; Wed, 3 Jan 2007 13:31:57 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Wed, 3 Jan 2007 12:31:55 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711213EA4B@zrc2hxm2.corp.nortel.com> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F032CE050@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Thread-Index: AccsdT4QU8BeWkSzROe/cOROp04J5wByuXCAAEk9TLA= From: "Brian Stucker" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: sip@ietf.org, Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com]=20 > Sent: Tuesday, January 02, 2007 1:41 AM <>=20 > As a summary what that would mean in terms of deployments: >=20 > - Every Outbound compliant (UA or proxy) implementation MUST > support TCP but MAY support UDP too. May support UDP for Outbound, or may support UDP, period? Unless I'm missing something somewhere, section 18 of RFC-3261 still says that all SIP elements MUST implement UDP. >=20 > - It will be up to the deployment to select whether TCP or UDP > (or even both) shall be used for that specific deployment. > Supporting UDP only would have known limitations and it would > also mean that TCP-only implementations could not be used for > that deployment. >=20 > Erkki=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 03 13:43:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2B4t-0007fJ-BW; Wed, 03 Jan 2007 13:43:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2B4r-0007dX-C1 for sip@ietf.org; Wed, 03 Jan 2007 13:43:05 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2B4q-0000De-0o for sip@ietf.org; Wed, 03 Jan 2007 13:43:05 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l03IgsR03961; Wed, 3 Jan 2007 13:42:54 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Wed, 3 Jan 2007 12:42:52 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711213EA6F@zrc2hxm2.corp.nortel.com> In-Reply-To: <458F1308.2070601@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Thread-Index: Accntj4fVTXVo5VBQFSG/Hxf2fGOKwHrz62g From: "Brian Stucker" To: "Dean Willis" , "Cullen Jennings" X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: SIP , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean, Deployments don't need to support the Very Important Stuff you mention below to see problems with UDP fragmentation across NATs. Just support an event package with some honkin' XML sizes like presence, you'll see it pretty quickly then. I think the big problem in the UDP vs. TCP debate is that end customers do not perceive the choice in transport protocol as being something that provides them with significant value. Because of that, they don't push their vendors to support it (as evidenced by the large amount of UDP equipment running around out there) and the system engineering requirements for TCP are viewed to be significantly different from UDP. The reason I am pointing this out is because we're trying to fix the problem by forcing people's hand's in the standard, which I believe is ultimately going to fail. People will put in whatever they need to continue to avoid the cost of developing proper TCP support until the market demands TCP be supported (meaning that they can no longer avoid the cost because they won't be able to deploy any equipment without it). IMHO-- we should be flexible in this regard. Make sure that the UDP behavior is at least minimally specified in the standard (warts and all) and then work outside of standards with customers so that they fully appreciate (and properly value) what they're getting with TCP that they're not getting with UDP. At that point I think the whole debate will resolve itself because the number of implementations wanting to use UDP will drop. Also, people should keep in mind that there are a panoply of access network types out there. Some of them behave better with UDP than they do with TCP because of the way the access network itself operates. If you are thinking only in a CAT-5/6 world, there are other issues out there that people may be up against that pushes them to use UDP. If I have an access network that favors UDP in performance, and I know there are no NATs between the client and the outbound proxy that have fragmentation issues, it doesn't make sense to use TCP. Regards, Brian > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Sunday, December 24, 2006 5:54 PM > To: Cullen Jennings > Cc: SIP; Audet, Francois (SC100:3055) > Subject: Re: [Sip] Question about Poll: Proposal relating to=20 > keepalive, TCP, and UDP usage in draft-ietf-sip-outbound >=20 > Cullen Jennings wrote: >=20 > > Hmm - I wish we had better specifics here - I will point out there =20 > > are millions of endpoints on well known residential endpoints that =20 > > are working through NATs and connected to PSTN gw and softwswiches =20 > > that are working over UDP. > ... > > Could you point me at a non enterprise deployment that is not in =20 > > point 2? I suspect there are some but the bulk seem to be form 2. >=20 > The problem is that none of those deployments are (yet) using=20 > the boatload of features like identity, e2m, complex=20 > route-header cookies, and other Very Important Stuff that we=20 > think might be likely to happen.=20 > But when that stuff starts to happen, UDP fragmentation will=20 > start to occur. We don't yet know how much will break as a=20 > result. But my guess is "a lot". >=20 > How about we rip out UDP, fix the Outbound stuff, fix the=20 > route-construction stuff, fix the early-media stuff. and call=20 > it SIP 3.0? >=20 > -- > Dean >=20 >=20 > --=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 03 13:49:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2BAt-0003l8-O9; Wed, 03 Jan 2007 13:49:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2BAs-0003kL-Rs for sip@ietf.org; Wed, 03 Jan 2007 13:49:19 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2BAr-00014Y-Cu for sip@ietf.org; Wed, 03 Jan 2007 13:49:18 -0500 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 96C17AC2BC; Wed, 3 Jan 2007 20:49:12 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17819.64168.559864.751052@harjus.tutpro.com> Date: Wed, 3 Jan 2007 20:49:12 +0200 To: "Brian Stucker" Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711213EA6F@zrc2hxm2.corp.nortel.com> References: <458F1308.2070601@softarmor.com> <6FC4416DDE56C44DA0AEE67BC7CA43711213EA6F@zrc2hxm2.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Cullen Jennings , SIP , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian Stucker writes: > IMHO-- we should be flexible in this regard. Make sure that the UDP > behavior is at least minimally specified in the standard (warts and all) > and then work outside of standards with customers so that they fully > appreciate (and properly value) what they're getting with TCP that > they're not getting with UDP. At that point I think the whole debate > will resolve itself because the number of implementations wanting to use > UDP will drop. i would think that the drop will be faster if there is no support for UDP in outbound. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From AlbaSalma@ROVITA.COM.PL Wed Jan 03 14:44:03 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2C1r-00008x-Kb for sip-archive@lists.ietf.org; Wed, 03 Jan 2007 14:44:03 -0500 Received: from kons-590e87c0.pool.einsundeins.de ([89.14.135.192]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2C1n-0001qe-M0 for sip-archive@lists.ietf.org; Wed, 03 Jan 2007 14:44:01 -0500 Received: from oem-7x8qbcvi58j ([108.142.142.58]) by kons-590e87c0.pool.einsundeins.de (8.13.4/8.13.4) with SMTP id E76BC1FFEDEEF5; Wed, 3 Jan 2007 20:44:16 +0100 Message-ID: <000a01c72f6f$80cd9320$c0870e59@oem7x8qbcvi58j> From: "in Maui" To: sip-archive@lists.ietf.org Subject: high resolution raquo Date: Wed, 3 Jan 2007 20:43:55 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C72F77.E291FB20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.3 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 ------=_NextPart_000_0006_01C72F77.E291FB20 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C72F77.E291FB20" ------=_NextPart_001_0007_01C72F77.E291FB20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mendesevan, rachel lillyfaith hillfamke. Forum, blog upload, contact, help, charts current chart todays. Mortons = grabbing breasts amp harry. You get email, fde next nude. Alticesung, hi leetara connertera klerktyra! Allenkylie popeleeann gloverlucy cornalujan millermay, marshmilla = simsmonica! Linked or, interwiki contained. Lillyfaith hillfamke uniongail portergeri. Mortons grabbing breasts amp = harry, morton. Neziocarre otiscassie lanecat nealechina chowchloe. Hotness added october september august july june may. Linked, or, interwiki contained! Adamsamy leeamy nuttallamy corrangel, jolieanna farisanna. Ripakiele, = belllaura grahamleah bibblil kimlinda. Overall babe of day, browse = celebs. Howardbusy mosscate zeta lovedani behrdannii aokidiane lanediane = nealdina meyerdita. Maranjules asnerkaren, elsonkaren lawlerkate. Kbx, = kb hotness, added october september august july. Website you get email, fde next? Rosekeegan, connor tracykeira, brookkelly hukelly ripakiele belllaura. Lanediane nealdina meyerdita von, jacobidrew du toitemilie de = ravinemily. Was, invalid empty, an linked. Gleavelisa kudrowliv silvaslucy = gracemandy crossmaria. Asnerkaren elsonkaren lawlerkate mosskatie price = humekrista allenkylie popeleeann? Dallas howardbusy mosscate zeta lovedani behrdannii aokidiane lanediane. Help charts current chart todays overall babe of? Leigh, cookrachel weiszradha, russorenee. Stonejulia moorejulie benzkate hudsonkate meluakaty rosekeegan connor = tracykeira! ------=_NextPart_001_0007_01C72F77.E291FB20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Mendesevan, rachel lillyfaith = hillfamke.
Forum, blog upload, contact, help, = charts current=20 chart todays. Mortons grabbing breasts amp harry.
You get email, fde next = nude.
Alticesung, hi leetara connertera = klerktyra!
Allenkylie popeleeann gloverlucy = cornalujan=20 millermay, marshmilla simsmonica!
Linked or, interwiki = contained.
Lillyfaith hillfamke uniongail = portergeri. Mortons=20 grabbing breasts amp harry, morton. Neziocarre otiscassie lanecat = nealechina chowchloe.
Hotness added october september august = july june may.
Linked, or, interwiki = contained!
Adamsamy leeamy nuttallamy corrangel, = jolieanna=20 farisanna. Ripakiele, belllaura grahamleah bibblil kimlinda. Overall = babe of=20 day, browse celebs. Howardbusy mosscate zeta lovedani behrdannii = aokidiane=20 lanediane nealdina meyerdita. Maranjules asnerkaren, elsonkaren = lawlerkate. Kbx,=20 kb hotness, added october september august july.
Website you get email, fde = next?
Rosekeegan, connor tracykeira, = brookkelly hukelly=20 ripakiele belllaura.
Lanediane nealdina meyerdita von, = jacobidrew du=20 toitemilie de ravinemily.
Was, invalid empty, an linked. = Gleavelisa kudrowliv=20 silvaslucy gracemandy crossmaria. Asnerkaren elsonkaren lawlerkate = mosskatie=20 price humekrista allenkylie popeleeann?
Dallas howardbusy mosscate zeta = lovedani behrdannii=20 aokidiane lanediane.
Help charts current chart todays = overall babe of?
Leigh, cookrachel weiszradha, = russorenee.
Stonejulia moorejulie benzkate = hudsonkate meluakaty=20 rosekeegan connor tracykeira!
------=_NextPart_001_0007_01C72F77.E291FB20-- ------=_NextPart_000_0006_01C72F77.E291FB20 Content-Type: image/gif; name="to navigation.gif" Content-Transfer-Encoding: base64 Content-ID: <000501c72f6f$80cd9320$c0870e59@oem7x8qbcvi58j> R0lGODlh4AFgAIfoAAMAAIoLCQB/AIJ+AAAAi4AAhgeMgrTLyb7Uu6jD+TMuDWwtCoIUDKkeBcAU DOolBQAzCCdKADtBB2BLAYhLBKJDArxKAO1AAABnBhhbAElWBWVkCIhWAJJWDLxoDutlCgCACBSG BkaNBGiNAHSOC5l4ALOHCu6KBgCeCBKfADWTCG6iAIGkAK6iAMGmAOWoDQDHBye8CEzOAGXBDnzD AJnEALnBAOTJBwDYAireAEfkAFzhAIjlDKLTAsTUANHVAAMNQBYAPkcFRlgBS4EIO6QAQrsAOuAO OQAnRisrQjgnTFURMnofOZwUO8UtMtMfRwBMNCw2Sk0xPldNQYlLM5ZMO789M9FBRABUQxNqOjtd R1NsTIRUB6lhQbRcTeNZTACMSSp+Mzx7RmOHNXmCP6iGRcx6St6ATQSrQB2iSEiVRVisPHydQqGb PsusNtqpRAC9OSLLRTLHO2m1RH/HS6a4Sci8RuHFOwznPxTpNUDaQm3bQYniPqbSPr7tS+7XMwAA gCMAiTMAi1UEeIoAdKwAjr4AhOAIfwgdgBMfe0YbilsZeoAYjpseiM0pftUfcgc4cio7hkxJeWwx hn1LhJhMeLlOfuY9ggBbgxZZjklUdF5liIpUgaNSgrVbee5kdwB3iiODiDmBfW57gHx4g653e82G cd93jgCjiB+VdkOXhWicgYOqeJWkfMKSeO2mewrFgBvEejq0hGa4fX++ia7Efbu/jtLMfQDodyXs ezvcdVnWjIHqjprtdcHaeOvqiAAFuiIAt0EAvmsGvokNzK4AzMcNvdUAswAhtxsqy0Qiy1Qru4oT vKMSzrcSyOEbxQA7tR4xzjMyyVg8wHY1vJFEushGt9I9uw5ovBhVt0djyF5cx4trzq1TzsdkwOJm uAmKyCyFukB2s2F9wYh4w6SBs8CCxdiCxQCSwiKjvT+Ww1mnxoKpuquntLagytmntgCyxhTMtDS6 tVjHzYa0zJvAuf/v5pmanXaHcv4AAAD4Bfb1CgAA//EI/wb5/vz//yH5BAD//60ALAAAAADgAWAA Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXOnQnsuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUGGynEq1qtWrC6Nq3co1J9avYMOK HUu2rNmzaNOqXcu2rdu3cOPKbdi1rt27ePPq3cu3b9G5gAMLHky4sOHDHv0qXswYL+LHkCNLltu4 suW9kzNrNni5s+fPoEOLHk26tOnTqFNb3sxatevXsGuyng03tu3buHP/pM27t+/fgHULH068eF/g yJMrX868ufPnCY1Ln64YunWL1LObrgoAQERgwJJr/x9Pvnj3nufLI4Xbvf3A9u7fexfYXSCB+wSu R0YPHwDR9DsBqN54AKZXoH8uGYhgggsOOB5E9cm3UH//xFchhfJZeCFBEeoXWIcFgRhhfSBuyJCD DgoIk4IvtWePiwoiyCKDLTaoIoq53UhjjfRp2KOHkPGk44syLjjjjETumKSSOEo3pIAxzjRkk8NF 1N98PYo434hbYsmlhD8CaRiXX4IJn0ElHkTlbRZ1eKaZXYZpopteYinmYFrKOad3JaZ5Z2BCHQhl kTseqKShNa4pHKKILpmenn/OlieYcIZ5JYdv6ulnpGnVCB+DnyZaqIuKKnplTAEEUOqqrLa63kab cv8q66y0UlrrrbhymmquvPYapKvABitsV74WC9awyCYrnbHPKUsas9BGK+200PKEw7XY3oQBBs4y lRYKKIAlgABAxnoWTzDA8FK63foVFgQQGDTuvArNOy5B2+YL0b1lXXsQvA5t6xC88QoEMEH8toWu ui6xa0+6EL+07Uv2CuDplIoiRjDBAiWccEHpDhSyiSRPaCdHB1e0McgQN9TyQODGTFDINMNwkD76 QJbywT6ODC6adc5sM7VY2VuQx+QyxC+dAxf8z85OT/QxxCM7hPNBPy+E89UC+ds1DjCH+3PWBZF9 WL76CmS22uGWLOekRFtltNAiM3yTw+NSbDFO8ML/5PDDDGObLU5Uq3vtS4frNLFMGCc5ZOKOkzrT 4qFBBAccB6U5cpoVfxw3WBwjnPQ/nhe0skBQQDFQ6g2BePlAr18YJ0MpI/1QyqIrNHLVBYEBBqbu +Uj66IYBAcRBpfsukPIFGf95Wpky/4/0CnXYeet2Ss+88wJxv5D2vy8ffkPeE0S9QcanX77v5w+k /j/lTz9+8ccbdJ9B4HVfP0H325ff82JxHve8Fz+E9C9EJzPg//w3kP4RcH/Vw9IBD8gQP1HwH/kD GkLSJMDjxe+CaOEJeGZyH8YtiB8oROFLwMPCmDSuXZYxnj1kuKQajtAlJcQhAUyokxvqUIc7nCEQ /15Cw5sAyIc+xEkSiThEmBRxRQ2CokxKSMUgvkSFMKxhFj+jvif2R4oXaxB+rJiTEjZwjP/LIAbD wxAKYoghXdzfpUzmvv3F74EQdFuntsjHF2rlhXHcSfoY80Wf+JGPiFQMFvnSuCWW55CJjOSaMJbD AVVSkpjsYxQz+RQAevKTa+GkKF8CylKa8iKjbNcpU5LKVpYGkq6kySpnmZArJXCDt2yTLUtiLpP0 0jqxxA0sRaWUYQ7FmMXcJJMqQ0vxBEiZNDkVqBgFTSltspBEkpw0sykoZBplm6HCTTN5M0dc2qpS eqxlLi0FtzKRrE/r9EimEIiRYNozKQ1ogEsUwP9PfrokVS8BqEwEyk2e+LMmAj1oQFX1T4YSlKAK 3acCthJOVDFUL+Nk1q4Qws+BdFQg+QipSDMUT4MsYAEGSZVKAyCQfNIzTCeN6UkHstGp9BMhNc2o Tv8RFILK5AEPeAlQXeIAB7ykqEctqlGfadGFSrSpDSXqUgd6Ubz0c6IxQapOdsrVfxR1IF9FyEz/ EVN22umjDwlpQcZa1n+gFaT5gGtc/1HTmrq0Ki6960CA2tW+NgSogF2IUpUK1sE6gCBhfchYCQLY wP6DrwUR6UgF0tgHFISwkCLJVxMrkJwa5p7FAYtnUfLLg0C2JDJdrFcN60nQxkard4noZbzp2tqD jqZvXaGAbnUbGtzaVjZ+DW5tfuss4Rr3uAMh7miQCyTlOve5dWHur6BL3epa97rYxYl0t8vd7nr3 u+AtTHbHS96dhPe8rS2vetfL3lailyLtJeV750vf+tr3vvhdSXz3y9/+6ia/AL6KfwdM4AIb+MAI TrCCF6yUADuYUwx20IMvEhAAOw== ------=_NextPart_000_0006_01C72F77.E291FB20-- From sip-bounces@ietf.org Wed Jan 03 15:51:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2D3w-0003Vp-5o; Wed, 03 Jan 2007 15:50:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2D3j-0003PW-M6; Wed, 03 Jan 2007 15:50:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2D3j-00053h-Bf; Wed, 03 Jan 2007 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 0B92F26ECF; Wed, 3 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H2D3i-0001n4-86; Wed, 03 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 03 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-ice-option-tag-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-ice-option-tag-00.txt Pages : 9 Date : 2007-1-3 This specification defines a media feature tag and an option tag for use with the Session Initiation Protocol (SIP). The media feature tag allows a UA to communicate to its registrar that it supports ICE. The option tag allows a User Agent (UA) to require support for ICE in order for a call to proceed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-ice-option-tag-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-ice-option-tag-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-ice-option-tag-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-3144440.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-ice-option-tag-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-ice-option-tag-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-3144440.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Wed Jan 03 16:07:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2DKD-0001Ks-GL; Wed, 03 Jan 2007 16:07:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2DKC-0001Kf-6n for sip@ietf.org; Wed, 03 Jan 2007 16:07:04 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2DKA-00088R-8X for sip@ietf.org; Wed, 03 Jan 2007 16:07:04 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l03KxS117344; Wed, 3 Jan 2007 15:59:28 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Wed, 3 Jan 2007 15:06:56 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711213ED0D@zrc2hxm2.corp.nortel.com> In-Reply-To: <17819.64168.559864.751052@harjus.tutpro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Thread-Index: AccvZ+HyYTIkZh/fQS2lFxCda7AafAAEiwYQ From: "Brian Stucker" To: "Juha Heinanen" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Cullen Jennings , SIP , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org As I said, there are networks where TCP is less efficient than UDP and there are no NAT complications to be concerned about. I don't think outbound is so fundamental to the operation of SIP as to force people to change out their transport protocol to get the benefits. There are other ways that people have been solving this problem without the benefit of a standard. I doubt that dropping support for UDP is likely to get them to move away from these mechanisms faster than if they had support for outbound with UDP. Regards, Brian > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com]=20 > Sent: Wednesday, January 03, 2007 12:49 PM > To: Stucker, Brian (RICH1:AR00) > Cc: Dean Willis; Cullen Jennings; SIP; Audet, Francois (SC100:3055) > Subject: RE: [Sip] Question about Poll: Proposal relating to=20 > keepalive, TCP, and UDP usage in draft-ietf-sip-outbound >=20 > Brian Stucker writes: >=20 > > IMHO-- we should be flexible in this regard. Make sure=20 > that the UDP > behavior is at least minimally specified in=20 > the standard (warts and all) > and then work outside of=20 > standards with customers so that they fully > appreciate=20 > (and properly value) what they're getting with TCP that >=20 > they're not getting with UDP. At that point I think the whole=20 > debate > will resolve itself because the number of=20 > implementations wanting to use > UDP will drop. >=20 > i would think that the drop will be faster if there is no=20 > support for UDP in outbound. >=20 > -- juha >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 04 00:27:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2L8B-0005UN-LK; Thu, 04 Jan 2007 00:27:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2L89-0005U2-Tz for sip@ietf.org; Thu, 04 Jan 2007 00:27:09 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2L88-0002QX-8P for sip@ietf.org; Thu, 04 Jan 2007 00:27:09 -0500 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 2F42AAC27A; Thu, 4 Jan 2007 07:27:07 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17820.36907.61383.47337@harjus.tutpro.com> Date: Thu, 4 Jan 2007 07:27:07 +0200 To: "Brian Stucker" Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711213ED0D@zrc2hxm2.corp.nortel.com> References: <17819.64168.559864.751052@harjus.tutpro.com> <6FC4416DDE56C44DA0AEE67BC7CA43711213ED0D@zrc2hxm2.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Cullen Jennings , SIP , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian Stucker writes: > I don't think outbound is so fundamental to the operation of SIP as to > force people to change out their transport protocol to get the > benefits. i fully agree. outbound doesn't give anything over what we have today. > There are other ways that people have been solving this problem without > the benefit of a standard. I doubt that dropping support for UDP is > likely to get them to move away from these mechanisms faster than if > they had support for outbound with UDP. the reason to drop outbound support from udp is there are problems with outbound and udp as has been described on this list. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 04 04:53:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2PGN-0001ah-Ti; Thu, 04 Jan 2007 04:51:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2PGM-0001aZ-7n for sip@ietf.org; Thu, 04 Jan 2007 04:51:54 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2PGI-0005ar-NF for sip@ietf.org; Thu, 04 Jan 2007 04:51:54 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l049oeok024257; Thu, 4 Jan 2007 11:50:42 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 11:51:31 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 11:51:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Thu, 4 Jan 2007 11:51:31 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F032CEF61@esebe103.NOE.Nokia.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711213EA4B@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Thread-Index: AccsdT4QU8BeWkSzROe/cOROp04J5wByuXCAAEk9TLAAG9PQkA== From: To: , X-OriginalArrivalTime: 04 Jan 2007 09:51:31.0584 (UTC) FILETIME=[E98F3000:01C72FE5] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sip@ietf.org, audet@nortel.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sorry, I was not clear enough for my formulation. The scope of my summary was the usage of SIP together with Outbound, thus I simply meant this: >May support UDP for Outbound as a rewording of the original proposal: > Proposal 2: Make outbound registrations over UDP flows optional for > UAs. Regards, Erkki >> -----Original Message----- >> From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com]=20 >> Sent: Tuesday, January 02, 2007 1:41 AM > ><>=20 > >> As a summary what that would mean in terms of deployments: >>=20 >> - Every Outbound compliant (UA or proxy) implementation MUST >> support TCP but MAY support UDP too. > >May support UDP for Outbound, or may support UDP, period? Unless I'm >missing something somewhere, section 18 of RFC-3261 still says that all >SIP elements MUST implement UDP. > >>=20 >> - It will be up to the deployment to select whether TCP or UDP >> (or even both) shall be used for that specific deployment. >> Supporting UDP only would have known limitations and it would >> also mean that TCP-only implementations could not be used for >> that deployment. >>=20 >> Erkki=20 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 04 05:04:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2PSF-0007Pn-CB; Thu, 04 Jan 2007 05:04:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2PSE-0007Pi-M3 for sip@ietf.org; Thu, 04 Jan 2007 05:04:10 -0500 Received: from mail.tataelxsi.co.in ([203.200.1.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2PSD-0007fw-6n for sip@ietf.org; Thu, 04 Jan 2007 05:04:10 -0500 Received: from rathod ([10.50.42.1]) by mail.tataelxsi.co.in (MOS 3.8.3-GA) with ESMTP id CEF40545 (AUTH rathod) for ; Thu, 4 Jan 2007 15:34:03 +0530 (IST) From: Rathod Subhashchandra To: Date: Thu, 4 Jan 2007 15:35:09 +0530 Message-ID: <012e01c72fe7$d1f28030$012a320a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F032CEF61@esebe103.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: High X-Junkmail-Status: score=10/50, host=mail.tataelxsi.co.in X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090206.459CCF66.00CC,ss=1,fgs=0, ip=10.50.42.1, so=2006-12-09 10:45:40, dmn=5.2.125/2006-10-10 X-Spam-Score: 0.4 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Sip] tool for automating soft phone key pad clicking X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rathod Subhashchandra List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi All, I am looking for a tool which shall help in automating third party software(SIP Stack phone) like automating of buttons click on the soft phones. It would be a great help if someone provides relevant details. Thanks ! Rathod. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 04 05:11:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2PYo-0005H6-JE; Thu, 04 Jan 2007 05:10:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2PYm-0005H1-I8 for sip@ietf.org; Thu, 04 Jan 2007 05:10:57 -0500 Received: from math.teaser.net ([213.91.2.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2PYj-0000rd-7w for sip@ietf.org; Thu, 04 Jan 2007 05:10:56 -0500 Received: from [192.168.4.61] (251.9.39-62.rev.gaoland.net [62.39.9.251]) by math.teaser.net (Postfix) with ESMTP id 180836C94D; Thu, 4 Jan 2007 11:10:52 +0100 (CET) Message-ID: <459CD2D3.3010209@wengo.fr> Date: Thu, 04 Jan 2007 11:11:31 +0100 From: Sebastien Tricaud User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: Rathod Subhashchandra Subject: Re: [Sip] tool for automating soft phone key pad clicking References: <012e01c72fe7$d1f28030$012a320a@telxsi.com> In-Reply-To: <012e01c72fe7$d1f28030$012a320a@telxsi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hello, For buttons clicks, I guess you can get sounds produced by softphones and script a player to it :-) Or, you can use miniua for sip calls scripting. Its documentation is available there -> http://dev.openwengo.com/trac/openwengo/trac.cgi/wiki/MiniUa In the hope that help you, Sebastien. Rathod Subhashchandra wrote: > Hi All, > > I am looking for a tool which shall help in automating third party > software(SIP Stack phone) like automating of buttons click on the soft > phones. It would be a great help if someone provides relevant details. > > Thanks ! > Rathod. > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 04 07:10:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2RP7-0006IN-Sz; Thu, 04 Jan 2007 07:09:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2RP6-0006Fd-2q for sip@ietf.org; Thu, 04 Jan 2007 07:09:04 -0500 Received: from mail.tataelxsi.co.in ([203.200.1.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2RP1-00075l-HG for sip@ietf.org; Thu, 04 Jan 2007 07:09:04 -0500 Received: from rathod ([10.50.42.1]) by mail.tataelxsi.co.in (MOS 3.8.3-GA) with ESMTP id CEF57731 (AUTH rathod); Thu, 4 Jan 2007 17:38:33 +0530 (IST) From: Rathod Subhashchandra To: "'Sebastien Tricaud'" Subject: RE: [Sip] tool for automating soft phone key pad clicking Date: Thu, 4 Jan 2007 17:39:31 +0530 Message-ID: <014101c72ff9$31ae7ef0$012a320a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <459CD2D3.3010209@wengo.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: High X-Junkmail-Status: score=10/50, host=mail.tataelxsi.co.in X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090201.459CECA3.005E,ss=1,fgs=0, ip=10.50.42.1, so=2006-12-09 10:45:40, dmn=5.2.125/2006-10-10 X-Spam-Score: 0.4 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rathod Subhashchandra List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Sebastien, I went through this. Looks very complicated. I am looking a tool like WinRunner. Can you help me in this? Thanks ! Rathod. -----Original Message----- From: Sebastien Tricaud [mailto:sebastien.tricaud@wengo.fr] Sent: Thursday, January 04, 2007 3:42 PM To: Rathod Subhashchandra Cc: sip@ietf.org Subject: Re: [Sip] tool for automating soft phone key pad clicking Hello, For buttons clicks, I guess you can get sounds produced by softphones and script a player to it :-) Or, you can use miniua for sip calls scripting. Its documentation is available there -> http://dev.openwengo.com/trac/openwengo/trac.cgi/wiki/MiniUa In the hope that help you, Sebastien. Rathod Subhashchandra wrote: > Hi All, > > I am looking for a tool which shall help in automating third party > software(SIP Stack phone) like automating of buttons click on the soft > phones. It would be a great help if someone provides relevant details. > > Thanks ! > Rathod. > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 04 08:31:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2SgE-0004rY-Hv; Thu, 04 Jan 2007 08:30:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2SgD-0004rP-2V for sip@ietf.org; Thu, 04 Jan 2007 08:30:49 -0500 Received: from mailx.8x8.com ([192.84.19.237] helo=mailint.8x8.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Sg8-00047E-My for sip@ietf.org; Thu, 04 Jan 2007 08:30:49 -0500 Received: from mailint.8x8.com (localhost.localdomain [127.0.0.1]) by mailint.8x8.com (8.13.1/8.13.1) with ESMTP id l04DUihC031163 for ; Thu, 4 Jan 2007 05:30:44 -0800 Received: from mailint.8x8.com (root@localhost) by mailint.8x8.com (8.13.1/8.13.1/Submit) with ESMTP id l04DUiFY031161 for ; Thu, 4 Jan 2007 05:30:44 -0800 Received: from [10.0.2.15] (godzilla.8x8.com 192.168.84.42) by mailint.8x8.com (Scalix SMTP Relay 10.0.1.3) via ESMTP; Thu, 04 Jan 2007 05:30:44 -0800 (PST) Date: Thu, 4 Jan 2007 14:30:41 +0100 From: Marc Petit-Huguenin To: sip@ietf.org Message-ID: <459D0181.6050601@acm.org> x-scalix-Hops: 1 User-Agent: Icedove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Disposition: inline X-Spam-Score: 1.1 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I just submitted a new version of my proposal to support hybrid TCP-UDP transport in Outbound. Until it appears in the archives, a copy can be found here: http://marc.petit-huguenin.org/draft-petithuguenin-sip-outbound-fragmentation-01.txt This is a nearly complete rewrite. Please read at least the Introduction and the Overview of Operation sections and you will see that this proposal does not add a lot of complexity to Outbound. Comments and questions are welcome. Thanks. -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [ RFC1855-compliant space for rent] Work: marc@8x8.com [ ] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 04 11:08:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2V7D-00062U-Nw; Thu, 04 Jan 2007 11:06:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2V7D-0005zn-28 for sip@ietf.org; Thu, 04 Jan 2007 11:06:51 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2V7B-0006Bx-NP for sip@ietf.org; Thu, 04 Jan 2007 11:06:51 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l04FxB229682; Thu, 4 Jan 2007 10:59:11 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Thu, 4 Jan 2007 10:06:39 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371121AF516@zrc2hxm2.corp.nortel.com> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F032CEF61@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Thread-Index: AccsdT4QU8BeWkSzROe/cOROp04J5wByuXCAAEk9TLAAG9PQkAAReElQ From: "Brian Stucker" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: sip@ietf.org, Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I agree. > -----Original Message----- > From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com]=20 > Sent: Thursday, January 04, 2007 3:52 AM > To: Stucker, Brian (RICH1:AR00); fluffy@cisco.com > Cc: sip@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: [Sip] Question about Poll: Proposal relating to=20 > keepalive, TCP, and UDP usage in draft-ietf-sip-outbound >=20 > Sorry, I was not clear enough for my formulation. > The scope of my summary was the usage of SIP together with=20 > Outbound, thus I simply meant this: >=20 > >May support UDP for Outbound >=20 > as a rewording of the original proposal: >=20 > > Proposal 2: Make outbound registrations over UDP flows optional for=20 > > UAs. >=20 > Regards, >=20 > Erkki >=20 > >> -----Original Message----- > >> From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com] > >> Sent: Tuesday, January 02, 2007 1:41 AM > > > ><> > > > >> As a summary what that would mean in terms of deployments: > >>=20 > >> - Every Outbound compliant (UA or proxy) implementation MUST > >> support TCP but MAY support UDP too. > > > >May support UDP for Outbound, or may support UDP, period? Unless I'm=20 > >missing something somewhere, section 18 of RFC-3261 still=20 > says that all=20 > >SIP elements MUST implement UDP. > > > >>=20 > >> - It will be up to the deployment to select whether TCP or UDP > >> (or even both) shall be used for that specific deployment. > >> Supporting UDP only would have known limitations and it would > >> also mean that TCP-only implementations could not be used for > >> that deployment. > >>=20 > >> Erkki > > >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 04 11:42:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Vf1-0007DL-Sn; Thu, 04 Jan 2007 11:41:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Vez-0007DD-IH for sip@ietf.org; Thu, 04 Jan 2007 11:41:45 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Vex-000810-Np for sip@ietf.org; Thu, 04 Jan 2007 11:41:45 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l04GfaS1000749 for ; Thu, 4 Jan 2007 10:41:39 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 10:41:22 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 17:41:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7301F.29D30B80" Subject: FW: [Sip] I-D ACTION:draft-ietf-sip-ice-option-tag-00.txt Date: Thu, 4 Jan 2007 17:41:20 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180A39D21@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-ice-option-tag-00.txt thread-index: AccveR10Ulek2QxiT2+1OKJnn+7IZQApQhKQ From: "Drage, Keith \(Keith\)" To: "SIP WG" X-OriginalArrivalTime: 04 Jan 2007 16:41:20.0858 (UTC) FILETIME=[29E8A3A0:01C7301F] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C7301F.29D30B80 Content-Type: text/plain; name="warning1.txt" Content-Disposition: inline; filename="warning1.txt" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: MIME-tools 5.420 (Entity 5.420) WARNING: This e-mail has been altered by some SMTP protection software. Following this paragraph are indications of the actual changes made. For more information, contact . An attachment named draft-ietf-sip-ice-option-tag-00.URL was removed from this document as it constituted a security hazard. If you require this document, please contact the sender and arrange an alternate means of receiving it. ------_=_NextPart_001_01C7301F.29D30B80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline (As WG chair) Please be aware of the following draft submission. While this is a new document in the SIP WG, the intention is that it should enter WGLC at the same time as the main ice draft in the MMUSIC WG has it's revised WGLC. This is believed to be imminent.=20 Now would therefore be a suitable time to review the document and identify any major issues with the direction that it takes, and identify any omissions that were expected to be covered by this draft, rather than leaving such for the WGLC. Send comments to the author and to the SIP WG list. Regards Keith=20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: 03 January 2007 20:50 To: i-d-announce@ietf.org Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-ice-option-tag-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-ice-option-tag-00.txt Pages : 9 Date : 2007-1-3 =09 This specification defines a media feature tag and an option tag for use with the Session Initiation Protocol (SIP). The media feature tag allows a UA to communicate to its registrar that it supports ICE. The option tag allows a User Agent (UA) to require support for ICE in order for a call to proceed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-ice-option-tag-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-ice-option-tag-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-ice-option-tag-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C7301F.29D30B80 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C7301F.29D30B80-- From sip-bounces@ietf.org Thu Jan 04 14:52:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Ybn-0000Z6-NZ; Thu, 04 Jan 2007 14:50:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Ybl-0000YZ-T0 for sip@ietf.org; Thu, 04 Jan 2007 14:50:38 -0500 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Ybk-0008Ft-1M for sip@ietf.org; Thu, 04 Jan 2007 14:50:37 -0500 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1H2Ybh-00086x-4S; Thu, 04 Jan 2007 14:50:33 -0500 Message-ID: <459D5A88.4070809@bbn.com> Date: Thu, 04 Jan 2007 14:50:32 -0500 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" References: <4.3.2.7.2.20070102163723.03594f08@email.cisco.com> In-Reply-To: <4.3.2.7.2.20070102163723.03594f08@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: SIP WG Subject: [Sip] Comments on Location Conveyance -06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org James, Here are some comments on the latest conveyance draft. I generally like the document, so it's mostly small stuff, but hopefully helpful, nonetheless. First, you refer Section 1: Introduction ---------------------------- I have trouble understanding the last sentance of the first paragraph. Consider condensing the sentence. For example, "We use the term "conveyance" to distinguish this work from other cirmustances in which location is used, such as location sighting or location configuration." The above sentance might be too vague, another possibility: "We use the term "conveyance" to distinguish this work from other circumstance in which location is used, such as the initial generation of location information or the acquisition of location information by the SIP entity." Section 3.3: 424 Response Code --------------------------------------- The final sentance of the final paragraph reads: "An initial set of location error codes are in [ID-ERROR]" I don't know if a concesus was reached regarding the future of the ID-ERROR (Geopriv error code registry draft). However, it seems that either: - The reference to ID-ERROR should be removed because the ID-ERROR draft is not moving forward, or else - Additional text should be added to clarify the relationship between the error code registry draft and the new warning codes provided in Section 3.4 Section 3.4: New Warning Codes for Location Error Granularity ----------------------------------------------------------------------------- The final sentance of paragraph 2 should read: "This can be useful for troubleshooting." (added the word 'be') Section 3.4.1 ---------------- The third sentance reads: "... only understood location in RFC4119 PIDF-LO format (civic or geo)." In this context it may be unclear to the reader what you mean by "geo". I'm not sure what you should call the format that's not civic, but it's important to be consistant (and as clear as possible). In this document, you refer to "geo" in 3.4.1, "Geo-location Format" in 3.4.2, and "Coordinate Format" in 4.1 Also, RFC 4119 refers to this format as GML 3.0, and the LoST drafts refer to this format as "Geodetic Coordinate". So basically, I don't know how you should refer to this format, but using "geo" as short hand without defining it, may cause confusion. (Also, consider adding a space between RFC and 4119.) Next, in the 5th (second to last) sentence of the first paragraph, the 'SHOULD' is capitalized, but in the last sentence the 'should' is not capitalized. My inclination is that since these are just examples, the 'should' should not be capitalized in either case. However, if you want the text to be normative, you should captialize both occurances of 'should' Section 3.4.3 ---------------- In the second paragraph, the word 'Warning' probably does not need to be capitolized. Section 3.4.4 ---------------- The first sentance is missing a comma and should read: "... means the location provided, whether by-value or by-reference, in a request is not well formed." Section 3.4.5 ---------------- I found the second paragraph to be unclear. Consider re-wording it as follows: "A typical reaction to receiving this warning code is for the location sender to verify that it has indeed included location information in the request and then to send the request again." Section 3.4.6 ---------------- In the second paragraph, consider changing 'error' to 'warning code' for consistancy. Section 3.4.7 ---------------- Consider re-wording the second paragraph as follows: "A typical reaction to receiving this warning code is for the location sender to convey more information, if doing so is allowed by local policy." Section 3.4.12 ----------------- In the second paragraph, consider changing 'error' to 'warning code' for consistancy. Section 3.6 -------------- In the last sentance of the first paragraph, consider adding a space between RFC and 3693. I had trouble understanding the first sentance of the second paragraph. Consider a re-wording such as: "... treating the URI as a presence URI and dereferencing it by sending a SUBSCRIBE request to a presence server as per [RFC3856]." In the last sentance of the third paragraph, add the word 'is' before the phrase 'the purpose of this extension' Section 5 ----------- In the fourth paragraph, add the word 'a' between 'for protecting' and 'PIDF' Consider rewording the first sentance of the last paragraph as follows: "... in the same SIP message, so long as each is in a separate message body part." Section 5.1 ------------- In the first sentance of the third paragraph, consider adding the phrase 'or wish to convey' between 'does not know' and 'its location at this time'. In sentance three of paragraph five, I find the phrase 'learn from the Warning code' to be unclear. Consider re-wording the sentance as follows: "Upon receiving an error response, the UAC SHOULD take appropriate steps based on the warning code before attempting to convey location again." I had trouble with the final paragraph of this section. I understand that if the UAC has a problem with location information sent by the UAS it doesn't have an oppertunity to send a warning code and should just ignore the information. However, you go on to say that "A subscription is a better means of getting a UAS's location". By 'a subscription' do you mean location-by-reference as opposed to location-by-value? Also, it's not clear why a subscription is a better way of obtaining the location of a UAS. Perhaps you could write a small amount of additional text clarifying this notion. Section 5.2 -------------- Consider re-wording the first sentance of the first paragraph as follows: "... is present, the type of URI contained in the header field will indicate if location ..." In the first sentance of the second paragraph, consider changing "or error the message" to "or else send an error response" Section 5.3 ------------- Consider re-wording the first sentance of the first paragraph as follows: "Proxies that perform location-based routing may need to consult external databases or systems to determine the route." Section 5.3.1 ---------------- In the first sentance of the first paragraph, consider adding the word 'geolocation' between 'any existing' and 'header'. The first paragraph indicates that any existing header parameter MUST NOT be modified or deleted by a proxy. However, the last paragraph describes a case where the proxy MUST remove the incoming "message-routed-on-this-uri". If "message-routed-on-this-uri" is a header parameter than this is a contradiction. (Alternatively, if this is not a contradiction, then it's unclear to me what a header parameter is). _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 04 17:43:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2bIK-0002I5-5q; Thu, 04 Jan 2007 17:42:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2bI4-0001iW-Br for sip@ietf.org; Thu, 04 Jan 2007 17:42:28 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2bGH-0004vC-K7 for sip@ietf.org; Thu, 04 Jan 2007 17:40:39 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 04 Jan 2007 14:40:37 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l04Meabg015097; Thu, 4 Jan 2007 14:40:36 -0800 Received: from [192.168.4.2] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l04MeLIm029112; Thu, 4 Jan 2007 14:40:21 -0800 (PST) In-Reply-To: <17819.64168.559864.751052@harjus.tutpro.com> References: <458F1308.2070601@softarmor.com> <6FC4416DDE56C44DA0AEE67BC7CA43711213EA6F@zrc2hxm2.corp.nortel.com> <17819.64168.559864.751052@harjus.tutpro.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5F813F72-62E8-48C2-9130-68B39F71CDBE@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Thu, 4 Jan 2007 14:40:13 -0800 To: Juha Heinanen X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1050; t=1167950436; x=1168814436; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20Question=20about=20Poll=3A=20Proposal=20relat ing=20to=20keepalive, =20TCP, =20and=20UDP=20usage=20in=20draft-ietf-sip-out bound |Sender:=20; bh=V2WrxitYU5LmORD9BCCR3NN0MO8XPLUmnlUuf615O8g=; b=Yeq9ulO/oCwuAVB92Z9JyFLjeqUdaasM+dBgxbsyAcK2O9tg3ZDEUl4vcPKAksNq6zjk/y57 Tip+vD07Tl2KsvfuzrofLRNDcuG2cI2TfgZkUS1qRnwXYE2x3vJQo6Jn; Authentication-Results: sj-dkim-6; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: SIP , Francois Audet , Dean Willis , Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jan 3, 2007, at 10:49 AM, Juha Heinanen wrote: > Brian Stucker writes: > >> IMHO-- we should be flexible in this regard. Make sure that the UDP >> behavior is at least minimally specified in the standard (warts >> and all) >> and then work outside of standards with customers so that they fully >> appreciate (and properly value) what they're getting with TCP that >> they're not getting with UDP. At that point I think the whole debate >> will resolve itself because the number of implementations wanting >> to use >> UDP will drop. > > i would think that the drop will be faster if there is no support for > UDP in outbound. > > -- juha I don't. The problem is not that UAs don't support TCP. The problems is that proxies don't support TCP on a large scale. Now we have had some posts that it is possible to build proxies with lots of TCP connections but if people want to encourage the move to TCP, I think the best thing they could do is help people understand how to build large scale TCP proxies. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 04 20:13:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2dci-0007pG-78; Thu, 04 Jan 2007 20:11:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2dcg-0007mh-64 for sip@ietf.org; Thu, 04 Jan 2007 20:11:54 -0500 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2dce-00069n-Rn for sip@ietf.org; Thu, 04 Jan 2007 20:11:54 -0500 Received: by ug-out-1314.google.com with SMTP id 72so5240873ugd for ; Thu, 04 Jan 2007 17:11:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fpaGjgZEp+iEod/57tqSJswDTqkmogNnR1xDnBo7h0ynhw2owYGZhaCJx4gkHqqaI93WYVlswIBJUtPu53/e14pqNr0T7gIzxKYeE6Au+HJKuuuVw9Fx1b/x3kZSxpIkNO1a4aEEPthOCRhFxl2P6FI7YqnYiPaKDS17VYPFF/M= Received: by 10.78.151.3 with SMTP id y3mr6570242hud.1167959511732; Thu, 04 Jan 2007 17:11:51 -0800 (PST) Received: by 10.78.151.2 with HTTP; Thu, 4 Jan 2007 17:11:51 -0800 (PST) Message-ID: <953beacc0701041711y61188681i67550e9f2f922f3b@mail.gmail.com> Date: Thu, 4 Jan 2007 17:11:51 -0800 From: "Rohan Mahy" To: "Cullen Jennings" Subject: Re: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound In-Reply-To: <91E4CFBC-9DA7-40F5-B757-62E0352708C4@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <91E4CFBC-9DA7-40F5-B757-62E0352708C4@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I don't see value in goal #3. I believe my proposal covers your goals #1 and #2 (with #2 corrected to talk about receiving large packets as corrected by Francois). Perhaps you are having an allergic reaction to some of the specific wording I proposed rather than the goal or effect of that text. If so, lets try to hammer out some mutually agreeable alternate text. thanks, -rohan On 12/30/06, Cullen Jennings wrote: > > If the people who have been expressing strong opinions on the details > of this proposal could comment on if they agree with these high level > goals or not, it would be really helpful for trying to get this draft > to move forward. > > On Dec 16, 2006, at 12:33 PM, Cullen Jennings wrote: > > > Practically speaking given where we are today, I would be a fan of > > a solution that meant the following goals: > > > > 1) allowed deployments that wanted to use TCP to use TCP > > > > 2) allowed deployments that wanted to use UDP to use only UDP with > > the known limitations that the UA would not be able to send large > > requests > > > > 3) allowed deployments that wanted to use both UDP and TCP to do so > > and not have the size limitations by using switchover > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 01:14:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2iKn-00018Q-PP; Fri, 05 Jan 2007 01:13:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2iKl-00016L-CV for sip@ietf.org; Fri, 05 Jan 2007 01:13:43 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2iKk-0002xx-2D for sip@ietf.org; Fri, 05 Jan 2007 01:13:43 -0500 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 6DBBEAC2C0; Fri, 5 Jan 2007 08:13:36 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17821.60560.400209.135681@harjus.tutpro.com> Date: Fri, 5 Jan 2007 08:13:36 +0200 To: Cullen Jennings Subject: Re: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound In-Reply-To: <5F813F72-62E8-48C2-9130-68B39F71CDBE@cisco.com> References: <458F1308.2070601@softarmor.com> <6FC4416DDE56C44DA0AEE67BC7CA43711213EA6F@zrc2hxm2.corp.nortel.com> <17819.64168.559864.751052@harjus.tutpro.com> <5F813F72-62E8-48C2-9130-68B39F71CDBE@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: SIP , Francois Audet , Dean Willis , Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen Jennings writes: > I don't. The problem is not that UAs don't support TCP. how can you from cisco say that the problem is not that UAs don't support TCP, when UAs from cisco and its affiliates don't support TCP? > The problems is that proxies don't support TCP on a large scale. which popular proxies don't support TCP in large scale? give me some names. if there are some, i'm sure their vendors must fix them, because otherwise they would be out of business. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 03:12:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2kAe-0007mz-Gt; Fri, 05 Jan 2007 03:11:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2kAd-0007mq-Jf for sip@ietf.org; Fri, 05 Jan 2007 03:11:23 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2kAX-0004wA-0I for sip@ietf.org; Fri, 05 Jan 2007 03:11:23 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 23F964F0045; Fri, 5 Jan 2007 09:11:08 +0100 (CET) Received: from eesmdmw020.eemea.ericsson.se ([159.107.3.34]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 09:11:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] tool for automating soft phone key pad clicking Date: Fri, 5 Jan 2007 09:11:06 +0100 Message-ID: In-Reply-To: <014101c72ff9$31ae7ef0$012a320a@telxsi.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] tool for automating soft phone key pad clicking Thread-Index: AccwoQyct14UQGdtQRyyzvU3WjmIqQ== From: "Jesus Javier Arauz \(MI/EEM\)" To: "Rathod Subhashchandra" , "Sebastien Tricaud" X-OriginalArrivalTime: 05 Jan 2007 08:11:07.0888 (UTC) FILETIME=[0D91DF00:01C730A1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, In a recent prototype I had to emulate processing of a 302 response by a SIP client by launching a script that actually dials the phone number received in the Contact header of the 302 on the client's UI. The reason was obviously that the client did not properly implement the re-dialling on reception of the 302. The tool I used is MacroExpress 3 and it worked pretty well. Hope it is helpful, /Javier Rathod Subhashchandra wrote: > Hi Sebastien, >=20 > I went through this. > Looks very complicated. I am looking a tool like WinRunner. Can you > help me in this?=20 >=20 > Thanks ! > Rathod. >=20 >=20 > -----Original Message----- > From: Sebastien Tricaud [mailto:sebastien.tricaud@wengo.fr] > Sent: Thursday, January 04, 2007 3:42 PM > To: Rathod Subhashchandra > Cc: sip@ietf.org > Subject: Re: [Sip] tool for automating soft phone key pad clicking >=20 >=20 > Hello, >=20 > For buttons clicks, I guess you can get sounds produced by softphones > and script a player to it :-)=20 >=20 > Or, you can use miniua for sip calls scripting. Its documentation is > available there -> > http://dev.openwengo.com/trac/openwengo/trac.cgi/wiki/MiniUa =20 >=20 >=20 > In the hope that help you, >=20 > Sebastien. >=20 >=20 >=20 >=20 >=20 > Rathod Subhashchandra wrote: >> Hi All, >>=20 >> I am looking for a tool which shall help in automating third party >> software(SIP Stack phone) like automating of buttons click on the >> soft phones. It would be a great help if someone provides relevant >> details.=20 >>=20 >> Thanks ! >> Rathod. >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip Use >> sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 03:39:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2kay-0006BT-91; Fri, 05 Jan 2007 03:38:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2kaw-0006BJ-0p for sip@ietf.org; Fri, 05 Jan 2007 03:38:34 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2kau-0003Im-Hn for sip@ietf.org; Fri, 05 Jan 2007 03:38:34 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l058bATQ010807; Fri, 5 Jan 2007 10:37:10 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 10:38:19 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 10:38:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Fri, 5 Jan 2007 10:38:18 +0200 Message-ID: In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711213ED0D@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Thread-Index: AccvZ+HyYTIkZh/fQS2lFxCda7AafAAEiwYQAEpKLmA= From: To: , X-OriginalArrivalTime: 05 Jan 2007 08:38:19.0030 (UTC) FILETIME=[D9CE6360:01C730A4] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: fluffy@cisco.com, sip@ietf.org, audet@nortel.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Brian, Brian Stucker wrote: >As I said, there are networks where TCP is less efficient than=20 >UDP and there are no NAT complications to be concerned about. > Can you elaborate what kind of networks these typically are? Do you mean that the networks are configured to prioritize UDP in some DiffServ'ish manner, or some more fundamental issues with retransmissions etc.=20 People often refer to TCP's inefficiency in the wireless access due to non-congestion related packet loss. This can be an issue when transfering large amounts of data. However, it is not relevant in case of SIP/TCP where relatively short messages are sent back and forth.=20 Markus _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 04:43:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2laU-0002pS-0I; Fri, 05 Jan 2007 04:42:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2laR-0002pI-RF for sip@ietf.org; Fri, 05 Jan 2007 04:42:07 -0500 Received: from mail.tataelxsi.co.in ([203.200.1.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H2laN-00088J-5H for sip@ietf.org; Fri, 05 Jan 2007 04:42:07 -0500 Received: from rathod ([10.50.42.1]) by mail.tataelxsi.co.in (MOS 3.8.3-GA) with ESMTP id CEG61047 (AUTH rathod); Fri, 5 Jan 2007 15:11:43 +0530 (IST) From: Rathod Subhashchandra To: "'Jesus Javier Arauz \(MI/EEM\)'" , "'Sebastien Tricaud'" Subject: RE: [Sip] tool for automating soft phone key pad clicking Date: Fri, 5 Jan 2007 15:12:44 +0530 Message-ID: <015f01c730ad$daa8cec0$012a320a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Junkmail-Status: score=10/50, host=mail.tataelxsi.co.in X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090205.459E1BA6.0026,ss=1,fgs=0, ip=10.50.42.1, so=2006-12-09 10:45:40, dmn=5.2.125/2006-10-10 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rathod Subhashchandra List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Javier, Thanks lot for this information. I have installed the Macro Express 3. Need to play with this tool to know how key strokes can be automated. My requirement is 1. I have developed the test automation tool for SIP protocol conformance. 2. Testing at present with SJPhone. SJPhone needs manual interaction for accepting/rejecting the call and also to place the MT(Mobile Terminating) to the Testing tool. 4. We have close to 300 test cases. Manually accepting/rejecting and placing call for these many test cases is becoming very difficult job. Hence, I wanted to automate the SJPhone for accepting/rejecting/call-placing. I can't write the stub as I don't have interface document. At present, I am not sure, whether all above things shall be taken care by MacroExpress3. Thanks ! Rathod. -----Original Message----- From: Jesus Javier Arauz (MI/EEM) [mailto:jesus.javier.arauz@ericsson.com] Sent: Friday, January 05, 2007 1:41 PM To: Rathod Subhashchandra; Sebastien Tricaud Cc: sip@ietf.org Subject: RE: [Sip] tool for automating soft phone key pad clicking Hi, In a recent prototype I had to emulate processing of a 302 response by a SIP client by launching a script that actually dials the phone number received in the Contact header of the 302 on the client's UI. The reason was obviously that the client did not properly implement the re-dialling on reception of the 302. The tool I used is MacroExpress 3 and it worked pretty well. Hope it is helpful, /Javier Rathod Subhashchandra wrote: > Hi Sebastien, > > I went through this. > Looks very complicated. I am looking a tool like WinRunner. Can you > help me in this? > > Thanks ! > Rathod. > > > -----Original Message----- > From: Sebastien Tricaud [mailto:sebastien.tricaud@wengo.fr] > Sent: Thursday, January 04, 2007 3:42 PM > To: Rathod Subhashchandra > Cc: sip@ietf.org > Subject: Re: [Sip] tool for automating soft phone key pad clicking > > > Hello, > > For buttons clicks, I guess you can get sounds produced by softphones > and script a player to it :-) > > Or, you can use miniua for sip calls scripting. Its documentation is > available there -> > http://dev.openwengo.com/trac/openwengo/trac.cgi/wiki/MiniUa > > > In the hope that help you, > > Sebastien. > > > > > > Rathod Subhashchandra wrote: >> Hi All, >> >> I am looking for a tool which shall help in automating third party >> software(SIP Stack phone) like automating of buttons click on the >> soft phones. It would be a great help if someone provides relevant >> details. >> >> Thanks ! >> Rathod. >> >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip Use >> sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 06:48:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2nYF-0000z7-PT; Fri, 05 Jan 2007 06:47:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2nYE-0000z1-KD for sip@ietf.org; Fri, 05 Jan 2007 06:47:58 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2nY8-0005Az-MB for sip@ietf.org; Fri, 05 Jan 2007 06:47:58 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D57237BE for ; Fri, 5 Jan 2007 12:47:43 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 12:47:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 5 Jan 2007 12:47:43 +0100 Message-ID: <7374777208BDC7449D5620EF942325670143FE3D@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Time zone in Date header Thread-Index: Accwv09LBxXQo8GGTaiU1Lj69Av/2A== From: "Christer Holmberg \(JO/LMF\)" To: "SIP WG" X-OriginalArrivalTime: 05 Jan 2007 11:47:43.0503 (UTC) FILETIME=[4F8F59F0:01C730BF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Sip] Time zone in Date header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1973529167==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1973529167== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C730BF.4F990AFB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C730BF.4F990AFB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, What is the reason that SIP only allows GMT in the Date header? Regards, Christer ------_=_NextPart_001_01C730BF.4F990AFB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Time zone in Date header

Hi,

What is the reason that SIP only allows = GMT in the Date header?

Regards,

Christer

------_=_NextPart_001_01C730BF.4F990AFB-- --===============1973529167== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1973529167==-- From sip-bounces@ietf.org Fri Jan 05 07:06:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2npu-0006un-2N; Fri, 05 Jan 2007 07:06:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2npr-0006uW-GL for sip@ietf.org; Fri, 05 Jan 2007 07:06:11 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2npp-000239-Tp for sip@ietf.org; Fri, 05 Jan 2007 07:06:11 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l05C42Lg021515; Fri, 5 Jan 2007 14:04:23 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 14:06:00 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 14:05:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 Date: Fri, 5 Jan 2007 14:05:56 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F032F7B71@esebe103.NOE.Nokia.com> In-Reply-To: <459D0181.6050601@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 Thread-Index: AccwBOYuXzf+mCduQci7Ujg5HtebDgAs6/Ug From: To: , X-OriginalArrivalTime: 05 Jan 2007 12:05:59.0782 (UTC) FILETIME=[DCFE4060:01C730C1] X-Nokia-AV: Clean X-Spam-Score: 1.3 (+) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, >Introduction and the Overview of Operation sections and you will see >that this proposal does not add a lot of complexity to Outbound. I quite much disagree and still think it is too complex.=20 The draft introduces the following pattern: 1. Proxy receives such a big SIP request that it can not pass it to the UA via the persistent UDP flow 2. Consequently the proxy will send ForceTCP message to the UA 3. The UA will open a temporary TCP connection towards the proxy 4. The UA will send a GetToken request to the proxy over the TCP connection 5. The proxy will respond GetToken with a new flow token assigned to the TCP flow 6. UA will store this new TCP flow token and associate it with the UDP flow 7. UA will respond to the ForceTCP message returning the flow token of the TCP flow to the proxy 8. Based on the response from the UA the proxy can now re-map the big SIP request from UDP flow to the new TCP flow and forward it to the UA That does not sound too easy to me. Especially when thinking about: - Various interactions between the SIP and STUN stacks required - Requirement for the UA to start opening TCP connections when there is no SIP request to sent (a change to the connection management architecture laid out in RFC 3261). - Usage of SigComp together with SIP and STUN muxed over a=20 TCP connection, if the deployment requires using SigComp I believe the proposed mechanism does not clearly describe to=20 which address and port the UA should set up its TCP connection. Usually UA resolves the SIP URI of the next hop when sending a request and opens the connection towards a resolved address-port pair. In the context of ForceTCP at least the port is not evident. If proxy has a TCP SIP port configured to the DNS, the UA might already have a TCP connection open towards the proxy even if the proxy does not recognize it. Instead of opening a new TCP connection the existing one could be used, see below. But if DNS does not have TCP SRV record for the proxy, then which port to use ? Always 5060 or should ForceTCP tell the port number ? But if you anyway would like to continue with the draft, please consider an alternative pattern. I believe that the requirement for the UA to associate the UDP and TCP flows together does not make sense. The proxy should maintain this association as it is the proxy who really needs this info, in order to remap inbound requests between flows. Consequently the pattern could be like this: 1. Proxy receives such a big SIP request that it can not pass it to the UA via the persistent UDP flow 2. Consequently the proxy will send ForceTCP message to the UA. This message would contain the flow token of the UDP flow. 3. UA would immediately respond to the ForceTCP message 4. The UA will open a temporary TCP connection towards the proxy or skip this phase if it already has a persistent TCP connection 5. The UA will send a GiveToken request to the proxy over the TCP connection, giving the token of the associated UDP flow 6. The proxy will respond GiveToken request and store the mapping between the TCP and UDP flows 7. Based on the GiveToken from the UA the proxy can now re-map the big SIP request from UDP flow to the TCP flow and forward it to the UA This pattern would also avoid ForceTCP transaction to time out (or retransmissions of ForceTCP) while UA is opening the TCP connection and performing the GetToken exchange. P.S. I still have doubts whether this mechanism, introduced as a=20 separate draft, would gain wide enough acceptance to be really useful for deployments. I also anticipate that when reviewed in detail, the complexity will grow as the problems and different error cases etc. pop up. Regards, Erkki >-----Original Message----- >From: ext Marc Petit-Huguenin [mailto:petithug@acm.org]=20 >Sent: 04.January.2007 15:31 >To: sip@ietf.org >Subject: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 > >I just submitted a new version of my proposal to support hybrid TCP-UDP > transport in Outbound. Until it appears in the archives, a=20 >copy can be >found here: > >http://marc.petit-huguenin.org/draft-petithuguenin-sip-outbound >-fragmentation-01.txt > >This is a nearly complete rewrite. Please read at least the >Introduction and the Overview of Operation sections and you will see >that this proposal does not add a lot of complexity to Outbound. > >Comments and questions are welcome. > >Thanks. > >--=20 >Marc Petit-Huguenin [ ] >Home: marc@petit-huguenin.org [ RFC1855-compliant space for rent] >Work: marc@8x8.com [ ] > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 07:08:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2nrk-0007Sw-SV; Fri, 05 Jan 2007 07:08:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2nrj-0007Sq-LT for sip@ietf.org; Fri, 05 Jan 2007 07:08:07 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2nrg-0002fB-07 for sip@ietf.org; Fri, 05 Jan 2007 07:08:07 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6F78558D; Fri, 5 Jan 2007 13:08:03 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 13:08:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Fri, 5 Jan 2007 13:08:02 +0100 Message-ID: <7374777208BDC7449D5620EF942325670143FEC8@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Thread-Index: Accsdcx4hLDZ/YKlTjuyveZWtIV6YAESsuVQ From: "Christer Holmberg \(JO/LMF\)" To: "Cullen Jennings" , "Francois Audet" X-OriginalArrivalTime: 05 Jan 2007 12:08:02.0852 (UTC) FILETIME=[26593E40:01C730C2] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >>I'm ok with having outbound support STUN-over-UDP, as long as we are=20 >>honest about the implications regarding fragmentation. This=20 >>could be as simple as explaining that if you don't keep a TCP=20 >>channel opened, request that are bigger than MTU and would observe the rules of RFC=20 >>3261/18.1.1 would not be able to be received. >=20 >Yes 100% agree - we should explain the bad implications of=20 >not having a TCP channel open. I am ok with adding such text too. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 07:08:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2nrm-0007VX-OP; Fri, 05 Jan 2007 07:08:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2nrl-0007T2-0g for sip@ietf.org; Fri, 05 Jan 2007 07:08:09 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2nrj-0002sD-LW for sip@ietf.org; Fri, 05 Jan 2007 07:08:08 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1C7D958D; Fri, 5 Jan 2007 13:08:07 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 13:08:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Fri, 5 Jan 2007 13:08:06 +0100 Message-ID: <7374777208BDC7449D5620EF942325670143FEC9@esealmw113.eemea.ericsson.se> In-Reply-To: <91E4CFBC-9DA7-40F5-B757-62E0352708C4@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Thread-Index: AccsdzZCdedu61TwQrK/dGKeXaTxmgESamnA From: "Christer Holmberg \(JO/LMF\)" To: "Cullen Jennings" X-OriginalArrivalTime: 05 Jan 2007 12:08:06.0540 (UTC) FILETIME=[288BFCC0:01C730C2] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I agree with these high level goals. Regards, Christer =20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: 31. joulukuuta 2006 3:01 > To: Cullen Jennings > Cc: SIP > Subject: Re: [Sip] Question about Poll: Proposal relating to=20 > keepalive, TCP,and UDP usage in draft-ietf-sip-outbound >=20 >=20 > If the people who have been expressing strong opinions on the=20 > details of this proposal could comment on if they agree with=20 > these high level goals or not, it would be really helpful for=20 > trying to get this draft to move forward. >=20 > On Dec 16, 2006, at 12:33 PM, Cullen Jennings wrote: >=20 > > Practically speaking given where we are today, I would be a=20 > fan of a=20 > > solution that meant the following goals: > > > > 1) allowed deployments that wanted to use TCP to use TCP > > > > 2) allowed deployments that wanted to use UDP to use only=20 > UDP with the=20 > > known limitations that the UA would not be able to send=20 > large requests > > > > 3) allowed deployments that wanted to use both UDP and TCP to do so=20 > > and not have the size limitations by using switchover >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 07:08:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2nrk-0007Sw-SV; Fri, 05 Jan 2007 07:08:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2nrj-0007Sq-LT for sip@ietf.org; Fri, 05 Jan 2007 07:08:07 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2nrg-0002fB-07 for sip@ietf.org; Fri, 05 Jan 2007 07:08:07 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6F78558D; Fri, 5 Jan 2007 13:08:03 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 13:08:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Fri, 5 Jan 2007 13:08:02 +0100 Message-ID: <7374777208BDC7449D5620EF942325670143FEC8@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Thread-Index: Accsdcx4hLDZ/YKlTjuyveZWtIV6YAESsuVQ From: "Christer Holmberg \(JO/LMF\)" To: "Cullen Jennings" , "Francois Audet" X-OriginalArrivalTime: 05 Jan 2007 12:08:02.0852 (UTC) FILETIME=[26593E40:01C730C2] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >>I'm ok with having outbound support STUN-over-UDP, as long as we are=20 >>honest about the implications regarding fragmentation. This=20 >>could be as simple as explaining that if you don't keep a TCP=20 >>channel opened, request that are bigger than MTU and would observe the rules of RFC=20 >>3261/18.1.1 would not be able to be received. >=20 >Yes 100% agree - we should explain the bad implications of=20 >not having a TCP channel open. I am ok with adding such text too. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 07:08:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2nrm-0007VX-OP; Fri, 05 Jan 2007 07:08:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2nrl-0007T2-0g for sip@ietf.org; Fri, 05 Jan 2007 07:08:09 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2nrj-0002sD-LW for sip@ietf.org; Fri, 05 Jan 2007 07:08:08 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1C7D958D; Fri, 5 Jan 2007 13:08:07 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 13:08:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Fri, 5 Jan 2007 13:08:06 +0100 Message-ID: <7374777208BDC7449D5620EF942325670143FEC9@esealmw113.eemea.ericsson.se> In-Reply-To: <91E4CFBC-9DA7-40F5-B757-62E0352708C4@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Thread-Index: AccsdzZCdedu61TwQrK/dGKeXaTxmgESamnA From: "Christer Holmberg \(JO/LMF\)" To: "Cullen Jennings" X-OriginalArrivalTime: 05 Jan 2007 12:08:06.0540 (UTC) FILETIME=[288BFCC0:01C730C2] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I agree with these high level goals. Regards, Christer =20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: 31. joulukuuta 2006 3:01 > To: Cullen Jennings > Cc: SIP > Subject: Re: [Sip] Question about Poll: Proposal relating to=20 > keepalive, TCP,and UDP usage in draft-ietf-sip-outbound >=20 >=20 > If the people who have been expressing strong opinions on the=20 > details of this proposal could comment on if they agree with=20 > these high level goals or not, it would be really helpful for=20 > trying to get this draft to move forward. >=20 > On Dec 16, 2006, at 12:33 PM, Cullen Jennings wrote: >=20 > > Practically speaking given where we are today, I would be a=20 > fan of a=20 > > solution that meant the following goals: > > > > 1) allowed deployments that wanted to use TCP to use TCP > > > > 2) allowed deployments that wanted to use UDP to use only=20 > UDP with the=20 > > known limitations that the UA would not be able to send=20 > large requests > > > > 3) allowed deployments that wanted to use both UDP and TCP to do so=20 > > and not have the size limitations by using switchover >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 07:12:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2nvY-0003F2-I4; Fri, 05 Jan 2007 07:12:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2nvX-0003Ex-Ro for sip@ietf.org; Fri, 05 Jan 2007 07:12:03 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2nvV-0003en-I4 for sip@ietf.org; Fri, 05 Jan 2007 07:12:03 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1FFD74F0001; Fri, 5 Jan 2007 13:07:52 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 13:07:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Fri, 5 Jan 2007 13:07:50 +0100 Message-ID: <7374777208BDC7449D5620EF942325670143FEC5@esealmw113.eemea.ericsson.se> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E726D00@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Thread-Index: AcchUe1gIxwWbbqbQbWGtWYJehi37ABeMQHAA30+JCA= From: "Christer Holmberg \(JO/LMF\)" To: "Francois Audet" , "Cullen Jennings" , "SIP" X-OriginalArrivalTime: 05 Jan 2007 12:07:51.0745 (UTC) FILETIME=[1FBA7310:01C730C2] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >Many PSTN gateways and Softswitches always send large INVITEs=20 >for example, and they will always fragment. And I might add=20 >that many very popular NAT/routers don't support UDP fragmentation. Why would these nodes send larger INVITEs than e.g. normal UAs? I would claim that in many cases it could be the other way around... Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 07:13:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2nwO-0003q8-Gt; Fri, 05 Jan 2007 07:12:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2nwM-0003pf-R2 for sip@ietf.org; Fri, 05 Jan 2007 07:12:54 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2nwL-00046W-7a for sip@ietf.org; Fri, 05 Jan 2007 07:12:54 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F1166104B; Fri, 5 Jan 2007 13:09:39 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 13:09:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Fri, 5 Jan 2007 13:09:35 +0100 Message-ID: <7374777208BDC7449D5620EF942325670143FED7@esealmw113.eemea.ericsson.se> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F032CE092@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Thread-Index: AccsfQrkgw8odb+sSJCc5azRkm1KfQBxHA1QAKAHmUA= From: "Christer Holmberg \(JO/LMF\)" To: , , X-OriginalArrivalTime: 05 Jan 2007 12:09:39.0396 (UTC) FILETIME=[5FE4B040:01C730C2] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: fluffy@cisco.com, sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >Me too: I also agree with #1 and #2. But when Outbound is=20 >used for NAT traversal I do not find #3 to add any value to=20 >#1. Switchover to TCP (in the presence of NAT) can only be=20 >used if the UA always keeps the TCP alive like in #1. The=20 >additional UDP flow does not bring any significant value for=20 >the deployment. >=20 >The only case where #3 might make some sense is that if 3GPP=20 >wants to support multiregistration of a single UA over=20 >different radio network types (cellular and WLAN) with=20 >Outbound. That use case does not have anything to do with NAT=20 >traversal, so keepalives would not be needed and switchover=20 >from UDP to TCP could be made like in RFC 3261.=20 I don't think we should rule out scenarios multiregistration with Outbound in NAT environments. TISPAN has also been looking at Outbound for certain multiregistraion scenarios. Regards, Christer =20 > >-----Original Message----- > >From: ext Ben Campbell [mailto:ben@nostrum.com] > >Sent: 31.December.2006 03:41 > >To: Adam Roach > >Cc: Cullen Jennings; SIP > >Subject: Re: [Sip] Question about Poll: Proposal relating to=20 > keepalive,=20 > >TCP,and UDP usage in draft-ietf-sip-outbound > > > >I concur with Adam, with the caveat that any unforseen complexities=20 > >that might be introduced by the phrase "not have the size=20 > limitations=20 > >by using switchover" not block the work. That is, if 3 is free, or=20 > >cheap, then great--but I would not want to significantly delay 1 and > >2 in order to get 3. > > > >On Dec 30, 2006, at 7:06 PM, Adam Roach wrote: > > > >> I agree 100% with #1 and #2. I find #3 to be of dubious value,=20 > >> although I see no harm in a solution that has that=20 > property as well=20 > >> (and you seem to get it for free if you satisfy #1 and #2). > >> > >> /a > >> > >> > >> > >> Cullen Jennings wrote: > >>> > >>> If the people who have been expressing strong opinions on the=20 > >>> details of this proposal could comment on if they agree=20 > with these=20 > >>> high level goals or not, it would be really helpful for trying to=20 > >>> get this draft to move forward. > >>> > >>> On Dec 16, 2006, at 12:33 PM, Cullen Jennings wrote: > >>> > >>>> Practically speaking given where we are today, I would=20 > be a fan of=20 > >>>> a solution that meant the following goals: > >>>> > >>>> 1) allowed deployments that wanted to use TCP to use TCP > >>>> > >>>> 2) allowed deployments that wanted to use UDP to use=20 > only UDP with=20 > >>>> the known limitations that the UA would not be able to=20 > send large=20 > >>>> requests > >>>> > >>>> 3) allowed deployments that wanted to use both UDP and=20 > TCP to do so=20 > >>>> and not have the size limitations by using switchover > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol Use=20 > >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>> sipping@ietf.org for new developments on the application of sip > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > > > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol Use=20 > >sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >sipping@ietf.org for new developments on the application of sip > > >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 07:29:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2oCS-0000nf-Ac; Fri, 05 Jan 2007 07:29:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2oCR-0000jy-Bw for sip@ietf.org; Fri, 05 Jan 2007 07:29:31 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2oCP-0007w7-1l for sip@ietf.org; Fri, 05 Jan 2007 07:29:31 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5CE3C6C5; Fri, 5 Jan 2007 13:29:28 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 13:29:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Fri, 5 Jan 2007 13:29:27 +0100 Message-ID: <7374777208BDC7449D5620EF942325670143FF6B@esealmw113.eemea.ericsson.se> In-Reply-To: <17819.64168.559864.751052@harjus.tutpro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Thread-Index: AccvZ/UUjGun/5hXTOGqKM0d48Z/dwBXCTBQ From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" , "Brian Stucker" X-OriginalArrivalTime: 05 Jan 2007 12:29:27.0814 (UTC) FILETIME=[243EE260:01C730C5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Cullen Jennings , SIP , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > IMHO-- we should be flexible in this regard. Make sure=20 > that the UDP > behavior is at least minimally specified in=20 > the standard (warts and all) > and then work outside of=20 > standards with customers so that they fully > appreciate=20 > (and properly value) what they're getting with TCP that >=20 > they're not getting with UDP. At that point I think the whole=20 > debate > will resolve itself because the number of=20 > implementations wanting to use > UDP will drop. >=20 > i would think that the drop will be faster if there is no=20 > support for UDP in outbound. That may also affect the deployment speed of outbound, and people will continue to use whatever mechanisms they are currently using. I pretty much agree with Brian. The market will decide what transport is most suitable. By supporting both UDP and TCP outbound provides a mechanism that works both today and tomorrow (when the SIP messages become too big for UDP, and people realize they must switch to TCP in order to get something to work). Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 07:29:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2oCO-0000he-3S; Fri, 05 Jan 2007 07:29:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2oCM-0000hV-Oi for sip@ietf.org; Fri, 05 Jan 2007 07:29:26 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2oCK-0007vs-1P for sip@ietf.org; Fri, 05 Jan 2007 07:29:26 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 80E254F0006; Fri, 5 Jan 2007 13:29:23 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 13:29:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Fri, 5 Jan 2007 13:29:22 +0100 Message-ID: <7374777208BDC7449D5620EF942325670143FF6A@esealmw113.eemea.ericsson.se> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F032CE050@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Thread-Index: AccsdT4QU8BeWkSzROe/cOROp04J5wByuXCAAKBPpkA= From: "Christer Holmberg \(JO/LMF\)" To: , X-OriginalArrivalTime: 05 Jan 2007 12:29:23.0001 (UTC) FILETIME=[21607A90:01C730C5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Cc: sip@ietf.org, audet@nortel.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I think that proxies should support both TCP and UDP. Regards, Christer=20 > -----Original Message----- > From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com]=20 > Sent: 2. tammikuuta 2007 9:41 > To: fluffy@cisco.com > Cc: sip@ietf.org; audet@nortel.com > Subject: RE: [Sip] Question about Poll: Proposal relating to=20 > keepalive, TCP,and UDP usage in draft-ietf-sip-outbound >=20 >=20 > Hi, >=20 > While my email contained a lot of questions for you rather=20 > than a clear proposal I am not sure if we interpret each=20 > others opinion well enough to say we agree. Anyway to clarify=20 > my opinion - I agree with the proposal given for the poll: >=20 > > Proposal 1: Make CRLF the only keepalive mechanism for TCP and TLS=20 > > over TCP flow (retain STUN for UDP flows). > > > > Proposal 2: Make outbound registrations over UDP flows optional for=20 > > UAs. > > > > Proposal 3: Include (in Outbound) the statement that its is=20 > > RECOMMENDED that the outbound-proxy-set is configured to result in=20 > > registrations over TCP or TLS whenever the UA can't accept incoming=20 > > TCP flows. >=20 > Do you agree with that ? >=20 > As a summary what that would mean in terms of deployments: >=20 > - Every Outbound compliant (UA or proxy) implementation MUST > support TCP but MAY support UDP too. >=20 > - It will be up to the deployment to select whether TCP or UDP > (or even both) shall be used for that specific deployment. > Supporting UDP only would have known limitations and it would > also mean that TCP-only implementations could not be used for > that deployment. >=20 > Erkki=20 >=20 > >-----Original Message----- > >From: ext Cullen Jennings [mailto:fluffy@cisco.com] > >Sent: 31.December.2006 02:48 > >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) > >Cc: audet@nortel.com; sip@ietf.org > >Subject: Re: [Sip] Question about Poll: Proposal relating to=20 > keepalive,=20 > >TCP,and UDP usage in draft-ietf-sip-outbound > > > > > >It took me some time to parse through this but sounds like you and I=20 > >are in 100% agreement on what an acceptable solution would look like. > > > > > >On Dec 20, 2006, at 12:18 AM, =20 > > wrote: > > > >> > >> Hi Cullen, > >> > >>>> Many PSTN gateways and Softswitches always send large=20 > INVITEs for=20 > >>>> example, and they will always fragment. And I might add=20 > that many=20 > >>>> very popular NAT/routers don't support UDP fragmentation. > >>> > >>> Hmm - I wish we had better specifics here - I will point=20 > out there=20 > >>> are millions of endpoints on well known residential=20 > endpoints that=20 > >>> are working through NATs and connected to PSTN gw and=20 > softwswiches=20 > >>> that are working over UDP. > >> > >> If so, then how would those endpoints get any benefit from=20 > Outbound ? > >> What would be the value added for those deployments if those > >endpoints > >> would be changed as Outbound UDP compliant endpoints ? Multiple=20 > >> registration support and new types of keepalive messages i.e. some=20 > >> added reliability ? > >> > >> But if those endpoints and proxies anyway have to be=20 > either upgraded=20 > >> or replaced for Outbound, then why couldn't that upgrade cover TCP=20 > >> support as well ? What is the ultimate benefit for using=20 > UDP instead=20 > >> of TCP for those deployments ? > >> > >>> Uh, no - I was saying that outbound over UDP is usable in > >cases where > >>> the policy is to reject messages that are too large for=20 > UDP. I agree=20 > >>> that limits the functionality of the communications with=20 > the UA that=20 > >>> registered over this UDP only network but that was that=20 > deployments=20 > >>> choice. > >>> > >>> Note what I am talking about here is all about=20 > deployments using TCP=20 > >>> or UDP. I don't mind about if a UA has to implement both. > >> > >> Please remember that the proposal that you do not agree=20 > with was like=20 > >> this: > >> > >>> Proposal 2: Make outbound registrations over UDP flows=20 > optional for=20 > >>> UAs. > >> > >> Outbound over UDP would still be possible and probably=20 > supported by=20 > >> those UA vendors who get significant gain for it. But some UAs=20 > >> targetting to other deployments could just opt to support TCP. > >> What is wrong with that ? > >> > >> If it is the deployments choice to limit the functionality of the=20 > >> communications with the UA registered, why could it not be=20 > possible=20 > >> for the specific closed deployments to administratively (or > >> technically) > >> limit the deployed UAs to be such that implement UDP ? Why=20 > would you=20 > >> mandate ALL the implemented UAs to support UDP for=20 > Outbound ? Those=20 > >> deployments could just tell the users not to aqcuire any UAs which=20 > >> only support Outbound with TCP, if the proxies (or=20 > operator policy)=20 > >> does not support TCP (or does not support persistent TCP > >connections). > >> > >>>> You mean a UA will open two connections, one for UDP and another=20 > >>>> for TCP? I fail to see why on earth anybody would do=20 > this instead=20 > >>>> of just using a single TCP > >connection. > >>> > >>> I think the folks that favor these approach would use a=20 > scheme where=20 > >>> the UDP connection was long lived and the TCP connection=20 > was short=20 > >>> lived for the large messages. The advantages of this=20 > would be to get=20 > >>> the scaleability and reliability schemes that are easier > >with UDP yet > >>> still be able to do large messages. > >> > >> Please remember the Outbound draft does make such a scheme=20 > possible ! > >> If the UA does NOT have a long lived persistent TCP connection=20 > >> available, there is no way for the proxy to get the UA to=20 > open such=20 > >> connection or for the proxy itself open such a TCP=20 > connection towards=20 > >> the UA via the NAT when a large message arrives destined=20 > to the UA.=20 > >> So if the UA does not keep the TCP connection open all the=20 > time, it=20 > >> has to live with the limitation of not being able to receive SIP=20 > >> requests bigger than MTU if the NAT discards fragmented=20 > UDP packets. > >> > >> P.S. Actually there is such a mechanism for that specified in Marc=20 > >> Petit-Huguenin's I-D "Preventing Fragmentation for Client=20 > Initiated=20 > >> Connections in the Session Initiation Protocol (SIP)" -=20 > but that is=20 > >> not within the baseline Outbound spec and there is no normative=20 > >> binding between those specs either. > >> > >> Regards, > >> > >> Erkki > > > > >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 07:36:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2oJO-0005CJ-SY; Fri, 05 Jan 2007 07:36:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2oJN-0005CD-5q for sip@ietf.org; Fri, 05 Jan 2007 07:36:41 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2oJK-0001gZ-R4 for sip@ietf.org; Fri, 05 Jan 2007 07:36:41 -0500 Received: by harjus.tutpro.com (Postfix, from userid 1000) id AAA2DAC2C0; Fri, 5 Jan 2007 14:36:37 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17822.18005.638975.743496@harjus.tutpro.com> Date: Fri, 5 Jan 2007 14:36:37 +0200 To: "Christer Holmberg \(JO/LMF\)" Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound In-Reply-To: <7374777208BDC7449D5620EF942325670143FF6B@esealmw113.eemea.ericsson.se> References: <17819.64168.559864.751052@harjus.tutpro.com> <7374777208BDC7449D5620EF942325670143FF6B@esealmw113.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Cullen Jennings , SIP , Francois Audet , Dean Willis , Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg \(JO/LMF\) writes: > That may also affect the deployment speed of outbound, and people will > continue to use whatever mechanisms they are currently using. what is wrong with that as long existing mechanism work and don't require any standardization? is there some ietf religion here? regarding tcp, outbound should not specify one single mandatory mechanism for keepalives. for example, if SIP UA support tcp keepalives, it should be allowed to use them without sending any application level data (stun or crlf). -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 07:58:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2odj-0005JE-2D; Fri, 05 Jan 2007 07:57:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2odh-0005Dk-KQ for sip@ietf.org; Fri, 05 Jan 2007 07:57:41 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2odf-0007Ol-7X for sip@ietf.org; Fri, 05 Jan 2007 07:57:41 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6FDDB537; Fri, 5 Jan 2007 13:57:34 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 13:57:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Fri, 5 Jan 2007 13:57:33 +0100 Message-ID: <7374777208BDC7449D5620EF942325670144006F@esealmw113.eemea.ericsson.se> In-Reply-To: <17822.18005.638975.743496@harjus.tutpro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Thread-Index: AccwxibTFgpk/ZfiThGqqm8WWTYBYgAABp7Q From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" X-OriginalArrivalTime: 05 Jan 2007 12:57:33.0820 (UTC) FILETIME=[112EFBC0:01C730C9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Cullen Jennings , SIP , Francois Audet , Dean Willis , Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>That may also affect the deployment speed of outbound, and people will continue to use whatever mechanisms they are=20 >>currently using. >=20 >what is wrong with that as long existing mechanism work and don't require any standardization? =20 >is there some ietf religion here? Probably :) But, the reason I like outbound is because I think it's a TECHNICALLY good solution, and more flexible than many of the existing mechanisms. >regarding tcp, outbound should not specify one single mandatory mechanism for keepalives. for example, if SIP UA=20 >support tcp keepalives, it should be allowed to use them without sending any application level data (stun or crlf). Yes. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 08:04:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2oka-0000QB-Ow; Fri, 05 Jan 2007 08:04:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2okZ-0000Q1-6l for sip@ietf.org; Fri, 05 Jan 2007 08:04:47 -0500 Received: from mail.tataelxsi.co.in ([203.200.1.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2okX-0000Us-Js for sip@ietf.org; Fri, 05 Jan 2007 08:04:47 -0500 Received: from rathod ([10.50.42.1]) by mail.tataelxsi.co.in (MOS 3.8.3-GA) with ESMTP id CEG86063 (AUTH rathod); Fri, 5 Jan 2007 18:34:30 +0530 (IST) From: Rathod Subhashchandra To: "'Jesus Javier Arauz \(MI/EEM\)'" , "'Sebastien Tricaud'" Subject: RE: [Sip] tool for automating soft phone key pad clicking Date: Fri, 5 Jan 2007 18:35:31 +0530 Message-ID: <017201c730ca$2ea0b6c0$012a320a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: High X-Junkmail-Status: score=10/50, host=mail.tataelxsi.co.in X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090209.459E4B2C.00BA,ss=1,fgs=0, ip=10.50.42.1, so=2006-12-09 10:45:40, dmn=5.2.125/2006-10-10 X-Spam-Score: 0.4 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rathod Subhashchandra List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Javier, My objective is achieved from this tool. Thanks lot for your timely and good help. Thanks ! Rathod. -----Original Message----- From: Rathod [mailto:rathod@tataelxsi.co.in] Sent: Friday, January 05, 2007 3:13 PM To: 'Jesus Javier Arauz (MI/EEM)'; 'Sebastien Tricaud' Cc: 'sip@ietf.org' Subject: RE: [Sip] tool for automating soft phone key pad clicking Hi Javier, Thanks lot for this information. I have installed the Macro Express 3. Need to play with this tool to know how key strokes can be automated. My requirement is 1. I have developed the test automation tool for SIP protocol conformance. 2. Testing at present with SJPhone. SJPhone needs manual interaction for accepting/rejecting the call and also to place the MT(Mobile Terminating) to the Testing tool. 4. We have close to 300 test cases. Manually accepting/rejecting and placing call for these many test cases is becoming very difficult job. Hence, I wanted to automate the SJPhone for accepting/rejecting/call-placing. I can't write the stub as I don't have interface document. At present, I am not sure, whether all above things shall be taken care by MacroExpress3. Thanks ! Rathod. -----Original Message----- From: Jesus Javier Arauz (MI/EEM) [mailto:jesus.javier.arauz@ericsson.com] Sent: Friday, January 05, 2007 1:41 PM To: Rathod Subhashchandra; Sebastien Tricaud Cc: sip@ietf.org Subject: RE: [Sip] tool for automating soft phone key pad clicking Hi, In a recent prototype I had to emulate processing of a 302 response by a SIP client by launching a script that actually dials the phone number received in the Contact header of the 302 on the client's UI. The reason was obviously that the client did not properly implement the re-dialling on reception of the 302. The tool I used is MacroExpress 3 and it worked pretty well. Hope it is helpful, /Javier Rathod Subhashchandra wrote: > Hi Sebastien, > > I went through this. > Looks very complicated. I am looking a tool like WinRunner. Can you > help me in this? > > Thanks ! > Rathod. > > > -----Original Message----- > From: Sebastien Tricaud [mailto:sebastien.tricaud@wengo.fr] > Sent: Thursday, January 04, 2007 3:42 PM > To: Rathod Subhashchandra > Cc: sip@ietf.org > Subject: Re: [Sip] tool for automating soft phone key pad clicking > > > Hello, > > For buttons clicks, I guess you can get sounds produced by softphones > and script a player to it :-) > > Or, you can use miniua for sip calls scripting. Its documentation is > available there -> > http://dev.openwengo.com/trac/openwengo/trac.cgi/wiki/MiniUa > > > In the hope that help you, > > Sebastien. > > > > > > Rathod Subhashchandra wrote: >> Hi All, >> >> I am looking for a tool which shall help in automating third party >> software(SIP Stack phone) like automating of buttons click on the >> soft phones. It would be a great help if someone provides relevant >> details. >> >> Thanks ! >> Rathod. >> >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip Use >> sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 08:12:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2orD-0003yQ-TG; Fri, 05 Jan 2007 08:11:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2orA-0003yL-Un for sip@ietf.org; Fri, 05 Jan 2007 08:11:37 -0500 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2or8-00026T-5y for sip@ietf.org; Fri, 05 Jan 2007 08:11:36 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id B710521F3C for ; Fri, 5 Jan 2007 18:34:34 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 9991321EA1 for ; Fri, 5 Jan 2007 18:34:34 +0530 (IST) Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 18:41:28 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Time zone in Date header Date: Fri, 5 Jan 2007 18:41:26 +0530 Message-ID: <8A24F115EA58164490CD026E9D0CEAD401A082EA@BLR-EC-MBX02.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Time zone in Date header Thread-Index: Accwv09LBxXQo8GGTaiU1Lj69Av/2AAC4pLQ From: To: , X-OriginalArrivalTime: 05 Jan 2007 13:11:28.0022 (UTC) FILETIME=[02681B60:01C730CB] X-Spam-Score: 0.2 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0536854914==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0536854914== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C730CB.02418665" This is a multi-part message in MIME format. ------_=_NextPart_001_01C730CB.02418665 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Christer, =20 we had a discussion on this some time back in the list: refer this url: http://www1.ietf.org/mail-archive/web/sipping/current/msg06624.html =20 HTH, SReeram. ________________________________ From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] Sent: Friday, January 05, 2007 5:18 PM To: SIP WG Subject: [Sip] Time zone in Date header Hi,=20 What is the reason that SIP only allows GMT in the Date header?=20 Regards,=20 Christer=20 ------_=_NextPart_001_01C730CB.02418665 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Time zone in Date header
Hi Christer,
 
we had a discussion on this some time back in = the=20 list:
refer this url: http://www1.ietf.org/mail-archive/web/sipping/current/msg06624.html
 
HTH,
SReeram.

From: Christer Holmberg (JO/LMF)=20 [mailto:christer.holmberg@ericsson.com]
Sent: Friday, January = 05,=20 2007 5:18 PM
To: SIP WG
Subject: [Sip] Time zone in = Date=20 header


Hi,

What is the reason that SIP only allows = GMT in the=20 Date header?

Regards,

Christer

------_=_NextPart_001_01C730CB.02418665-- --===============0536854914== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0536854914==-- From sip-bounces@ietf.org Fri Jan 05 08:19:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2oyl-0007P5-F1; Fri, 05 Jan 2007 08:19:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2oyk-0007Oz-1j for sip@ietf.org; Fri, 05 Jan 2007 08:19:26 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2oye-0003eC-BM for sip@ietf.org; Fri, 05 Jan 2007 08:19:26 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 915301C4; Fri, 5 Jan 2007 14:19:15 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 14:19:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Time zone in Date header Date: Fri, 5 Jan 2007 14:19:14 +0100 Message-ID: <7374777208BDC7449D5620EF9423256701440126@esealmw113.eemea.ericsson.se> In-Reply-To: <8A24F115EA58164490CD026E9D0CEAD401A082EA@BLR-EC-MBX02.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Time zone in Date header Thread-Index: Accwv09LBxXQo8GGTaiU1Lj69Av/2AAC4pLQAABJOHA= From: "Christer Holmberg \(JO/LMF\)" To: , X-OriginalArrivalTime: 05 Jan 2007 13:19:14.0934 (UTC) FILETIME=[18B53960:01C730CC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.3 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0637118906==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0637118906== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C730CC.18C8D98D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C730CC.18C8D98D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Thanks for the link! =20 So, has something happened after that? Anyone drafting something? :) =20 Regards, =20 Christer ________________________________ From: sreeram.kanumuri@wipro.com [mailto:sreeram.kanumuri@wipro.com]=20 Sent: 5. tammikuuta 2007 15:11 To: Christer Holmberg (JO/LMF); sip@ietf.org Subject: RE: [Sip] Time zone in Date header =09 =09 Hi Christer, =20 we had a discussion on this some time back in the list: refer this url: http://www1.ietf.org/mail-archive/web/sipping/current/msg06624.html =20 HTH, SReeram. ________________________________ From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com]=20 Sent: Friday, January 05, 2007 5:18 PM To: SIP WG Subject: [Sip] Time zone in Date header =09 =09 Hi,=20 What is the reason that SIP only allows GMT in the Date header?=20 Regards,=20 Christer=20 The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.=20 WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com =09 ------_=_NextPart_001_01C730CC.18C8D98D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Time zone in Date header
Hi,
 
Thanks=20 for the link!
 
So,=20 has something happened after that? Anyone drafting something?=20 :)
 
Regards,
 
Christer

From: sreeram.kanumuri@wipro.com=20 [mailto:sreeram.kanumuri@wipro.com]
Sent: 5. tammikuuta = 2007=20 15:11
To: Christer Holmberg (JO/LMF);=20 sip@ietf.org
Subject: RE: [Sip] Time zone in Date=20 header

Hi Christer,
 
we had a discussion on this some time back = in the=20 list:
refer this url: http://www1.ietf.org/mail-archive/web/sipping/current/msg06624.html
 
HTH,
SReeram.

From: Christer Holmberg (JO/LMF)=20 [mailto:christer.holmberg@ericsson.com]
Sent: Friday, = January 05,=20 2007 5:18 PM
To: SIP WG
Subject: [Sip] Time zone = in Date=20 header


Hi,

What is the reason that SIP only allows = GMT in the=20 Date header?

Regards,

Christer


The information = contained in=20 this electronic message and any attachments to this message are = intended=20 for the exclusive use of the addressee(s) and may contain = proprietary,=20 confidential or privileged information. If you are not the = intended=20 recipient, you should not disseminate, distribute or copy this = e-mail.=20 Please notify the sender immediately and destroy all copies of = this=20 message and any attachments.

WARNING: Computer viruses = can be=20 transmitted via email. The recipient should check this email and = any=20 attachments for the presence of viruses. The company accepts no=20 liability for any damage caused by any virus transmitted by this = = email.

www.wipro.com
------_=_NextPart_001_01C730CC.18C8D98D-- --===============0637118906== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0637118906==-- From sip-bounces@ietf.org Fri Jan 05 08:29:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2p8E-00036u-6v; Fri, 05 Jan 2007 08:29:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2p8C-00035m-Dy for sip@ietf.org; Fri, 05 Jan 2007 08:29:12 -0500 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2p8A-0005PR-3B for sip@ietf.org; Fri, 05 Jan 2007 08:29:12 -0500 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 65B6020A6D4; Fri, 5 Jan 2007 14:29:06 +0100 (CET) Message-Id: <7.0.1.0.0.20070105142623.0255f908@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 05 Jan 2007 14:29:00 +0100 To: jh@tutpro.com (Juha Heinanen), Cullen Jennings From: Jiri Kuthan Subject: Re: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound In-Reply-To: <17821.60560.400209.135681@harjus.tutpro.com> References: <458F1308.2070601@softarmor.com> <6FC4416DDE56C44DA0AEE67BC7CA43711213EA6F@zrc2hxm2.corp.nortel.com> <17819.64168.559864.751052@harjus.tutpro.com> <5F813F72-62E8-48C2-9130-68B39F71CDBE@cisco.com> <17821.60560.400209.135681@harjus.tutpro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: SIP , Francois Audet , Brian Stucker , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 07:13 05/01/2007, Juha Heinanen wrote: >Cullen Jennings writes: > > > I don't. The problem is not that UAs don't support TCP. > >how can you from cisco say that the problem is not that UAs don't >support TCP, when UAs from cisco and its affiliates don't support TCP? > > > The problems is that proxies don't support TCP on a large scale. > >which popular proxies don't support TCP in large scale? give me some >names. if there are some, i'm sure their vendors must fix them, because >otherwise they would be out of business. Well, based on sipit observations it appears much easier to compile a short list of those that do TCP in large scale. Solely based on what I'm aware of sole presence of TCP is okay, 50k TCP connections is very good, 200k is fantastic (and to some extent uncertain) and more than that is sci-fi. -jiri -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 08:39:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2pI9-0007sd-Lm; Fri, 05 Jan 2007 08:39:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2pI7-0007iw-Rh for sip@ietf.org; Fri, 05 Jan 2007 08:39:27 -0500 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2pI5-0007Mw-Lx for sip@ietf.org; Fri, 05 Jan 2007 08:39:27 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 3063022073 for ; Fri, 5 Jan 2007 19:02:23 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 4AA7322075 for ; Fri, 5 Jan 2007 19:02:19 +0530 (IST) Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 19:09:12 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Time zone in Date header Date: Fri, 5 Jan 2007 19:09:11 +0530 Message-ID: <8A24F115EA58164490CD026E9D0CEAD401A08310@BLR-EC-MBX02.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Time zone in Date header Thread-Index: Accwv09LBxXQo8GGTaiU1Lj69Av/2AAC4pLQAABJOHAAAKALcA== From: To: , X-OriginalArrivalTime: 05 Jan 2007 13:39:12.0412 (UTC) FILETIME=[E275DDC0:01C730CE] X-Spam-Score: 0.4 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0879807888==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0879807888== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C730CE.E2599125" This is a multi-part message in MIME format. ------_=_NextPart_001_01C730CE.E2599125 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Christer, =20 Noting happened after that dicussion. =20 As I said some time back I prefer it to be Drafted. I agree adding time zone may increase the complexity , but also gives a lot of other uses which can be used in applications. =20 -SReeram. ________________________________ From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] Sent: Friday, January 05, 2007 6:49 PM To: Sreeram Kanumuri (WT01 - IP-Multimedia Carrier & Ent Networks); sip@ietf.org Subject: RE: [Sip] Time zone in Date header Hi, =20 Thanks for the link! =20 So, has something happened after that? Anyone drafting something? :) =20 Regards, =20 Christer ________________________________ From: sreeram.kanumuri@wipro.com [mailto:sreeram.kanumuri@wipro.com]=20 Sent: 5. tammikuuta 2007 15:11 To: Christer Holmberg (JO/LMF); sip@ietf.org Subject: RE: [Sip] Time zone in Date header =09 =09 Hi Christer, =20 we had a discussion on this some time back in the list: refer this url: http://www1.ietf.org/mail-archive/web/sipping/current/msg06624.html =20 HTH, SReeram. ________________________________ From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com]=20 Sent: Friday, January 05, 2007 5:18 PM To: SIP WG Subject: [Sip] Time zone in Date header =09 =09 Hi,=20 What is the reason that SIP only allows GMT in the Date header?=20 Regards,=20 Christer=20 The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.=20 WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com =09 ------_=_NextPart_001_01C730CE.E2599125 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Time zone in Date header
Hi Christer,
 
Noting happened after that = dicussion.
 
As I said some time back I prefer it to be=20 Drafted.
I agree adding time zone may increase the = complexity , but=20 also gives a lot of  other uses which can be used in=20 applications.
 
-SReeram.

From: Christer Holmberg (JO/LMF)=20 [mailto:christer.holmberg@ericsson.com]
Sent: Friday, January = 05,=20 2007 6:49 PM
To: Sreeram Kanumuri (WT01 - IP-Multimedia = Carrier &=20 Ent Networks); sip@ietf.org
Subject: RE: [Sip] Time zone in = Date=20 header

Hi,
 
Thanks=20 for the link!
 
So,=20 has something happened after that? Anyone drafting something?=20 :)
 
Regards,
 
Christer

From: sreeram.kanumuri@wipro.com=20 [mailto:sreeram.kanumuri@wipro.com]
Sent: 5. tammikuuta = 2007=20 15:11
To: Christer Holmberg (JO/LMF);=20 sip@ietf.org
Subject: RE: [Sip] Time zone in Date=20 header

Hi Christer,
 
we had a discussion on this some time back = in the=20 list:
refer this url: http://www1.ietf.org/mail-archive/web/sipping/current/msg06624.html
 
HTH,
SReeram.

From: Christer Holmberg (JO/LMF)=20 [mailto:christer.holmberg@ericsson.com]
Sent: Friday, = January 05,=20 2007 5:18 PM
To: SIP WG
Subject: [Sip] Time zone = in Date=20 header


Hi,

What is the reason that SIP only allows = GMT in the=20 Date header?

Regards,

Christer


The information = contained in=20 this electronic message and any attachments to this message are = intended=20 for the exclusive use of the addressee(s) and may contain = proprietary,=20 confidential or privileged information. If you are not the = intended=20 recipient, you should not disseminate, distribute or copy this = e-mail.=20 Please notify the sender immediately and destroy all copies of = this=20 message and any attachments.

WARNING: Computer viruses = can be=20 transmitted via email. The recipient should check this email and = any=20 attachments for the presence of viruses. The company accepts no=20 liability for any damage caused by any virus transmitted by this = = email.

www.wipro.com
------_=_NextPart_001_01C730CE.E2599125-- --===============0879807888== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0879807888==-- From sip-bounces@ietf.org Fri Jan 05 09:26:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2q0o-0002eG-FZ; Fri, 05 Jan 2007 09:25:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2q0n-0002cl-Aw for sip@ietf.org; Fri, 05 Jan 2007 09:25:37 -0500 Received: from mailx.8x8.com ([192.84.19.237] helo=mailint.8x8.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2q0m-0001i9-Ph for sip@ietf.org; Fri, 05 Jan 2007 09:25:37 -0500 Received: from mailint.8x8.com (localhost.localdomain [127.0.0.1]) by mailint.8x8.com (8.13.1/8.13.1) with ESMTP id l05EPTO0023272; Fri, 5 Jan 2007 06:25:29 -0800 Received: from mailint.8x8.com (root@localhost) by mailint.8x8.com (8.13.1/8.13.1/Submit) with ESMTP id l05EPTx9023271; Fri, 5 Jan 2007 06:25:29 -0800 Received: from [192.168.48.184] ( 192.168.48.184) by mailint.8x8.com (Scalix SMTP Relay 10.0.1.3) via ESMTP; Fri, 05 Jan 2007 06:25:28 -0800 (PST) Date: Fri, 5 Jan 2007 15:25:25 +0100 From: Marc Petit-Huguenin To: Erkki.Koivusalo@nokia.com Message-ID: <459E5FD5.5050306@acm.org> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F032F7B71@esebe103.NOE.Nokia.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F032F7B71@esebe103.NOE.Nokia.com> Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 x-scalix-Hops: 1 User-Agent: Icedove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline X-Spam-Score: 1.1 (+) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Erkki, Thanks for your comments. Please see my responses inline. Erkki.Koivusalo@nokia.com wrote: > Hi, > >> Introduction and the Overview of Operation sections and you will see >> that this proposal does not add a lot of complexity to Outbound. > > I quite much disagree and still think it is too complex. > The draft introduces the following pattern: > > 1. Proxy receives such a big SIP request that it can not pass it > to the UA via the persistent UDP flow > 2. Consequently the proxy will send ForceTCP message to the UA > 3. The UA will open a temporary TCP connection towards the proxy > 4. The UA will send a GetToken request to the proxy over the TCP > connection > 5. The proxy will respond GetToken with a new flow token assigned > to the TCP flow > 6. UA will store this new TCP flow token and associate it with the > UDP flow > 7. UA will respond to the ForceTCP message returning the flow token > of the TCP flow to the proxy > 8. Based on the response from the UA the proxy can now re-map the > big SIP request from UDP flow to the new TCP flow and forward > it to the UA > > That does not sound too easy to me. Especially when thinking about: > - Various interactions between the SIP and STUN stacks required > - Requirement for the UA to start opening TCP connections when > there is no SIP request to sent (a change to the connection > management architecture laid out in RFC 3261). > - Usage of SigComp together with SIP and STUN muxed over a > TCP connection, if the deployment requires using SigComp > > I believe the proposed mechanism does not clearly describe to > which address and port the UA should set up its TCP connection. > Usually UA resolves the SIP URI of the next hop when sending > a request and opens the connection towards a resolved address-port > pair. In the context of ForceTCP at least the port is not evident. > > If proxy has a TCP SIP port configured to the DNS, the UA might > already have a TCP connection open towards the proxy even if the > proxy does not recognize it. Instead of opening a new TCP connection > the existing one could be used, see below. But if DNS does > not have TCP SRV record for the proxy, then which port to use ? > Always 5060 or should ForceTCP tell the port number ? The remote UDP IP address and port are used to open the TCP connection. This works because "[f]or any port and interface that a server listens on for UDP, it MUST listen on that same port and interface for TCP." (RFC 3261 Section 18.2.1). I will add this to the draft. > > > But if you anyway would like to continue with the draft, please > consider an alternative pattern. > > I believe that the requirement for the UA to associate the UDP and > TCP flows together does not make sense. The proxy should maintain > this association as it is the proxy who really needs this info, > in order to remap inbound requests between flows. Consequently > the pattern could be like this: > > 1. Proxy receives such a big SIP request that it can not pass it > to the UA via the persistent UDP flow > 2. Consequently the proxy will send ForceTCP message to the UA. > This message would contain the flow token of the UDP flow. > 3. UA would immediately respond to the ForceTCP message > 4. The UA will open a temporary TCP connection towards the proxy > or skip this phase if it already has a persistent TCP connection > 5. The UA will send a GiveToken request to the proxy over the TCP > connection, giving the token of the associated UDP flow > 6. The proxy will respond GiveToken request and store the mapping > between the TCP and UDP flows > 7. Based on the GiveToken from the UA the proxy can now re-map the > big SIP request from UDP flow to the TCP flow and forward > it to the UA This is a nice improvement on my proposal, and I would suggest an additional improvement by using Indications for ForceTCP and GiveToken. The proxy can retransmit the ForceTCP Indication until the GiveToken is received, and so reduce the number of STUN messages exchanged to two. The only problem I see with this pattern is that it is not scalable. The reason I proposed to store the association in the UA is that there is no need for data locking in the proxy. With your pattern, the structure that contains the mapping between UDP and TCP flows needs to be locked during the access, and as this is a global structure that will be under heavy use, this will reduce the scalability. > > This pattern would also avoid ForceTCP transaction to time out > (or retransmissions of ForceTCP) while UA is opening the TCP > connection and performing the GetToken exchange. > Yes, I knew about this problem. I thought about using a STUN 100 Error response to stop the retransmission, but I discovered that it does not work. I sent an email to the BEHAVE list about this issue: http://www1.ietf.org/mail-archive/web/behave/current/msg01859.html > > P.S. I still have doubts whether this mechanism, introduced as a > separate draft, would gain wide enough acceptance to be really > useful for deployments. I also anticipate that when reviewed in > detail, the complexity will grow as the problems and different > error cases etc. pop up. I do not expect to have this draft published as an RFC. I do not like to complain about problems without proposing solutions, and an I-D is a good way to present them. UDP as it is in Outbound does not work and need to be fixed. My proposal (or another proposal) can be added to the existing Outbound draft, but I do not think that this is a good idea to delay even more Outbound. Another solution would be to remove completely UDP from Outbound and add a text saying that UDP is still mandatory, but Outbound covers only TCP, and to start to work on a UDP-Outbound draft (based or not on my draft). -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: marc@8x8.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 09:33:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2q8Y-0006Ps-DM; Fri, 05 Jan 2007 09:33:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2q8X-0006PT-Dy for sip@ietf.org; Fri, 05 Jan 2007 09:33:37 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2q8V-0003dh-2u for sip@ietf.org; Fri, 05 Jan 2007 09:33:37 -0500 Received: by harjus.tutpro.com (Postfix, from userid 1000) id F2732AC2C0; Fri, 5 Jan 2007 16:33:33 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17822.25021.937610.439146@harjus.tutpro.com> Date: Fri, 5 Jan 2007 16:33:33 +0200 To: Marc Petit-Huguenin Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 In-Reply-To: <459E5FD5.5050306@acm.org> References: <8B1D53AEF7B03449A6D3771B3B7F850F032F7B71@esebe103.NOE.Nokia.com> <459E5FD5.5050306@acm.org> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 1.1 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Marc Petit-Huguenin writes: > > 1. Proxy receives such a big SIP request that it can not pass it > > to the UA via the persistent UDP flow > > 2. Consequently the proxy will send ForceTCP message to the UA > > 3. The UA will open a temporary TCP connection towards the proxy > > 4. The UA will send a GetToken request to the proxy over the TCP > > connection > > 5. The proxy will respond GetToken with a new flow token assigned > > to the TCP flow > > 6. UA will store this new TCP flow token and associate it with the > > UDP flow > > 7. UA will respond to the ForceTCP message returning the flow token > > of the TCP flow to the proxy > > 8. Based on the response from the UA the proxy can now re-map the > > big SIP request from UDP flow to the new TCP flow and forward > > it to the UA you must be joking. looks like ietf folks are living in an extremely complex surrealistic world. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 11:10:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2rcp-0005Rp-2L; Fri, 05 Jan 2007 11:08:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2rco-0005RX-9b for sip@ietf.org; Fri, 05 Jan 2007 11:08:58 -0500 Received: from celine.siteprotect.com ([64.26.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2rcm-0002dg-9y for sip@ietf.org; Fri, 05 Jan 2007 11:08:57 -0500 Received: from cornfed (c-24-9-79-73.hsd1.co.comcast.net [24.9.79.73]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id l05G8gv26814; Fri, 5 Jan 2007 10:08:42 -0600 Message-Id: <200701051608.l05G8gv26814@celine.siteprotect.com> From: "Frank W. Miller" To: "'Juha Heinanen'" , "'Marc Petit-Huguenin'" Subject: RE: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 Date: Fri, 5 Jan 2007 09:08:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Accw1og6OtX5UYQFRzu+F4FTZXLNgAADN/Ag In-Reply-To: <17822.25021.937610.439146@harjus.tutpro.com> X-Spam-Score: 1.1 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org With all due respect to everyone, I would like to echo and amplify this. The entire direction of the SIP spec lately, outbound, ice, etc. have really become overly complex. I think a concerted effort to take a step back and simplify things would benefit the entire community. Thanks, FM -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com] Sent: Friday, January 05, 2007 7:34 AM To: Marc Petit-Huguenin Cc: sip@ietf.org Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 Marc Petit-Huguenin writes: > > 1. Proxy receives such a big SIP request that it can not pass it > > to the UA via the persistent UDP flow > > 2. Consequently the proxy will send ForceTCP message to the UA > > 3. The UA will open a temporary TCP connection towards the proxy > > 4. The UA will send a GetToken request to the proxy over the TCP > > connection > > 5. The proxy will respond GetToken with a new flow token assigned > > to the TCP flow > > 6. UA will store this new TCP flow token and associate it with the > > UDP flow > > 7. UA will respond to the ForceTCP message returning the flow token > > of the TCP flow to the proxy > > 8. Based on the response from the UA the proxy can now re-map the > > big SIP request from UDP flow to the new TCP flow and forward > > it to the UA you must be joking. looks like ietf folks are living in an extremely complex surrealistic world. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 11:34:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2s0h-00074z-2A; Fri, 05 Jan 2007 11:33:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2s0g-00074l-9u for sip@ietf.org; Fri, 05 Jan 2007 11:33:38 -0500 Received: from mailx.8x8.com ([192.84.19.237] helo=mailint.8x8.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2s0c-0002fD-KA for sip@ietf.org; Fri, 05 Jan 2007 11:33:38 -0500 Received: from mailint.8x8.com (localhost.localdomain [127.0.0.1]) by mailint.8x8.com (8.13.1/8.13.1) with ESMTP id l05GXSFx002239; Fri, 5 Jan 2007 08:33:28 -0800 Received: from mailint.8x8.com (root@localhost) by mailint.8x8.com (8.13.1/8.13.1/Submit) with ESMTP id l05GXD8p002232; Fri, 5 Jan 2007 08:33:19 -0800 Received: from [10.0.2.15] (godzilla.8x8.com 192.168.84.42) by mailint.8x8.com (Scalix SMTP Relay 10.0.1.3) via ESMTP; Fri, 05 Jan 2007 08:33:10 -0800 (PST) Date: Fri, 5 Jan 2007 17:32:58 +0100 From: Marc Petit-Huguenin To: "Frank W. Miller" Message-ID: <459E7DBA.1090701@acm.org> In-Reply-To: <200701051608.l05G8gv26814@celine.siteprotect.com> References: <200701051608.l05G8gv26814@celine.siteprotect.com> Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 x-scalix-Hops: 1 User-Agent: Icedove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline X-Spam-Score: 1.1 (+) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: sip@ietf.org, 'Juha Heinanen' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Frank W. Miller wrote: > > With all due respect to everyone, I would like to echo and amplify this. > The entire direction of the SIP spec lately, outbound, ice, etc. have really > become overly complex. I think a concerted effort to take a step back and > simplify things would benefit the entire community. "For every complex problem, there is a solution that is simple, neat, and wrong." H.L. Mencken (1880-1956) SIP didn't create the problem. The ISPs who didn't deploy IPv6, the vendors who sold NAT boxes and especially people who does not understand the end to end argument created the problem. > > Thanks, > FM > > > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: Friday, January 05, 2007 7:34 AM > To: Marc Petit-Huguenin > Cc: sip@ietf.org > Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 > > Marc Petit-Huguenin writes: > > > > 1. Proxy receives such a big SIP request that it can not pass it > > > to the UA via the persistent UDP flow > > > 2. Consequently the proxy will send ForceTCP message to the UA > > > 3. The UA will open a temporary TCP connection towards the proxy > > > 4. The UA will send a GetToken request to the proxy over the TCP > > > connection > > > 5. The proxy will respond GetToken with a new flow token assigned > > > to the TCP flow > > > 6. UA will store this new TCP flow token and associate it with the > > > UDP flow > > > 7. UA will respond to the ForceTCP message returning the flow token > > > of the TCP flow to the proxy > > > 8. Based on the response from the UA the proxy can now re-map the > > > big SIP request from UDP flow to the new TCP flow and forward > > > it to the UA > > you must be joking. looks like ietf folks are living in an extremely > complex surrealistic world. > > -- juha > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From louvan@bigpond.com Fri Jan 05 11:57:17 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2sNZ-0006jl-K1 for sip-archive@lists.ietf.org; Fri, 05 Jan 2007 11:57:17 -0500 Received: from 69.red-88-1-23.dynamicip.rima-tde.net ([88.1.23.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2sNX-0002ea-Em for sip-archive@lists.ietf.org; Fri, 05 Jan 2007 11:57:17 -0500 Received: from 144.140.80.13 (HELO extmail.bigpond.com) by lists.ietf.org with esmtp (0I1F*>F9=?W7 (3H*) id I0+R9--/+35'/-9) for sip-archive@lists.ietf.org; Fri, 5 Jan 2007 17:10:01 -0060 Date: Fri, 5 Jan 2007 17:10:01 -0060 From: Nasdaq.com Alert! X-Mailer: The Bat! (v3.71.14) Professional X-Priority: 3 (Normal) Message-ID: <257790455.18231470625010@thebat.net> To: sip-archive@lists.ietf.org Subject: Hurry do not let yourself to miss this incredible offer. MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam: Not detected X-Spam-Score: 4.4 (++++) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 The favorable terms and conditions for your business in WDSC Sudan has always rejected plans to replace the AU force with a larger, stro= nger UN mission. On Thursday, UN chief Kofi Annan had said a compromise had= been reached for a hybrid UN-AU force, to break the deadlock over the Darf= ur mission. More than 200,000 people have died in three years of conflict i= n the region. His Foreign Minister Lam Akol specified that "there should be= no talk about a mixed force". President Omar al-Bashir told state TV: "The= government of Sudan welcomes all financial, material, logistic or technica= l assistance from the UN in order to strengthen the AU mission in Darfur." =
Untitled Document
WORLDSOURCE INC.
GET WDSC (WORLDSOURCE INC)
FIRST THI= NG AFTER NEW YEAR. THIS IS GOING TO ERUPT!
JUST VIEW= FOR HOT NEWS ABOUT THIS COMPANY. THE ALARM IS ON!!!
YOUR BROK= ERAGE SITE HELPS YOU TO REALIZE THE EXHAUSTIVE INFORMATION ON WDSC.<= /th>
IT=92S GE= TTING GROWTH ALMOST EVERY HOUR! MORE THAN 75%= DAILY FROM OPENING PRICE.
HARDLY YO= U HAD A CHANCE TO DOUBLE YOUR INVESTMENTS JUST PER 1 WEEK.
CALL YOU = BROKERS IMMEDIATELY AND MAKE THEM TO BUY IT. DO NOT MISS YOUR CHANCE!!!
GO WDSC!

Following a meetingAbout three million have fled their homes. Chad in anti-= Sudan alliance
From sip-bounces@ietf.org Fri Jan 05 12:04:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2sUL-00021n-W9; Fri, 05 Jan 2007 12:04:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2sUK-00021c-A3 for sip@ietf.org; Fri, 05 Jan 2007 12:04:16 -0500 Received: from mailout-1.omnitel.it ([194.20.77.121] helo=fmis437.omnitel.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2sUJ-0004eA-He for sip@ietf.org; Fri, 05 Jan 2007 12:04:16 -0500 Received: from omini96.omnitel.it (omini96.omnitel.it [10.21.18.148]) by fmis437.omnitel.it (Switch-3.2.5/Switch-3.2.5) with ESMTP id l05H4Ci3003645 for ; Fri, 5 Jan 2007 18:04:12 +0100 (MET) Received: from oivmexo01.omnitel.it ([10.31.32.12]) by ominc75.omnitel.it with Microsoft SMTPSVC(5.0.2195.6713); Fri, 5 Jan 2007 18:04:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 Date: Fri, 5 Jan 2007 18:03:30 +0100 Message-ID: <5371BE300539E6439919CF97203DDEC208B3D11F@OIVMEXO01.omnitel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 Thread-Index: Accw52uVL9zWnirpSBq3EIxbcRQPDAAAE4LA From: "STURA, Marco, VF-IT" To: "Marc Petit-Huguenin" , "Frank W. Miller" X-OriginalArrivalTime: 05 Jan 2007 17:04:11.0372 (UTC) FILETIME=[85363AC0:01C730EB] X-Spam-Score: 1.2 (+) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org, Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >SIP didn't create the problem. The ISPs who didn't deploy IPv6, the = >vendors who sold NAT boxes and especially people who does not = understand >the end to end argument created the problem. Oh yes! I fully agree on this analysis. For instance deploying IPv6 = would have had much lower cost and complexity at the end than all these = solutions we need to workaround and stuff would have worked nicely and = smoothly probably faster......but creating problems often justify things = that otherwise won't be necessary and so here we are :-) -----Original Message----- From: Marc Petit-Huguenin [mailto:petithug@acm.org]=20 Sent: venerd=EC 5 gennaio 2007 17.33 To: Frank W. Miller Cc: sip@ietf.org; 'Juha Heinanen' Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 Frank W. Miller wrote: >=20 > With all due respect to everyone, I would like to echo and amplify = this. > The entire direction of the SIP spec lately, outbound, ice, etc. have = really > become overly complex. I think a concerted effort to take a step back = and > simplify things would benefit the entire community. "For every complex problem, there is a solution that is simple, neat, and wrong." H.L. Mencken (1880-1956) SIP didn't create the problem. The ISPs who didn't deploy IPv6, the vendors who sold NAT boxes and especially people who does not understand the end to end argument created the problem. >=20 > Thanks, > FM >=20 >=20 > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com]=20 > Sent: Friday, January 05, 2007 7:34 AM > To: Marc Petit-Huguenin > Cc: sip@ietf.org > Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 >=20 > Marc Petit-Huguenin writes: >=20 > > > 1. Proxy receives such a big SIP request that it can not pass it > > > to the UA via the persistent UDP flow > > > 2. Consequently the proxy will send ForceTCP message to the UA > > > 3. The UA will open a temporary TCP connection towards the proxy > > > 4. The UA will send a GetToken request to the proxy over the TCP > > > connection > > > 5. The proxy will respond GetToken with a new flow token assigned > > > to the TCP flow > > > 6. UA will store this new TCP flow token and associate it with = the > > > UDP flow > > > 7. UA will respond to the ForceTCP message returning the flow = token > > > of the TCP flow to the proxy > > > 8. Based on the response from the UA the proxy can now re-map the > > > big SIP request from UDP flow to the new TCP flow and forward > > > it to the UA >=20 > you must be joking. looks like ietf folks are living in an extremely > complex surrealistic world. >=20 > -- juha >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 12:15:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2seE-0006ta-PN; Fri, 05 Jan 2007 12:14:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2seD-0006tP-Nm for sip@ietf.org; Fri, 05 Jan 2007 12:14:29 -0500 Received: from celine.siteprotect.com ([64.26.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2seB-0000Ob-Ck for sip@ietf.org; Fri, 05 Jan 2007 12:14:29 -0500 Received: from cornfed (c-24-9-79-73.hsd1.co.comcast.net [24.9.79.73]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id l05HEFv01323; Fri, 5 Jan 2007 11:14:15 -0600 Message-Id: <200701051714.l05HEFv01323@celine.siteprotect.com> From: "Frank W. Miller" To: "'Marc Petit-Huguenin'" Subject: RE: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 Date: Fri, 5 Jan 2007 10:13:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Accw5zsS1QJES15lSyOQ2mmWKi08UwABMsyA In-Reply-To: <459E7DBA.1090701@acm.org> X-Spam-Score: 1.1 (+) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: sip@ietf.org, 'Juha Heinanen' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Do you honestly think that there wouldn't be NAT if the world were completely IPv6? NAT may have originally been put in place to alleviate the IPv4 address exhaustion problem but separation of address spaces is more useful than that, no matter how big the address spaces are. While I would luv for the public Internet to be purely end-to-end wrt IP addresses, this just is never going to happen again. The early days of a few hundred VAXs all happily talking to each other directly are long gone. The days of trust are gone forever and NAT is just one reflection of that. FM -----Original Message----- From: Marc Petit-Huguenin [mailto:petithug@acm.org] Sent: Friday, January 05, 2007 9:33 AM To: Frank W. Miller Cc: 'Juha Heinanen'; sip@ietf.org Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 Frank W. Miller wrote: > > With all due respect to everyone, I would like to echo and amplify this. > The entire direction of the SIP spec lately, outbound, ice, etc. have really > become overly complex. I think a concerted effort to take a step back and > simplify things would benefit the entire community. "For every complex problem, there is a solution that is simple, neat, and wrong." H.L. Mencken (1880-1956) SIP didn't create the problem. The ISPs who didn't deploy IPv6, the vendors who sold NAT boxes and especially people who does not understand the end to end argument created the problem. > > Thanks, > FM > > > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: Friday, January 05, 2007 7:34 AM > To: Marc Petit-Huguenin > Cc: sip@ietf.org > Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 > > Marc Petit-Huguenin writes: > > > > 1. Proxy receives such a big SIP request that it can not pass it > > > to the UA via the persistent UDP flow > > > 2. Consequently the proxy will send ForceTCP message to the UA > > > 3. The UA will open a temporary TCP connection towards the proxy > > > 4. The UA will send a GetToken request to the proxy over the TCP > > > connection > > > 5. The proxy will respond GetToken with a new flow token assigned > > > to the TCP flow > > > 6. UA will store this new TCP flow token and associate it with the > > > UDP flow > > > 7. UA will respond to the ForceTCP message returning the flow token > > > of the TCP flow to the proxy > > > 8. Based on the response from the UA the proxy can now re-map the > > > big SIP request from UDP flow to the new TCP flow and forward > > > it to the UA > > you must be joking. looks like ietf folks are living in an extremely > complex surrealistic world. > > -- juha > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 12:32:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2svL-0005SO-91; Fri, 05 Jan 2007 12:32:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2svK-0005SJ-RD for sip@ietf.org; Fri, 05 Jan 2007 12:32:10 -0500 Received: from mailx.8x8.com ([192.84.19.237] helo=mailint.8x8.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2svH-0006Ij-ES for sip@ietf.org; Fri, 05 Jan 2007 12:32:10 -0500 Received: from mailint.8x8.com (localhost.localdomain [127.0.0.1]) by mailint.8x8.com (8.13.1/8.13.1) with ESMTP id l05HW5aU008772; Fri, 5 Jan 2007 09:32:05 -0800 Received: from mailint.8x8.com (root@localhost) by mailint.8x8.com (8.13.1/8.13.1/Submit) with ESMTP id l05HW3NC008771; Fri, 5 Jan 2007 09:32:05 -0800 Received: from [10.0.2.15] (godzilla.8x8.com 192.168.84.42) by mailint.8x8.com (Scalix SMTP Relay 10.0.1.3) via ESMTP; Fri, 05 Jan 2007 09:32:02 -0800 (PST) Date: Fri, 5 Jan 2007 18:31:57 +0100 From: Marc Petit-Huguenin To: "Frank W. Miller" Message-ID: <459E8B8D.10600@acm.org> In-Reply-To: <200701051714.l05HEFv01323@celine.siteprotect.com> References: <200701051714.l05HEFv01323@celine.siteprotect.com> Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 x-scalix-Hops: 1 User-Agent: Icedove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline X-Spam-Score: 1.1 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: sip@ietf.org, 'Juha Heinanen' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Frank W. Miller wrote: > Do you honestly think that there wouldn't be NAT if the world were > completely IPv6? NAT may have originally been put in place to alleviate the > IPv4 address exhaustion problem but separation of address spaces is more > useful than that, no matter how big the address spaces are. What about distributed firewall? http://www.cs.columbia.edu/~smb/papers/distfw.html > While I would > luv for the public Internet to be purely end-to-end wrt IP addresses, this > just is never going to happen again. I agree, but it is not a reason to not try to improve things. NAT, firewalls, load balancers, B2BUA and SBC are the cancer of Internet. > The early days of a few hundred VAXs > all happily talking to each other directly are long gone. The days of trust > are gone forever and NAT is just one reflection of that. > So, how do you solve the problem of using a SIP endpoint behind a NAT? a SIP endpoint been defined as running on UDP AND TCP. Because this is the problem here. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: marc@8x8.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 12:37:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2szx-0007Zz-Bj; Fri, 05 Jan 2007 12:36:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2szv-0007QT-67 for sip@ietf.org; Fri, 05 Jan 2007 12:36:55 -0500 Received: from mailout-1.omnitel.it ([194.20.77.121] helo=fmis437.omnitel.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2szt-0007Ua-KW for sip@ietf.org; Fri, 05 Jan 2007 12:36:55 -0500 Received: from omini93.omnitel.it (omini93.omnitel.it [10.21.18.145]) by fmis437.omnitel.it (Switch-3.2.5/Switch-3.2.5) with ESMTP id l05Haqau009980 for ; Fri, 5 Jan 2007 18:36:52 +0100 (MET) Received: from oivmexo01.omnitel.it ([10.31.32.12]) by ominc74.omnitel.it with Microsoft SMTPSVC(5.0.2195.6713); Fri, 5 Jan 2007 18:36:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 Date: Fri, 5 Jan 2007 18:36:24 +0100 Message-ID: <5371BE300539E6439919CF97203DDEC208B3D120@OIVMEXO01.omnitel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 Thread-Index: Accw5zsS1QJES15lSyOQ2mmWKi08UwABMsyAAACGygA= From: "STURA, Marco, VF-IT" To: "Frank W. Miller" , "Marc Petit-Huguenin" X-OriginalArrivalTime: 05 Jan 2007 17:36:51.0283 (UTC) FILETIME=[1568EA30:01C730F0] X-Spam-Score: 1.2 (+) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: sip@ietf.org, Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yes, but for that (if needed) ISPs would use sort of topology hiding = functions in the sip infrastructure not uncontrolled NAT boxes. Or, what = about distributed FWs? But anyway, this is an endless discussion as it was for the IPv6 and e2e = argument. I think the situation is what it is, and we need solutions. = However, if we could aim to a cleaner future that would help a lot. Marco=20 -----Original Message----- From: Frank W. Miller [mailto:fwmiller@cornfed.com]=20 Sent: venerd=EC 5 gennaio 2007 18.14 To: 'Marc Petit-Huguenin' Cc: sip@ietf.org; 'Juha Heinanen' Subject: RE: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 Do you honestly think that there wouldn't be NAT if the world were completely IPv6? NAT may have originally been put in place to alleviate = the IPv4 address exhaustion problem but separation of address spaces is more useful than that, no matter how big the address spaces are. While I = would luv for the public Internet to be purely end-to-end wrt IP addresses, = this just is never going to happen again. The early days of a few hundred = VAXs all happily talking to each other directly are long gone. The days of = trust are gone forever and NAT is just one reflection of that. FM -----Original Message----- From: Marc Petit-Huguenin [mailto:petithug@acm.org]=20 Sent: Friday, January 05, 2007 9:33 AM To: Frank W. Miller Cc: 'Juha Heinanen'; sip@ietf.org Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 Frank W. Miller wrote: >=20 > With all due respect to everyone, I would like to echo and amplify = this. > The entire direction of the SIP spec lately, outbound, ice, etc. have really > become overly complex. I think a concerted effort to take a step back = and > simplify things would benefit the entire community. "For every complex problem, there is a solution that is simple, neat, and wrong." H.L. Mencken (1880-1956) SIP didn't create the problem. The ISPs who didn't deploy IPv6, the vendors who sold NAT boxes and especially people who does not understand the end to end argument created the problem. >=20 > Thanks, > FM >=20 >=20 > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com]=20 > Sent: Friday, January 05, 2007 7:34 AM > To: Marc Petit-Huguenin > Cc: sip@ietf.org > Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 >=20 > Marc Petit-Huguenin writes: >=20 > > > 1. Proxy receives such a big SIP request that it can not pass it > > > to the UA via the persistent UDP flow > > > 2. Consequently the proxy will send ForceTCP message to the UA > > > 3. The UA will open a temporary TCP connection towards the proxy > > > 4. The UA will send a GetToken request to the proxy over the TCP > > > connection > > > 5. The proxy will respond GetToken with a new flow token assigned > > > to the TCP flow > > > 6. UA will store this new TCP flow token and associate it with = the > > > UDP flow > > > 7. UA will respond to the ForceTCP message returning the flow = token > > > of the TCP flow to the proxy > > > 8. Based on the response from the UA the proxy can now re-map the > > > big SIP request from UDP flow to the new TCP flow and forward > > > it to the UA >=20 > you must be joking. looks like ietf folks are living in an extremely > complex surrealistic world. >=20 > -- juha >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 12:52:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2tEI-0004U8-4x; Fri, 05 Jan 2007 12:51:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2tEF-0004U2-TV for sip@ietf.org; Fri, 05 Jan 2007 12:51:43 -0500 Received: from celine.siteprotect.com ([64.26.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2tEB-0002UK-Hm for sip@ietf.org; Fri, 05 Jan 2007 12:51:43 -0500 Received: from cornfed (c-24-9-79-73.hsd1.co.comcast.net [24.9.79.73]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id l05HpVv05078; Fri, 5 Jan 2007 11:51:31 -0600 Message-Id: <200701051751.l05HpVv05078@celine.siteprotect.com> From: "Frank W. Miller" To: "'Marc Petit-Huguenin'" Subject: RE: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 Date: Fri, 5 Jan 2007 10:50:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Accw75DrL+GqqD73TdWqM9YMZ34M9AAAG0Dg In-Reply-To: <459E8B8D.10600@acm.org> X-Spam-Score: 1.1 (+) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: sip@ietf.org, 'Juha Heinanen' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Well, you asked... There are two ways that I think are a lot simpler, one more radical than the other. First, the "less" radical approach. For SIP, just spec TCP for transport and have the UAs punch holes through the Firewall/NAT and keepalive them. This I think is sort of what Dean was eluding to in an earlier email. For media, ICE is a solution. But, it seems overly complex to me. Consider this article: http://www.heise-security.co.uk/articles/82481 When you see the address of the incoming media in the SDP, just punch a hole in the FW/NAT. Second, the "more" radical approach. If we really want to solve the NAT problem simply, we need to revisit the basic assumption that signaling and media are on different transport ports. We could use the basic idea in IAX2 of separate address space behind the transport port number. We've already breached the multiplexing of multiple protocols onto a single transport address. Why not do it right? Allow STUN, SIP, and RTP to all use the same transport address and use another address behind the port number to de/mux them. Here's the basic architecture of IAX2 for those that haven't seen it (http://www.ietf.org/internet-drafts/draft-guy-iax-02.txt): +-----------------+ +------------------+ | Stream | | Stream | | Number | | Number | | +-+ | | +-+ | | | |---+ | | +---| | | | +-+ \ | | / +-+ | | +-+ \ Port | +---------+ | Port / +-+ | | | |---+ \+-+ | | IP | | +-+/ +---| | | | +-+ \_ | |<------>| Network |<------>| | _/ +-+ | | ... _ +-+ | +---------+ | +-+ _ ... | | +-+ / | | \ +-+ | | | |---+ | | +---| | | | +-+ | | +-+ | +-----------------+ +------------------+ Host 1 Host 2 Something completely different. Like I said before, I would prefer the separation of signaling and media on separate ports but the NAT problem in my opinion, along with the close relationship between signaling and media streams, makes it untenable. FM -----Original Message----- From: Marc Petit-Huguenin [mailto:petithug@acm.org] Sent: Friday, January 05, 2007 10:32 AM To: Frank W. Miller Cc: sip@ietf.org; 'Juha Heinanen' Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 Frank W. Miller wrote: > Do you honestly think that there wouldn't be NAT if the world were > completely IPv6? NAT may have originally been put in place to alleviate the > IPv4 address exhaustion problem but separation of address spaces is more > useful than that, no matter how big the address spaces are. What about distributed firewall? http://www.cs.columbia.edu/~smb/papers/distfw.html > While I would > luv for the public Internet to be purely end-to-end wrt IP addresses, this > just is never going to happen again. I agree, but it is not a reason to not try to improve things. NAT, firewalls, load balancers, B2BUA and SBC are the cancer of Internet. > The early days of a few hundred VAXs > all happily talking to each other directly are long gone. The days of trust > are gone forever and NAT is just one reflection of that. > So, how do you solve the problem of using a SIP endpoint behind a NAT? a SIP endpoint been defined as running on UDP AND TCP. Because this is the problem here. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: marc@8x8.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 15:42:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2vsE-0000k2-Ll; Fri, 05 Jan 2007 15:41:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2vsD-0000j4-9u for sip@ietf.org; Fri, 05 Jan 2007 15:41:09 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2vrp-0005qc-N5 for sip@ietf.org; Fri, 05 Jan 2007 15:40:47 -0500 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 7B2E6AC2C0; Fri, 5 Jan 2007 22:40:40 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17822.47048.451043.121968@harjus.tutpro.com> Date: Fri, 5 Jan 2007 22:40:40 +0200 To: Marc Petit-Huguenin Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 In-Reply-To: <459E8B8D.10600@acm.org> References: <200701051714.l05HEFv01323@celine.siteprotect.com> <459E8B8D.10600@acm.org> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 1.1 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: sip@ietf.org, "Frank W. Miller" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Marc Petit-Huguenin writes: > So, how do you solve the problem of using a SIP endpoint behind a NAT? a > SIP endpoint been defined as running on UDP AND TCP. Because this is > the problem here. it has already been solved in practise. see see/openser documentation for proxy operation and, for example, nokia SIP UA for TCP UA operation. there is no need to standardize anything for nat traversal. there would have been need to standardize UA behavior for load balanced resilient operation, but that was excluded from outbound. now there is nothing left worth writing an outbound rfc. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 18:19:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2yKU-0000PD-Br; Fri, 05 Jan 2007 18:18:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2yKS-0000P8-Vv for sip@ietf.org; Fri, 05 Jan 2007 18:18:28 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2yKR-0006im-Lh for sip@ietf.org; Fri, 05 Jan 2007 18:18:28 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 05 Jan 2007 15:18:26 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l05NIQGW003841; Fri, 5 Jan 2007 15:18:26 -0800 Received: from [192.168.4.2] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l05NILIm012968; Fri, 5 Jan 2007 15:18:25 -0800 (PST) In-Reply-To: <953beacc0701041711y61188681i67550e9f2f922f3b@mail.gmail.com> References: <91E4CFBC-9DA7-40F5-B757-62E0352708C4@cisco.com> <953beacc0701041711y61188681i67550e9f2f922f3b@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Fri, 5 Jan 2007 15:18:12 -0800 To: Rohan Mahy X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2074; t=1168039106; x=1168903106; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20Question=20about=20Poll=3A=20Proposal=20relat ing=20to=20keepalive, =20TCP, =20and=20UDP=20usage=20in=20draft-ietf-sip-out bound |Sender:=20; bh=tU8xngid+66PRlN1YnD6fO/z4XemyHegnijj7QcJHpw=; b=MbgqrJaHeXxi8Zzc9y94mCk6sQd/P/ZlMfja5ZWESpw7aUmuMYgtIBjTAKMahOLZ/H+Q7sKS 58C7pbzBwRGJeuNw3Icx9et3ka5m3nXNK76ayzetaiuFVwMp9noDpE2e; Authentication-Results: sj-dkim-6; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This was why I wanted to concentrate on the high level goals. It seems that most people agree with 1 and 2 and I may have stated 3 poorly but I get the idea that if 3 is something large and complex with long delay people don't want to wait for it and if 3 simply means that you can multiregister with two protocols people have no objections to it and see benefits for some cases. On Jan 4, 2007, at 5:11 PM, Rohan Mahy wrote: > Hi, > > I don't see value in goal #3. I believe my proposal covers your goals > #1 and #2 (with #2 corrected to talk about receiving large packets as > corrected by Francois). > > Perhaps you are having an allergic reaction to some of the specific > wording I proposed rather than the goal or effect of that text. If > so, lets try to hammer out some mutually agreeable alternate text. > > thanks, > -rohan > > On 12/30/06, Cullen Jennings wrote: >> >> If the people who have been expressing strong opinions on the details >> of this proposal could comment on if they agree with these high level >> goals or not, it would be really helpful for trying to get this draft >> to move forward. >> >> On Dec 16, 2006, at 12:33 PM, Cullen Jennings wrote: >> >> > Practically speaking given where we are today, I would be a fan of >> > a solution that meant the following goals: >> > >> > 1) allowed deployments that wanted to use TCP to use TCP >> > >> > 2) allowed deployments that wanted to use UDP to use only UDP with >> > the known limitations that the UA would not be able to send large >> > requests >> > >> > 3) allowed deployments that wanted to use both UDP and TCP to do so >> > and not have the size limitations by using switchover >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 05 18:34:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2yaC-0008R2-Ng; Fri, 05 Jan 2007 18:34:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2yaB-0008QZ-BA for sip@ietf.org; Fri, 05 Jan 2007 18:34:43 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2yaA-0004An-1Q for sip@ietf.org; Fri, 05 Jan 2007 18:34:43 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 05 Jan 2007 15:34:41 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l05NYfqd009272; Fri, 5 Jan 2007 15:34:41 -0800 Received: from [192.168.4.2] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l05NYLlc019164; Fri, 5 Jan 2007 15:34:26 -0800 (PST) In-Reply-To: <17821.60560.400209.135681@harjus.tutpro.com> References: <458F1308.2070601@softarmor.com> <6FC4416DDE56C44DA0AEE67BC7CA43711213EA6F@zrc2hxm2.corp.nortel.com> <17819.64168.559864.751052@harjus.tutpro.com> <5F813F72-62E8-48C2-9130-68B39F71CDBE@cisco.com> <17821.60560.400209.135681@harjus.tutpro.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4DC7F4F8-68BF-4F96-A145-66AF6BEA60A1@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Fri, 5 Jan 2007 15:34:13 -0800 To: Juha Heinanen X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2393; t=1168040081; x=1168904081; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20Question=20about=20Poll=3A=20Proposal=20relat ing=20to=20keepalive, =20TCP, =20and=20UDP=20usage=20in=20draft-ietf-sip-out bound |Sender:=20; bh=6KmJHYGJWIuS6Oav9TTVsJvcZiZ8AuD94w2XX8LZRms=; b=AVH1/PTgWAv8bL3JxBOn/sGeMkFhGApTI1I5GH1WJsTnHE0GoCudZiLBrqV78jOe710LkXzO F69qWq0A02H8O45YphaisX5JqQWV9HsqYstOY9Ugj/yd0VqyLTU3x+8f; Authentication-Results: sj-dkim-7; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: SIP , Francois Audet , Dean Willis , Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jan 4, 2007, at 10:13 PM, Juha Heinanen wrote: > Cullen Jennings writes: > >> I don't. The problem is not that UAs don't support TCP. > > how can you from cisco say that the problem is not that UAs don't > support TCP, when UAs from cisco and its affiliates don't support TCP? Cisco has many UAs that support TCP though you are right that not 100% of them do. Trust, me there are lots of things I wish Cisco SIP stuff did that it does not yet do but that is partially the time lag between standards and implementations and a little bit the nature of some of the specifications IETF writes do not seem to be particularly wanted by customers. (Insert S/MIME joke here :-) > >> The problems is that proxies don't support TCP on a large scale. > > which popular proxies don't support TCP in large scale? give me some > names. if there are some, i'm sure their vendors must fix them, > because > otherwise they would be out of business. > > -- juha I has asked many times for a commercially available proxy that did over 100k TCP connections and high reliability (I include open source stuff as commercially available since a customer can use it). I have yet to receive a reply to that request. People have said it is possible to build them, and I believe those people, I'm just pointing out that if someone doing a vonage like service today does not seem to have many choices about if they are going to use UDP or not. Over time, I'm suspect that will change and I think it is critical that outbound does provide a TCP solution but I think it is also important that it provide a UDP solution for the people that want to use that today. When you connect a counterpath or snom softphone behind a NAT to SER over TCP and incoming calls work, that is because they doing some of what outbound specifies. Something that strictly followed the existing RFC would try and form a new TCP connection and fail. I think it is important to get this finished and out there so more things can follow it and work too. I don't think there are long existing mechanisms that work and are optimal. Several proprietary solutions have been done and non optimal things like registering every 15 seconds have been done but clearly a standards based approach with a more optimal solution seems like a good idea. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jan 06 02:29:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H35yQ-0002jk-15; Sat, 06 Jan 2007 02:28:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H35yO-0002je-Qx for sip@ietf.org; Sat, 06 Jan 2007 02:28:12 -0500 Received: from mailx.8x8.com ([192.84.19.237] helo=mailint.8x8.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H35yN-0002Im-Bu for sip@ietf.org; Sat, 06 Jan 2007 02:28:12 -0500 Received: from mailint.8x8.com (localhost.localdomain [127.0.0.1]) by mailint.8x8.com (8.13.1/8.13.1) with ESMTP id l067RujJ018903; Fri, 5 Jan 2007 23:27:56 -0800 Received: from mailint.8x8.com (root@localhost) by mailint.8x8.com (8.13.1/8.13.1/Submit) with ESMTP id l067RhtX018887; Fri, 5 Jan 2007 23:27:47 -0800 Received: from [10.0.2.15] (godzilla.8x8.com 192.168.84.42) by mailint.8x8.com (Scalix SMTP Relay 10.0.1.3) via ESMTP; Fri, 05 Jan 2007 23:27:42 -0800 (PST) Date: Sat, 6 Jan 2007 08:27:38 +0100 From: Marc Petit-Huguenin To: "Frank W. Miller" Message-ID: <459F4F6A.8020405@acm.org> In-Reply-To: <200701051751.l05HpVv05078@celine.siteprotect.com> References: <200701051751.l05HpVv05078@celine.siteprotect.com> Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 x-scalix-Hops: 1 User-Agent: Icedove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline X-Spam-Score: 1.1 (+) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: sip@ietf.org, 'Juha Heinanen' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Frank W. Miller wrote: > Well, you asked... > > There are two ways that I think are a lot simpler, one more radical than the > other. > > First, the "less" radical approach. > > For SIP, just spec TCP for transport and have the UAs punch holes through > the Firewall/NAT and keepalive them. This I think is sort of what Dean was > eluding to in an earlier email. Ah, but you do not answer the question: "[H]ow do you solve the problem of using a SIP endpoint behind a NAT? a SIP endpoint been defined as running on UDP AND TCP." Basically what you are saying (with the other UDP-haters in this list) is that the UDP problem is too complex, so let's just remove UDP from the list of transports supported by SIP. As this is the I *E* T F, I was hoping for more enthusiasm to solve problems, instead of sweeping them under the rug. > > For media, ICE is a solution. But, it seems overly complex to me. ICE is a brilliant and complex solution to complex problems. But the problems solved by ICE goes beyond just NAT traversal. It also offers a strategy for IPv4 to IPv6 migration, a way to create direct connection for two UA behind the same NAT and a nice solution for multihomed UA. > Consider > this article: > > http://www.heise-security.co.uk/articles/82481 Yes, it is extremely funny to see sysadmins discovering STUN more than five years after the publication of the first draft. BTW sysadmins also break the end to end argument. Think about that. > > When you see the address of the incoming media in the SDP, just punch a hole > in the FW/NAT. > > Second, the "more" radical approach. > > If we really want to solve the NAT problem simply, we need to revisit the > basic assumption that signaling and media are on different transport ports. > We could use the basic idea in IAX2 of separate address space behind the > transport port number. We've already breached the multiplexing of multiple > protocols onto a single transport address. Why not do it right? Allow > STUN, SIP, and RTP to all use the same transport address and use another > address behind the port number to de/mux them. > > Here's the basic architecture of IAX2 for those that haven't seen it > (http://www.ietf.org/internet-drafts/draft-guy-iax-02.txt): > > +-----------------+ +------------------+ > | Stream | | Stream | > | Number | | Number | > | +-+ | | +-+ | > | | |---+ | | +---| | | > | +-+ \ | | / +-+ | > | +-+ \ Port | +---------+ | Port / +-+ | > | | |---+ \+-+ | | IP | | +-+/ +---| | | > | +-+ \_ | |<------>| Network |<------>| | _/ +-+ | > | ... _ +-+ | +---------+ | +-+ _ ... | > | +-+ / | | \ +-+ | > | | |---+ | | +---| | | > | +-+ | | +-+ | > +-----------------+ +------------------+ > Host 1 Host 2 > > > Something completely different. Like I said before, I would prefer the > separation of signaling and media on separate ports but the NAT problem in > my opinion, along with the close relationship between signaling and media > streams, makes it untenable. > > FM > > > -----Original Message----- > From: Marc Petit-Huguenin [mailto:petithug@acm.org] > Sent: Friday, January 05, 2007 10:32 AM > To: Frank W. Miller > Cc: sip@ietf.org; 'Juha Heinanen' > Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 > > Frank W. Miller wrote: >> Do you honestly think that there wouldn't be NAT if the world were >> completely IPv6? NAT may have originally been put in place to alleviate > the >> IPv4 address exhaustion problem but separation of address spaces is more >> useful than that, no matter how big the address spaces are. > > What about distributed firewall? > > http://www.cs.columbia.edu/~smb/papers/distfw.html > >> While I would >> luv for the public Internet to be purely end-to-end wrt IP addresses, this >> just is never going to happen again. > > I agree, but it is not a reason to not try to improve things. NAT, > firewalls, load balancers, B2BUA and SBC are the cancer of Internet. > >> The early days of a few hundred VAXs >> all happily talking to each other directly are long gone. The days of > trust >> are gone forever and NAT is just one reflection of that. >> > > So, how do you solve the problem of using a SIP endpoint behind a NAT? a > SIP endpoint been defined as running on UDP AND TCP. Because this is > the problem here. > -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: marc@8x8.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jan 06 03:37:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H372l-0003Lf-23; Sat, 06 Jan 2007 03:36:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H372j-0003LT-KP for sip@ietf.org; Sat, 06 Jan 2007 03:36:45 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H372i-0000aG-9Z for sip@ietf.org; Sat, 06 Jan 2007 03:36:45 -0500 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 6E2F5AC2C0; Sat, 6 Jan 2007 10:36:38 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17823.24470.324705.515983@harjus.tutpro.com> Date: Sat, 6 Jan 2007 10:36:38 +0200 To: Cullen Jennings Subject: Re: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound In-Reply-To: <4DC7F4F8-68BF-4F96-A145-66AF6BEA60A1@cisco.com> References: <458F1308.2070601@softarmor.com> <6FC4416DDE56C44DA0AEE67BC7CA43711213EA6F@zrc2hxm2.corp.nortel.com> <17819.64168.559864.751052@harjus.tutpro.com> <5F813F72-62E8-48C2-9130-68B39F71CDBE@cisco.com> <17821.60560.400209.135681@harjus.tutpro.com> <4DC7F4F8-68BF-4F96-A145-66AF6BEA60A1@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: SIP , Francois Audet , Dean Willis , Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen Jennings writes: > When you connect a counterpath or snom softphone behind a NAT to SER > over TCP and incoming calls work, that is because they doing some of > what outbound specifies. Something that strictly followed the > existing RFC would try and form a new TCP connection and fail. I > think it is important to get this finished and out there so more > things can follow it and work too. I don't think there are long > existing mechanisms that work and are optimal. Several proprietary > solutions have been done and non optimal things like registering > every 15 seconds have been done but clearly a standards based > approach with a more optimal solution seems like a good idea. you simply write a one paragraph best practise rfc that says that in case of tcp, it is good idea to use between ua and proxy a persistent tcp connection that is refreshed every X minutes using crnl or tcp keepalive. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jan 06 06:01:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H39H6-0003yI-V5; Sat, 06 Jan 2007 05:59:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H39H5-0003yB-Eb for sip@ietf.org; Sat, 06 Jan 2007 05:59:43 -0500 Received: from mailx.8x8.com ([192.84.19.237] helo=mailint.8x8.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H39H4-0005J1-3m for sip@ietf.org; Sat, 06 Jan 2007 05:59:43 -0500 Received: from mailint.8x8.com (localhost.localdomain [127.0.0.1]) by mailint.8x8.com (8.13.1/8.13.1) with ESMTP id l06AxSvQ031854; Sat, 6 Jan 2007 02:59:28 -0800 Received: from mailint.8x8.com (root@localhost) by mailint.8x8.com (8.13.1/8.13.1/Submit) with ESMTP id l06AxPMw031852; Sat, 6 Jan 2007 02:59:25 -0800 Received: from [10.0.2.15] (godzilla.8x8.com 192.168.84.42) by mailint.8x8.com (Scalix SMTP Relay 10.0.1.3) via ESMTP; Sat, 06 Jan 2007 02:59:24 -0800 (PST) Date: Sat, 6 Jan 2007 11:59:19 +0100 From: Marc Petit-Huguenin To: Juha Heinanen Message-ID: <459F8107.7060809@acm.org> In-Reply-To: <17823.24470.324705.515983@harjus.tutpro.com> References: <458F1308.2070601@softarmor.com> References: <6FC4416DDE56C44DA0AEE67BC7CA43711213EA6F@zrc2hxm2.corp.nortel.com> References: <17819.64168.559864.751052@harjus.tutpro.com> References: <5F813F72-62E8-48C2-9130-68B39F71CDBE@cisco.com> References: <17821.60560.400209.135681@harjus.tutpro.com> References: <4DC7F4F8-68BF-4F96-A145-66AF6BEA60A1@cisco.com> References: <17823.24470.324705.515983@harjus.tutpro.com> Subject: Re: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound x-scalix-Hops: 1 User-Agent: Icedove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Cullen Jennings , SIP , Francois Audet , Brian Stucker , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Juha Heinanen wrote: > Cullen Jennings writes: > > > When you connect a counterpath or snom softphone behind a NAT to SER > > over TCP and incoming calls work, that is because they doing some of > > what outbound specifies. Something that strictly followed the > > existing RFC would try and form a new TCP connection and fail. I > > think it is important to get this finished and out there so more > > things can follow it and work too. I don't think there are long > > existing mechanisms that work and are optimal. Several proprietary > > solutions have been done and non optimal things like registering > > every 15 seconds have been done but clearly a standards based > > approach with a more optimal solution seems like a good idea. > > you simply write a one paragraph best practise rfc that says that in > case of tcp, it is good idea to use between ua and proxy a persistent > tcp connection that is refreshed every X minutes using crnl or tcp > keepalive. Not sure that an UA that cannot receive initial SIP requests would be very useful. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: marc@8x8.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jan 06 11:38:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3EX3-0005BN-48; Sat, 06 Jan 2007 11:36:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3EX2-0005BI-CM for sip@ietf.org; Sat, 06 Jan 2007 11:36:32 -0500 Received: from celine.siteprotect.com ([64.26.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3EX1-0008WH-0Y for sip@ietf.org; Sat, 06 Jan 2007 11:36:32 -0500 Received: from cornfed (c-24-9-79-73.hsd1.co.comcast.net [24.9.79.73]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id l06GaER12161; Sat, 6 Jan 2007 10:36:15 -0600 Message-Id: <200701061636.l06GaER12161@celine.siteprotect.com> From: "Frank W. Miller" To: "'Marc Petit-Huguenin'" Subject: RE: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 Date: Sat, 6 Jan 2007 09:35:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <459F4F6A.8020405@acm.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: AccxZLU1riL9YOttSHem8jnNl9hctwASruKA X-Spam-Score: 1.1 (+) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: sip@ietf.org, 'Juha Heinanen' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org -----Original Message----- From: Marc Petit-Huguenin [mailto:petithug@acm.org] Sent: Saturday, January 06, 2007 12:28 AM To: Frank W. Miller Cc: sip@ietf.org; 'Juha Heinanen' Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 Frank W. Miller wrote: > Well, you asked... > > There are two ways that I think are a lot simpler, one more radical than the > other. > > First, the "less" radical approach. > > For SIP, just spec TCP for transport and have the UAs punch holes through > the Firewall/NAT and keepalive them. This I think is sort of what Dean was > eluding to in an earlier email. Ah, but you do not answer the question: "[H]ow do you solve the problem of using a SIP endpoint behind a NAT? a SIP endpoint been defined as running on UDP AND TCP." Basically what you are saying (with the other UDP-haters in this list) is that the UDP problem is too complex, so let's just remove UDP from the list of transports supported by SIP. As this is the I *E* T F, I was hoping for more enthusiasm to solve problems, instead of sweeping them under the rug. FM: Hole punching will work for UDP and TCP both. FM: I'm not a UDP hater but I do think that TCP is the proper transport protocol that fits this application. I also think that if you have TCP, UDP is probably unnecessary. I would advocate the dropping of UDP in a "version 3.0" of SIP but not for -outbound. There is too much installed base that uses UDP (including my stuff!). > > For media, ICE is a solution. But, it seems overly complex to me. ICE is a brilliant and complex solution to complex problems. But the problems solved by ICE goes beyond just NAT traversal. It also offers a strategy for IPv4 to IPv6 migration, a way to create direct connection for two UA behind the same NAT and a nice solution for multihomed UA. FM: What does ICE do for IPv6 transistion that hole punching does not? FM: Two UAs behind the same NAT should not have to traverse the NAT. They should be smart enough to figure that out. I don't think there's anything wrt "IPv4 to IPv6 transition" (whatever that means) that would not be possible with hole punching. > Consider > this article: > > http://www.heise-security.co.uk/articles/82481 Yes, it is extremely funny to see sysadmins discovering STUN more than five years after the publication of the first draft. BTW sysadmins also break the end to end argument. Think about that. FM: The article talks about hole punching, which is more than STUN. In SIP, you would get your visible IP address, put that into the SDP and when the other UA gets it, they punch a hole in their FW/NAT based on the address you sent them to allow incoming media to flow. FM: No comment on the more radical approach I guess... ;) FM _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jan 06 13:06:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3Fv3-0002Sj-Az; Sat, 06 Jan 2007 13:05:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3Fv1-0002Sd-Lb for sip@ietf.org; Sat, 06 Jan 2007 13:05:23 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3Fuo-00087A-7Y for sip@ietf.org; Sat, 06 Jan 2007 13:05:23 -0500 Received: by harjus.tutpro.com (Postfix, from userid 1000) id F2439AC2C0; Sat, 6 Jan 2007 20:05:04 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17823.58576.926896.687135@harjus.tutpro.com> Date: Sat, 6 Jan 2007 20:05:04 +0200 To: Marc Petit-Huguenin Subject: Re: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound In-Reply-To: <459F8107.7060809@acm.org> References: <458F1308.2070601@softarmor.com> <6FC4416DDE56C44DA0AEE67BC7CA43711213EA6F@zrc2hxm2.corp.nortel.com> <17819.64168.559864.751052@harjus.tutpro.com> <5F813F72-62E8-48C2-9130-68B39F71CDBE@cisco.com> <17821.60560.400209.135681@harjus.tutpro.com> <4DC7F4F8-68BF-4F96-A145-66AF6BEA60A1@cisco.com> <17823.24470.324705.515983@harjus.tutpro.com> <459F8107.7060809@acm.org> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Cullen Jennings , SIP , Francois Audet , Brian Stucker , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Marc Petit-Huguenin writes: > Not sure that an UA that cannot receive initial SIP requests would be > very useful. are you saying that UA implementors are so brain damaged that they cannot figure out to initiate a tcp connection without being told so by ietf? -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jan 06 13:46:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3GY8-0008RY-5D; Sat, 06 Jan 2007 13:45:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3GY7-0008RT-2U for sip@ietf.org; Sat, 06 Jan 2007 13:45:47 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3GY5-0006B0-Iq for sip@ietf.org; Sat, 06 Jan 2007 13:45:47 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 06 Jan 2007 10:45:45 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l06IjiHf031925; Sat, 6 Jan 2007 10:45:44 -0800 Received: from [192.168.4.2] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l06IjWIm005427; Sat, 6 Jan 2007 10:45:32 -0800 (PST) In-Reply-To: <17823.58576.926896.687135@harjus.tutpro.com> References: <458F1308.2070601@softarmor.com> <6FC4416DDE56C44DA0AEE67BC7CA43711213EA6F@zrc2hxm2.corp.nortel.com> <17819.64168.559864.751052@harjus.tutpro.com> <5F813F72-62E8-48C2-9130-68B39F71CDBE@cisco.com> <17821.60560.400209.135681@harjus.tutpro.com> <4DC7F4F8-68BF-4F96-A145-66AF6BEA60A1@cisco.com> <17823.24470.324705.515983@harjus.tutpro.com> <459F8107.7060809@acm.org> <17823.58576.926896.687135@harjus.tutpro.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <62A97DE1-622F-429C-A1ED-626BC1F65C78@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Sat, 6 Jan 2007 10:45:24 -0800 To: Juha Heinanen X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1432; t=1168109144; x=1168973144; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20Question=20about=20Poll=3A=20Proposal=20relat ing=20to=20keepalive, =20TCP, =20and=20UDP=20usage=20in=20draft-ietf-sip-out bound |Sender:=20; bh=/wfhyqJunjLlxK8y+skMzbfKALcMU5CQOKumK3ZAaNM=; b=XMnGI6Gx490AJcspK8N3nkQRA2zVIqXebWapInq57TYiAqKeypiegZ9O7cJH9+AyJqi8+enT ptm9KNlEFmhUt3Wm5YXm3rAU6Ueyb41l55QT0L15aNidq9zzSKCe82jF; Authentication-Results: sj-dkim-5; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: SIP , Marc Petit-Huguenin , Francois Audet , Brian Stucker , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jan 6, 2007, at 10:05 AM, Juha Heinanen wrote: > Marc Petit-Huguenin writes: > >> Not sure that an UA that cannot receive initial SIP requests would be >> very useful. > > are you saying that UA implementors are so brain damaged that they > cannot figure out to initiate a tcp connection without being told > so by > ietf? > > -- juha A large percentage of the TCP implementations observed at SIPIT formed a new TCP connection for every transaction and take down the connection at the end of the transaction - some, I kid you not, closed the TCP connection after sending the request but before receiving the response. Now in fairness, most of these were, ah, implementations that had lots of other parts that needed improvement and not implementations that had been to lots of sipits and seen lots of testing but it did open my eye. The people that have these implementations always point out that they seem to be following the spec. I don't think the specs have to be an full implementers guide so I'm not sure that this little story has much bearing on what we should be doing in the specs other than realize that people do implement some things that seem a little wacky at times. No matter what we say in the RFCs, there will always be people who manage not to understand them but it would be nice if the bulk of the people understood what they needed to do. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jan 06 14:22:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3H6V-0003aO-Ix; Sat, 06 Jan 2007 14:21:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3H6T-0003aI-IQ for sip@ietf.org; Sat, 06 Jan 2007 14:21:17 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3H6S-0003ED-79 for sip@ietf.org; Sat, 06 Jan 2007 14:21:17 -0500 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 0E925AC2C1; Sat, 6 Jan 2007 21:21:11 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17823.63143.2955.529777@harjus.tutpro.com> Date: Sat, 6 Jan 2007 21:21:11 +0200 To: Cullen Jennings Subject: Re: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound In-Reply-To: <62A97DE1-622F-429C-A1ED-626BC1F65C78@cisco.com> References: <458F1308.2070601@softarmor.com> <6FC4416DDE56C44DA0AEE67BC7CA43711213EA6F@zrc2hxm2.corp.nortel.com> <17819.64168.559864.751052@harjus.tutpro.com> <5F813F72-62E8-48C2-9130-68B39F71CDBE@cisco.com> <17821.60560.400209.135681@harjus.tutpro.com> <4DC7F4F8-68BF-4F96-A145-66AF6BEA60A1@cisco.com> <17823.24470.324705.515983@harjus.tutpro.com> <459F8107.7060809@acm.org> <17823.58576.926896.687135@harjus.tutpro.com> <62A97DE1-622F-429C-A1ED-626BC1F65C78@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: SIP , Marc Petit-Huguenin , Francois Audet , Brian Stucker , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen Jennings writes: > No matter what we say in the RFCs, there will > always be people who manage not to understand them but it would be > nice if the bulk of the people understood what they needed to do. i agree that many implementors don't care about rfcs. just an example from this very week: we noticed that a popular sip phone vendor didn't implement g726 as specified in rfc3551. the vendor did two mistakes: payload type was 2 and media packing was wrong. when i complained about it, vendor replied that they don't care about the rfc, but rather follow cisco, who also has wrong implementation of g726. comforting was they would consider fixing their implementation if i would order 20,000 phones from them. coming back to tcp, if implementors don't think before they start coding, ietf can produce a best practise document saying that it is a good idea to initiate tcp connections and keep them open. it is a pure implementation issue, not a protocol one. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jan 06 14:45:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3HT9-0003An-9J; Sat, 06 Jan 2007 14:44:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3HT7-0003Ah-V9 for sip@ietf.org; Sat, 06 Jan 2007 14:44:41 -0500 Received: from celine.siteprotect.com ([64.26.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3HT5-000696-Ie for sip@ietf.org; Sat, 06 Jan 2007 14:44:41 -0500 Received: from cornfed (c-24-9-79-73.hsd1.co.comcast.net [24.9.79.73]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id l06JiO803294; Sat, 6 Jan 2007 13:44:24 -0600 Message-Id: <200701061944.l06JiO803294@celine.siteprotect.com> From: "Frank W. Miller" To: "'Cullen Jennings'" , "'Juha Heinanen'" Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Sat, 6 Jan 2007 12:43:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <62A97DE1-622F-429C-A1ED-626BC1F65C78@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: AccxwwqgQHi18Y+uQwqCw09Q/9PmQgAB4lHw X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: 'SIP' , 'Marc Petit-Huguenin' , 'Francois Audet' , 'Dean Willis' , 'Brian Stucker' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I suppose this question would be more appropriate for the sip-implementors list, but, as someone who's about to add TCP to their implementation... I was going to keep the connection alive during the course of a dialog for sessions and subscriptions and for transactions for other things. Do any of you have any comment on your practical experiences with how best to maintain the life of TCP connections? Thanks, FM -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Saturday, January 06, 2007 11:45 AM To: Juha Heinanen Cc: SIP; Marc Petit-Huguenin; Francois Audet; Brian Stucker; Dean Willis Subject: Re: [Sip] Question about Poll: Proposal relating to keepalive, TCP,and UDP usage in draft-ietf-sip-outbound On Jan 6, 2007, at 10:05 AM, Juha Heinanen wrote: > Marc Petit-Huguenin writes: > >> Not sure that an UA that cannot receive initial SIP requests would be >> very useful. > > are you saying that UA implementors are so brain damaged that they > cannot figure out to initiate a tcp connection without being told > so by > ietf? > > -- juha A large percentage of the TCP implementations observed at SIPIT formed a new TCP connection for every transaction and take down the connection at the end of the transaction - some, I kid you not, closed the TCP connection after sending the request but before receiving the response. Now in fairness, most of these were, ah, implementations that had lots of other parts that needed improvement and not implementations that had been to lots of sipits and seen lots of testing but it did open my eye. The people that have these implementations always point out that they seem to be following the spec. I don't think the specs have to be an full implementers guide so I'm not sure that this little story has much bearing on what we should be doing in the specs other than realize that people do implement some things that seem a little wacky at times. No matter what we say in the RFCs, there will always be people who manage not to understand them but it would be nice if the bulk of the people understood what they needed to do. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jan 06 15:10:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3Hqp-0003EF-0N; Sat, 06 Jan 2007 15:09:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3Hqn-0003EA-Dr for sip@ietf.org; Sat, 06 Jan 2007 15:09:09 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3Hqm-0001xc-42 for sip@ietf.org; Sat, 06 Jan 2007 15:09:09 -0500 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 57570AC2C1; Sat, 6 Jan 2007 22:09:07 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17824.483.305092.436535@harjus.tutpro.com> Date: Sat, 6 Jan 2007 22:09:07 +0200 To: "Frank W. Miller" Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound In-Reply-To: <200701061944.l06JiO803294@celine.siteprotect.com> References: <62A97DE1-622F-429C-A1ED-626BC1F65C78@cisco.com> <200701061944.l06JiO803294@celine.siteprotect.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: 'Cullen Jennings' , 'Marc Petit-Huguenin' , 'SIP' , 'Francois Audet' , 'Brian Stucker' , 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Frank W. Miller writes: > Do any of > you have any comment on your practical experiences with how best to maintain > the life of TCP connections? sending crnl every ten minutes or so works fine. if your tcp stack has tcp keepalive support, you could try to use that although i don't have practical experience about it. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jan 07 02:40:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3Sc7-0001bm-25; Sun, 07 Jan 2007 02:38:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3Sc5-0001bh-99 for sip@ietf.org; Sun, 07 Jan 2007 02:38:41 -0500 Received: from wx-out-0506.google.com ([66.249.82.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3Sc3-0008FE-2O for sip@ietf.org; Sun, 07 Jan 2007 02:38:41 -0500 Received: by wx-out-0506.google.com with SMTP id h27so7369652wxd for ; Sat, 06 Jan 2007 23:38:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=crsUXUU3CobsI6ImfiAx4zpIDndk+3+pSo5ymbJVNWJbhB2pB0w1hvQKNNDXAlFb5f5DIcPtErPViY44qdYiY74NO3eI3K0QiKubSqMGgXThopxDJFVszPIEqar758DUl9mTIH9kQzvHtYrfQmhw0bpc9c3XvQFP75ZDe5jTZeQ= Received: by 10.90.73.3 with SMTP id v3mr1481902aga.1168155518916; Sat, 06 Jan 2007 23:38:38 -0800 (PST) Received: by 10.90.115.19 with HTTP; Sat, 6 Jan 2007 23:38:38 -0800 (PST) Message-ID: Date: Sun, 7 Jan 2007 08:38:38 +0100 From: "Alan Bergmin" To: "Marc Petit-Hughenin" Subject: Re: [Sip] I-D: Preventing Fragmentation for Client Initiated Connections in the Session Initiation Protocol (SIP) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > The TCP connections are temporary, not permanent. > > I think that we can compare this to a HTTP server. Even if I am > constantly logged in slashdot.org, there is no permanent TCP connection > between my browser and slashdot.org's HTTP server. This is because it > is more efficient to close the connection at the end of the transaction, > and to open a new one when I click on reload. Looking at most of exising web sites, I agree most of TCP connections are temporary (ie: limited to the life of the HTTP transaction). However for "dynamic" web sites like Gmail, there is a permanent TCP connection reused for many HTTP transactions. > So there is 3 possible combinations of transports for SIP; UDP alone, > permanent TCP and UDP + temporary TCP. As SIP is definitely closer to "dynamic web sites", I would rather limit TCP cases to the "permanent TCP" case only and remove the "UDP + temporary TCP" case. Alan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jan 07 02:43:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3Sgg-00038Y-Dj; Sun, 07 Jan 2007 02:43:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3Sgf-00038T-8n for sip@ietf.org; Sun, 07 Jan 2007 02:43:25 -0500 Received: from mailx.8x8.com ([192.84.19.237] helo=mailint.8x8.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3Sgd-0001BE-TS for sip@ietf.org; Sun, 07 Jan 2007 02:43:25 -0500 Received: from mailint.8x8.com (localhost.localdomain [127.0.0.1]) by mailint.8x8.com (8.13.1/8.13.1) with ESMTP id l077hBkh031800; Sat, 6 Jan 2007 23:43:11 -0800 Received: from mailint.8x8.com (root@localhost) by mailint.8x8.com (8.13.1/8.13.1/Submit) with ESMTP id l077h4Cd031798; Sat, 6 Jan 2007 23:43:10 -0800 Received: from [10.0.2.15] (godzilla.8x8.com 192.168.84.42) by mailint.8x8.com (Scalix SMTP Relay 10.0.1.3) via ESMTP; Sat, 06 Jan 2007 23:43:03 -0800 (PST) Date: Sun, 7 Jan 2007 08:42:59 +0100 From: Marc Petit-Huguenin To: "Frank W. Miller" Message-ID: <45A0A483.7020900@acm.org> In-Reply-To: <200701061636.l06GaER12161@celine.siteprotect.com> References: <200701061636.l06GaER12161@celine.siteprotect.com> Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 x-scalix-Hops: 1 User-Agent: Icedove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline X-Spam-Score: 1.1 (+) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: sip@ietf.org, 'Juha Heinanen' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Inline. Frank W. Miller wrote: > [snip] >> >> For SIP, just spec TCP for transport and have the UAs punch holes through >> the Firewall/NAT and keepalive them. This I think is sort of what Dean > was >> eluding to in an earlier email. > > Ah, but you do not answer the question: > "[H]ow do you solve the problem of using a SIP endpoint behind a NAT? a > SIP endpoint been defined as running on UDP AND TCP." > > Basically what you are saying (with the other UDP-haters in this list) > is that the UDP problem is too complex, so let's just remove UDP from > the list of transports supported by SIP. > > As this is the I *E* T F, I was hoping for more enthusiasm to solve > problems, instead of sweeping them under the rug. > > > FM: Hole punching will work for UDP and TCP both. > > FM: I'm not a UDP hater but I do think that TCP is the proper transport > protocol that fits this application. I also think that if you have TCP, UDP > is probably unnecessary. I would advocate the dropping of UDP in a "version > 3.0" of SIP but not for -outbound. There is too much installed base that > uses UDP (including my stuff!). This is exactly where I do not follow. You are proposing to remove UDP from SIP (RFC 3261), where it works perfectly well, and to keep it in Outbound, where it does not. > >> For media, ICE is a solution. But, it seems overly complex to me. > > ICE is a brilliant and complex solution to complex problems. But the > problems solved by ICE goes beyond just NAT traversal. It also offers a > strategy for IPv4 to IPv6 migration, a way to create direct connection > for two UA behind the same NAT and a nice solution for multihomed UA. > > FM: What does ICE do for IPv6 transistion that hole punching does not? The ICE algorithm will prefer an IPv6 route for the media if it can find one. > > FM: Two UAs behind the same NAT should not have to traverse the NAT. They > should be smart enough to figure that out. How? Comparing IP addresses does not work. AFAIK, ICE is the only specification that permit this. > I don't think there's anything > wrt "IPv4 to IPv6 transition" (whatever that means) that would not be > possible with hole punching. > [snip] > > FM: No comment on the more radical approach I guess... ;) > Well, the question started with "[h]ow do you solve the problem of using a SIP endpoint behind a NAT?" The protocol that you proposed is perhaps interesting, but does not respond to this question. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: marc@8x8.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jan 07 03:10:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3T6A-0004B5-2B; Sun, 07 Jan 2007 03:09:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3T69-00049c-8F for sip@ietf.org; Sun, 07 Jan 2007 03:09:45 -0500 Received: from mailx.8x8.com ([192.84.19.237] helo=mailint.8x8.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3T64-0007gQ-R1 for sip@ietf.org; Sun, 07 Jan 2007 03:09:45 -0500 Received: from mailint.8x8.com (localhost.localdomain [127.0.0.1]) by mailint.8x8.com (8.13.1/8.13.1) with ESMTP id l0789Zvk032264; Sun, 7 Jan 2007 00:09:35 -0800 Received: from mailint.8x8.com (root@localhost) by mailint.8x8.com (8.13.1/8.13.1/Submit) with ESMTP id l0789Z4O032263; Sun, 7 Jan 2007 00:09:35 -0800 Received: from [10.0.2.15] (godzilla.8x8.com 192.168.84.42) by mailint.8x8.com (Scalix SMTP Relay 10.0.1.3) via ESMTP; Sun, 07 Jan 2007 00:09:34 -0800 (PST) Date: Sun, 7 Jan 2007 09:09:30 +0100 From: Marc Petit-Huguenin To: Alan Bergmin Message-ID: <45A0AABA.7000806@acm.org> In-Reply-To: References: Subject: Re: [Sip] I-D: Preventing Fragmentation for Client Initiated Connections in the Session Initiation Protocol (SIP) x-scalix-Hops: 1 User-Agent: Icedove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Alan Bergmin wrote: >> The TCP connections are temporary, not permanent. >> >> I think that we can compare this to a HTTP server. Even if I am >> constantly logged in slashdot.org, there is no permanent TCP connection >> between my browser and slashdot.org's HTTP server. This is because it >> is more efficient to close the connection at the end of the transaction, >> and to open a new one when I click on reload. > > Looking at most of exising web sites, I agree most of TCP connections > are temporary (ie: limited to the life of the HTTP transaction). > However for "dynamic" web sites like Gmail, there is a permanent TCP > connection reused for many HTTP transactions. > Yes, an AJAX pattern tries to use a permanent connection to the server and to use streaming to do not have to reload the data periodically. This is explained here: http://ajaxpatterns.org/HTTP_Streaming This is the concerns in this document about the ability of a server to manage a lot of permanent TCP connections that make me rethink the assumption that permanent TCP connections for SIP was the definitive solution. After some prototyping and load testing, I concluded that it was possible to use the hybrid TCP-UDP transport with an endpoint behind a NAT, and that this solution was more scalable than the TCP-only solution. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: marc@8x8.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jan 07 09:32:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3Z3Q-0003aT-NN; Sun, 07 Jan 2007 09:31:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3Z3P-0003aN-Lw for sip@ietf.org; Sun, 07 Jan 2007 09:31:19 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3Z3M-0006VM-1s for sip@ietf.org; Sun, 07 Jan 2007 09:31:19 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2121151F; Sun, 7 Jan 2007 15:31:06 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 7 Jan 2007 15:31:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Date: Sun, 7 Jan 2007 15:31:05 +0100 Message-ID: <7374777208BDC7449D5620EF9423256701474AA1@esealmw113.eemea.ericsson.se> In-Reply-To: <200701061944.l06JiO803294@celine.siteprotect.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Thread-Index: AccxwwqgQHi18Y+uQwqCw09Q/9PmQgAB4lHwACdFH6A= From: "Christer Holmberg \(JO/LMF\)" To: "Frank W. Miller" , "Cullen Jennings" , "Juha Heinanen" X-OriginalArrivalTime: 07 Jan 2007 14:31:05.0914 (UTC) FILETIME=[771411A0:01C73268] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: SIP , Marc Petit-Huguenin , Francois Audet , Brian Stucker , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Since this issue is not outbound specific, I propose we start a separate thread for it. I believe I have also seen (and not only at SIPit) clients that establish TCP connections per transaction. But, even if you would establish the connection when the dialog is established, and keep it open during the dialog, you still have the question: are there cases/scenarios where the establishment of the TCP connection takes too much time? Would the TCP connection have to be established already prior to the establishment of the dialog? If so, would it be useful to maintain the TCP connection during the whole registration - also in non-outbound cases? Regards, Christer =20 > -----Original Message----- > From: Frank W. Miller [mailto:fwmiller@cornfed.com]=20 > Sent: 6. tammikuuta 2007 21:44 > To: 'Cullen Jennings'; 'Juha Heinanen' > Cc: 'SIP'; 'Marc Petit-Huguenin'; 'Francois Audet'; 'Dean=20 > Willis'; 'Brian Stucker' > Subject: RE: [Sip] Question about Poll: Proposal relating to=20 > keepalive, TCP,and UDP usage in draft-ietf-sip-outbound >=20 >=20 > I suppose this question would be more appropriate for the=20 > sip-implementors list, but, as someone who's about to add TCP=20 > to their implementation... >=20 > I was going to keep the connection alive during the course of=20 > a dialog for sessions and subscriptions and for transactions=20 > for other things. Do any of you have any comment on your=20 > practical experiences with how best to maintain the life of=20 > TCP connections? >=20 > Thanks, > FM >=20 >=20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Saturday, January 06, 2007 11:45 AM > To: Juha Heinanen > Cc: SIP; Marc Petit-Huguenin; Francois Audet; Brian Stucker;=20 > Dean Willis > Subject: Re: [Sip] Question about Poll: Proposal relating to=20 > keepalive, TCP,and UDP usage in draft-ietf-sip-outbound >=20 >=20 > On Jan 6, 2007, at 10:05 AM, Juha Heinanen wrote: >=20 > > Marc Petit-Huguenin writes: > > > >> Not sure that an UA that cannot receive initial SIP=20 > requests would be > >> very useful. > > > > are you saying that UA implementors are so brain damaged that they > > cannot figure out to initiate a tcp connection without being told =20 > > so by > > ietf? > > > > -- juha >=20 > A large percentage of the TCP implementations observed at SIPIT =20 > formed a new TCP connection for every transaction and take down the =20 > connection at the end of the transaction - some, I kid you not, =20 > closed the TCP connection after sending the request but before =20 > receiving the response. >=20 > Now in fairness, most of these were, ah, implementations that had =20 > lots of other parts that needed improvement and not implementations =20 > that had been to lots of sipits and seen lots of testing but it did =20 > open my eye. The people that have these implementations always point =20 > out that they seem to be following the spec. I don't think=20 > the specs =20 > have to be an full implementers guide so I'm not sure that this =20 > little story has much bearing on what we should be doing in=20 > the specs =20 > other than realize that people do implement some things that seem a =20 > little wacky at times. No matter what we say in the RFCs, there will =20 > always be people who manage not to understand them but it would be =20 > nice if the bulk of the people understood what they needed to do. >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jan 07 10:47:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3aDx-0006jC-3t; Sun, 07 Jan 2007 10:46:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3aDw-0006j7-1t for sip@ietf.org; Sun, 07 Jan 2007 10:46:16 -0500 Received: from rwcrmhc15.comcast.net ([216.148.227.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3aDu-0006V9-PJ for sip@ietf.org; Sun, 07 Jan 2007 10:46:16 -0500 Received: from s73602 (failure[218.104.123.2]) by comcast.net (rwcrmhc15) with SMTP id <20070107154613m1500ppal0e>; Sun, 7 Jan 2007 15:46:13 +0000 Message-ID: <03ac01c73272$7cb1b4f0$807b68da@china.huawei.com> From: "Spencer Dawkins" To: "SIP" References: <7374777208BDC7449D5620EF9423256701474AA1@esealmw113.eemea.ericsson.se> Subject: Re: TCP connection establishment [was: RE: [Sip] Question about Poll:Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Date: Sun, 7 Jan 2007 23:42:42 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Christer, I had pinged Cullen for more details about the SIPit "TCP connections per transaction" experience, but since you followed up onlist, I will, too... (1) Re: "the establishment of the TCP connection takes too much time" - the TCP handshake is three-way, so you're adding one RTT to the establishment of a dialog. How many RTTs are already required for DNS, etc. for a typical INVITE in your environment? (2) More generally - the alternatives would be opening a new TCP connection per (a) message, (b) transaction, (c) dialog, or (d) registration, right? I had observed to Cullen that SIP is normatively dependent on HTTP/1.1, and HTTP spent a LONG time coming up with a coherent transport story, even for the restricted case where NAT and FW traversal tended to be initiated unidirectionally (that story turned out to be, roughly, the clients leave connections open, up to some limited number of connections, and servers leave the connections open as long as it seems reasonable to do so - and a server might choose to close connections immediately). It's not surprising that we are seeing some server implementations use the same strategy for SIP. Apps programmers tend to ignore transport considerations until they recognize a problem. Whatever the final guidance on connection lifetime turns out to be, SIP over TCP is likely to work better if we write it down fairly soon ... and I don't think more than an Informational document is needed. Thanks, Spencer From: "Christer Holmberg (JO/LMF)" Hi, Since this issue is not outbound specific, I propose we start a separate thread for it. I believe I have also seen (and not only at SIPit) clients that establish TCP connections per transaction. But, even if you would establish the connection when the dialog is established, and keep it open during the dialog, you still have the question: are there cases/scenarios where the establishment of the TCP connection takes too much time? Would the TCP connection have to be established already prior to the establishment of the dialog? If so, would it be useful to maintain the TCP connection during the whole registration - also in non-outbound cases? Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jan 07 11:14:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3aeq-0000ur-Mn; Sun, 07 Jan 2007 11:14:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3aep-0000rs-Bq for sip@ietf.org; Sun, 07 Jan 2007 11:14:03 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3aek-0007YD-Kg for sip@ietf.org; Sun, 07 Jan 2007 11:14:03 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 87F3F705; Sun, 7 Jan 2007 17:13:45 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 7 Jan 2007 17:13:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TCP connection establishment [was: RE: [Sip] Question aboutPoll:Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Date: Sun, 7 Jan 2007 17:13:43 +0100 Message-ID: <7374777208BDC7449D5620EF9423256701474B2A@esealmw113.eemea.ericsson.se> In-Reply-To: <03ac01c73272$7cb1b4f0$807b68da@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP connection establishment [was: RE: [Sip] Question aboutPoll:Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Thread-Index: Accyc0g705KxdcSfRVSuk0q/kQAjMQAAkXKA From: "Christer Holmberg \(JO/LMF\)" To: "Spencer Dawkins" , "SIP" X-OriginalArrivalTime: 07 Jan 2007 16:13:45.0142 (UTC) FILETIME=[CE43AD60:01C73276] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >I had pinged Cullen for more details about the SIPit "TCP=20 >connections per transaction" experience, but since you=20 >followed up onlist, I will, too... >=20 >(1) Re: "the establishment of the TCP connection takes too=20 >much time" - the TCP handshake is three-way, so you're adding=20 >one RTT to the establishment of a dialog. How many RTTs are=20 >already required for DNS, etc. for a typical INVITE in your=20 >environment? If you can use the TCP connection to send the INVITE, there is no need for DNS when sending the INVITE. =20 >(2) More generally - the alternatives would be opening a new=20 >TCP connection per (a) message, (b) transaction, (c) dialog,=20 >or (d) registration, right? Yes. >I had observed to Cullen that SIP is normatively dependent on=20 >HTTP/1.1, and HTTP spent a LONG time coming up with a=20 >coherent transport story, even for the restricted case where=20 >NAT and FW traversal tended to be initiated unidirectionally=20 >(that story turned out to be, roughly, the clients leave=20 >connections open, up to some limited number of connections,=20 >and servers leave the connections open as long as it seems=20 >reasonable to do so - and a server might choose to close=20 >connections immediately). It's not surprising that we are=20 >seeing some server implementations use the same strategy for=20 >SIP. The difference is that SIP is often used for real-time type of applications (a good old "phone call" is probably the best example :). You don't mind if you have to wait a few seconds for your webpage to open, but you do mind if it takes a long time to reach the remote party when making a phone call (maybe there could even be regulatory issues...). Regards, Christer >Apps programmers tend to ignore transport considerations until they recognize a problem. >=20 >Whatever the final guidance on connection lifetime turns out to be, SIP over TCP is likely to work better if we write it=20 >down fairly soon ... and I don't think more than an Informational document is needed. >=20 > Thanks, >=20 > Spencer >=20 > From: "Christer Holmberg (JO/LMF)" >=20 > Hi, >=20 > Since this issue is not outbound specific, I propose we start=20 > a separate thread for it. >=20 > I believe I have also seen (and not only at SIPit) clients=20 > that establish TCP connections per transaction. >=20 > But, even if you would establish the connection when the=20 > dialog is established, and keep it open during the dialog,=20 > you still have the > question: are there cases/scenarios where the establishment=20 > of the TCP connection takes too much time? Would the TCP=20 > connection have to be established already prior to the=20 > establishment of the dialog? >=20 > If so, would it be useful to maintain the TCP connection=20 > during the whole registration - also in non-outbound cases? >=20 > Regards, >=20 > Christer=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jan 07 11:39:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3b27-0001x6-IT; Sun, 07 Jan 2007 11:38:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3b25-0001wr-Sm for sip@ietf.org; Sun, 07 Jan 2007 11:38:05 -0500 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3b24-0005wW-HM for sip@ietf.org; Sun, 07 Jan 2007 11:38:05 -0500 Received: from s73602 (failure[218.104.123.2]) by comcast.net (rwcrmhc11) with SMTP id <20070107163802m1100389gbe>; Sun, 7 Jan 2007 16:38:03 +0000 Message-ID: <07f401c73279$b9c2c710$807b68da@china.huawei.com> From: "Spencer Dawkins" To: "SIP" References: <7374777208BDC7449D5620EF9423256701474B2A@esealmw113.eemea.ericsson.se> Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll:Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Date: Mon, 8 Jan 2007 00:34:15 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Christer, Sorry I wasn't clearer (beyond jet-lag, to a place I call "jet-stupid"). I wasn't thinking about the number of RTTs just from the UA's perspective, I was thinking about the total amount of stop-and-wait delays that happen while the INVITE is being processed. There is an optimization path that says "this action takes so long that I want to shave every millisecond, no matter what problems that causes", but if we're talking about a rather slow action anyway, will anyone actually notice the milliseconds we save? Maybe yes, maybe not, but since optimizations have a cost, we need to understand the benefit associated with that cost. And looking further down in your response, I wasn't clearer on another topic - I agree that the strategy you've seen at SIPits is questionable, I'm just saying that the people who used that strategy may be reusing it from another environment where it made more sense, without thinking about how SIP and HTTP/1.1 differ in their transport needs. I agree with your comment that this can be a problem because users think "real-time" means "real-soon". Thanks, Spencer ----- Original Message ----- From: "Christer Holmberg (JO/LMF)" Hi, >I had pinged Cullen for more details about the SIPit "TCP >connections per transaction" experience, but since you >followed up onlist, I will, too... > >(1) Re: "the establishment of the TCP connection takes too >much time" - the TCP handshake is three-way, so you're adding >one RTT to the establishment of a dialog. How many RTTs are >already required for DNS, etc. for a typical INVITE in your >environment? If you can use the TCP connection to send the INVITE, there is no need for DNS when sending the INVITE. >(2) More generally - the alternatives would be opening a new >TCP connection per (a) message, (b) transaction, (c) dialog, >or (d) registration, right? Yes. >I had observed to Cullen that SIP is normatively dependent on >HTTP/1.1, and HTTP spent a LONG time coming up with a >coherent transport story, even for the restricted case where >NAT and FW traversal tended to be initiated unidirectionally >(that story turned out to be, roughly, the clients leave >connections open, up to some limited number of connections, >and servers leave the connections open as long as it seems >reasonable to do so - and a server might choose to close >connections immediately). It's not surprising that we are >seeing some server implementations use the same strategy for >SIP. The difference is that SIP is often used for real-time type of applications (a good old "phone call" is probably the best example :). You don't mind if you have to wait a few seconds for your webpage to open, but you do mind if it takes a long time to reach the remote party when making a phone call (maybe there could even be regulatory issues...). Regards, Christer >Apps programmers tend to ignore transport considerations until they recognize a problem. > >Whatever the final guidance on connection lifetime turns out to be, SIP over TCP is likely to work better if we write it >down fairly soon ... and I don't think more than an Informational document is needed. > > Thanks, > > Spencer > > From: "Christer Holmberg (JO/LMF)" > > Hi, > > Since this issue is not outbound specific, I propose we start > a separate thread for it. > > I believe I have also seen (and not only at SIPit) clients > that establish TCP connections per transaction. > > But, even if you would establish the connection when the > dialog is established, and keep it open during the dialog, > you still have the > question: are there cases/scenarios where the establishment > of the TCP connection takes too much time? Would the TCP > connection have to be established already prior to the > establishment of the dialog? > > If so, would it be useful to maintain the TCP connection > during the whole registration - also in non-outbound cases? > > Regards, > > Christer > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jan 07 11:41:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3b4v-00038K-30; Sun, 07 Jan 2007 11:41:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3b4r-00035t-Oa for sip@ietf.org; Sun, 07 Jan 2007 11:40:57 -0500 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3b4o-0006B7-IC for sip@ietf.org; Sun, 07 Jan 2007 11:40:57 -0500 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 7820D20A2FC; Sun, 7 Jan 2007 17:40:50 +0100 (CET) Message-Id: <7.0.1.0.0.20070107170737.05672488@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 07 Jan 2007 17:18:28 +0100 To: "Spencer Dawkins" , "SIP" From: Jiri Kuthan Subject: Re: TCP connection establishment [was: RE: [Sip] Question about Poll:Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] In-Reply-To: <03ac01c73272$7cb1b4f0$807b68da@china.huawei.com> References: <7374777208BDC7449D5620EF9423256701474AA1@esealmw113.eemea.ericsson.se> <03ac01c73272$7cb1b4f0$807b68da@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 16:42 07/01/2007, Spencer Dawkins wrote: >Hi, Christer, > >I had pinged Cullen for more details about the SIPit "TCP connections per transaction" experience, but since you followed up onlist, I will, too... > >(1) Re: "the establishment of the TCP connection takes too much time" - the TCP handshake is three-way, so you're adding one RTT to the establishment of a dialog. How many RTTs are already required for DNS, etc. for a typical INVITE in your environment? I dont think it really matters so much, because what I would call a reasonable vanilla SIP implementation establishes TCP connection during registration. Sending/receiving an INVITE doesn't add up. >(2) More generally - the alternatives would be opening a new TCP connection per (a) message, (b) transaction, (c) dialog, or (d) registration, right? Yes, that's possible implementors' choices. I think that if there is no bulk traffic then keeping number of connections equal to one for as long as possible eliminates extra TCP setup times and confusion with multiple connections (which one is associated with which contact...). Possibly those who use SIP for bulk transport such as SIMPLE may be keen to have parallel TCP connections to minimize blocking. >I had observed to Cullen that SIP is normatively dependent on HTTP/1.1, and HTTP spent a LONG time coming up with a coherent transport story, even for the restricted case where NAT and FW traversal tended to be initiated unidirectionally (that story turned out to be, roughly, the clients leave connections open, up to some limited number of connections, and servers leave the connections open as long as it seems reasonable to do so - and a server might choose to close connections immediately). It's not surprising that we are seeing some server implementations use the same strategy for SIP. I'm not sure how good the HTTP parralle works sind we need inbound traffic too and connections closed at proxy's discretion prohibit that. We do it too in SER when we run out of TCP connections. Which leads to reasonable clients reregistering themselves to stay reachable and the problem shifts to other clients. I think having reasonable client recommendations (behave?) which would keep number of connections low (to avoid ambiguities and overloaded servers) is a safe thing to do. -jiri >Apps programmers tend to ignore transport considerations until they recognize a problem. > >Whatever the final guidance on connection lifetime turns out to be, SIP over TCP is likely to work better if we write it down fairly soon ... and I don't think more than an Informational document is needed. > >Thanks, > >Spencer > >From: "Christer Holmberg (JO/LMF)" > >Hi, > >Since this issue is not outbound specific, I propose we start a separate >thread for it. > >I believe I have also seen (and not only at SIPit) clients that >establish TCP connections per transaction. > >But, even if you would establish the connection when the dialog is >established, and keep it open during the dialog, you still have the >question: are there cases/scenarios where the establishment of the TCP >connection takes too much time? Would the TCP connection have to be >established already prior to the establishment of the dialog? > >If so, would it be useful to maintain the TCP connection during the >whole registration - also in non-outbound cases? > >Regards, > >Christer > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jan 07 11:41:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3b4u-00037l-Cf; Sun, 07 Jan 2007 11:41:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3b4r-00035s-OG for sip@ietf.org; Sun, 07 Jan 2007 11:40:57 -0500 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3b4o-0006B4-IC for sip@ietf.org; Sun, 07 Jan 2007 11:40:57 -0500 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id C458D20A2EE; Sun, 7 Jan 2007 17:40:48 +0100 (CET) Message-Id: <7.0.1.0.0.20070107170604.024a2640@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 07 Jan 2007 17:06:54 +0100 To: "Frank W. Miller" , "'Cullen Jennings'" , "'Juha Heinanen'" From: Jiri Kuthan Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound In-Reply-To: <200701061944.l06JiO803294@celine.siteprotect.com> References: <62A97DE1-622F-429C-A1ED-626BC1F65C78@cisco.com> <200701061944.l06JiO803294@celine.siteprotect.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: 'SIP' , 'Marc Petit-Huguenin' , 'Francois Audet' , 'Brian Stucker' , 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Keep it as long as you can until you don't shut the client down (i.e., unregister). -jiri At 20:43 06/01/2007, Frank W. Miller wrote: >I suppose this question would be more appropriate for the sip-implementors >list, but, as someone who's about to add TCP to their implementation... > >I was going to keep the connection alive during the course of a dialog for >sessions and subscriptions and for transactions for other things. Do any of >you have any comment on your practical experiences with how best to maintain >the life of TCP connections? > >Thanks, >FM > > >-----Original Message----- >From: Cullen Jennings [mailto:fluffy@cisco.com] >Sent: Saturday, January 06, 2007 11:45 AM >To: Juha Heinanen >Cc: SIP; Marc Petit-Huguenin; Francois Audet; Brian Stucker; Dean Willis >Subject: Re: [Sip] Question about Poll: Proposal relating to keepalive, >TCP,and UDP usage in draft-ietf-sip-outbound > > >On Jan 6, 2007, at 10:05 AM, Juha Heinanen wrote: > >> Marc Petit-Huguenin writes: >> >>> Not sure that an UA that cannot receive initial SIP requests would be >>> very useful. >> >> are you saying that UA implementors are so brain damaged that they >> cannot figure out to initiate a tcp connection without being told >> so by >> ietf? >> >> -- juha > >A large percentage of the TCP implementations observed at SIPIT >formed a new TCP connection for every transaction and take down the >connection at the end of the transaction - some, I kid you not, >closed the TCP connection after sending the request but before >receiving the response. > >Now in fairness, most of these were, ah, implementations that had >lots of other parts that needed improvement and not implementations >that had been to lots of sipits and seen lots of testing but it did >open my eye. The people that have these implementations always point >out that they seem to be following the spec. I don't think the specs >have to be an full implementers guide so I'm not sure that this >little story has much bearing on what we should be doing in the specs >other than realize that people do implement some things that seem a >little wacky at times. No matter what we say in the RFCs, there will >always be people who manage not to understand them but it would be >nice if the bulk of the people understood what they needed to do. > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jan 07 11:41:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3b4t-00037C-GM; Sun, 07 Jan 2007 11:40:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3b4q-00035n-TG for sip@ietf.org; Sun, 07 Jan 2007 11:40:56 -0500 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3b4o-0006B0-IB for sip@ietf.org; Sun, 07 Jan 2007 11:40:56 -0500 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 26D2020A2E6; Sun, 7 Jan 2007 17:40:47 +0100 (CET) Message-Id: <7.0.1.0.0.20070107165921.024a43a8@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 07 Jan 2007 17:04:42 +0100 To: jh@tutpro.com (Juha Heinanen), Cullen Jennings From: Jiri Kuthan Subject: Re: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound In-Reply-To: <17823.63143.2955.529777@harjus.tutpro.com> References: <458F1308.2070601@softarmor.com> <6FC4416DDE56C44DA0AEE67BC7CA43711213EA6F@zrc2hxm2.corp.nortel.com> <17819.64168.559864.751052@harjus.tutpro.com> <5F813F72-62E8-48C2-9130-68B39F71CDBE@cisco.com> <17821.60560.400209.135681@harjus.tutpro.com> <4DC7F4F8-68BF-4F96-A145-66AF6BEA60A1@cisco.com> <17823.24470.324705.515983@harjus.tutpro.com> <459F8107.7060809@acm.org> <17823.58576.926896.687135@harjus.tutpro.com> <62A97DE1-622F-429C-A1ED-626BC1F65C78@cisco.com> <17823.63143.2955.529777@harjus.tutpro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: SIP , Marc Petit-Huguenin , Francois Audet , Dean Willis , Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 20:21 06/01/2007, Juha Heinanen wrote: >Cullen Jennings writes: > > > No matter what we say in the RFCs, there will > > always be people who manage not to understand them but it would be > > nice if the bulk of the people understood what they needed to do. > >i agree that many implementors don't care about rfcs. just an example >from this very week: > >we noticed that a popular sip phone vendor didn't implement g726 as >specified in rfc3551. the vendor did two mistakes: payload type was 2 >and media packing was wrong. > >when i complained about it, vendor replied that they don't care about >the rfc, but rather follow cisco, who also has wrong implementation of >g726. comforting was they would consider fixing their implementation if >i would order 20,000 phones from them. > >coming back to tcp, if implementors don't think before they start >coding, ietf can produce a best practise document saying that it is a >good idea to initiate tcp connections and keep them open. it is a pure >implementation issue, not a protocol one. which appears to me to be a behave application guidance bcp candidate. give the client the responsibility for establishing transport connection, keeping it alive (and reestablish session state if connection is gone), be symmetric. -jiri -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jan 07 11:54:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3bHS-0000Ur-Hr; Sun, 07 Jan 2007 11:53:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3bHR-0000UP-2I for sip@ietf.org; Sun, 07 Jan 2007 11:53:57 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3bHO-0007vC-Mr for sip@ietf.org; Sun, 07 Jan 2007 11:53:57 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 07 Jan 2007 08:53:52 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l07Grp4F018964; Sun, 7 Jan 2007 08:53:51 -0800 Received: from [192.168.0.103] (sjc-vpn-hwcore-141.cisco.com [10.21.152.141]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l07Grolb011570; Sun, 7 Jan 2007 08:53:51 -0800 (PST) Message-ID: <45A125D6.2000804@cisco.com> Date: Sun, 07 Jan 2007 08:54:46 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.8) Gecko/20061025 Thunderbird/1.5.0.8 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Spencer Dawkins Subject: Re: TCP connection establishment [was: RE: [Sip] Question about Poll:Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF9423256701474AA1@esealmw113.eemea.ericsson.se> <03ac01c73272$7cb1b4f0$807b68da@china.huawei.com> In-Reply-To: <03ac01c73272$7cb1b4f0$807b68da@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3165; t=1168188832; x=1169052832; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20TCP=20connection=20establishment=20[was=3A=20RE=3A=20 [Sip]=20Question=20about=09Poll=3AProposal=0A=20relating=20to=20keepalive, =20TCP,=09and=20UDP=20usage=20in=20draft-ietf-sip-outbound] |Sender:=20; bh=R8Du1ZyarocrPNu7VxamTVR2OaYWFaAE7t3NEAohfGU=; b=BSJ7+vfmMHdkRfXp2PW9DbbjZjGQzLSB2rraB9/NTDXS2N6fnxWcn6w/rulUi42HDDuKQOQc s7MoRhuddv0L8J1vuOwRMPU6hCMyFLsQw6WA7D+N53Sm6g2tFJNlB1HH; Authentication-Results: sj-dkim-7; header.From=mat@cisco.com; dkim=pass (sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From my perspective, any place you have a discussion about transport/TCP/UDP, you should actually have a discussion about (D)TLS as if were always enabled. That is the medium to even short term goal, IMO, so framing the overheads as "just" the 3-way TCP handshake really misses the boat on how you strategize for exchanges that are actually 10x more expensive (or more, fsvo "expensive"). Mike Spencer Dawkins wrote: > Hi, Christer, > > I had pinged Cullen for more details about the SIPit "TCP connections > per transaction" experience, but since you followed up onlist, I will, > too... > > (1) Re: "the establishment of the TCP connection takes too much time" > - the TCP handshake is three-way, so you're adding one RTT to the > establishment of a dialog. How many RTTs are already required for DNS, > etc. for a typical INVITE in your environment? > > (2) More generally - the alternatives would be opening a new TCP > connection per (a) message, (b) transaction, (c) dialog, or (d) > registration, right? > > I had observed to Cullen that SIP is normatively dependent on > HTTP/1.1, and HTTP spent a LONG time coming up with a coherent > transport story, even for the restricted case where NAT and FW > traversal tended to be initiated unidirectionally (that story turned > out to be, roughly, the clients leave connections open, up to some > limited number of connections, and servers leave the connections open > as long as it seems reasonable to do so - and a server might choose to > close connections immediately). It's not surprising that we are seeing > some server implementations use the same strategy for SIP. Apps > programmers tend to ignore transport considerations until they > recognize a problem. > > Whatever the final guidance on connection lifetime turns out to be, > SIP over TCP is likely to work better if we write it down fairly soon > ... and I don't think more than an Informational document is needed. > > Thanks, > > Spencer > > From: "Christer Holmberg (JO/LMF)" > > Hi, > > Since this issue is not outbound specific, I propose we start a separate > thread for it. > > I believe I have also seen (and not only at SIPit) clients that > establish TCP connections per transaction. > > But, even if you would establish the connection when the dialog is > established, and keep it open during the dialog, you still have the > question: are there cases/scenarios where the establishment of the TCP > connection takes too much time? Would the TCP connection have to be > established already prior to the establishment of the dialog? > > If so, would it be useful to maintain the TCP connection during the > whole registration - also in non-outbound cases? > > Regards, > > Christer > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jan 07 12:06:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3bT8-0005qq-9p; Sun, 07 Jan 2007 12:06:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3bT6-0005ql-T4 for sip@ietf.org; Sun, 07 Jan 2007 12:06:00 -0500 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3bT5-0001OJ-L6 for sip@ietf.org; Sun, 07 Jan 2007 12:06:00 -0500 Received: from s73602 (failure[218.104.123.2]) by comcast.net (rwcrmhc13) with SMTP id <20070107170558m1300i29dde>; Sun, 7 Jan 2007 17:05:58 +0000 Message-ID: <0aff01c7327d$a06fa2c0$807b68da@china.huawei.com> From: "Spencer Dawkins" To: "SIP" References: <7374777208BDC7449D5620EF9423256701474AA1@esealmw113.eemea.ericsson.se> <03ac01c73272$7cb1b4f0$807b68da@china.huawei.com> <45A125D6.2000804@cisco.com> Subject: Re: TCP connection establishment [was: RE: [Sip] Question about Poll:Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Date: Mon, 8 Jan 2007 01:02:25 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Michael, > From my perspective, any place you have a discussion about > transport/TCP/UDP, > you should actually have a discussion about (D)TLS as if were always > enabled. > That is the medium to even short term goal, IMO, so framing the overheads > as > "just" the 3-way TCP handshake really misses the boat on how you > strategize > for exchanges that are actually 10x more expensive (or more, fsvo > "expensive"). > > Mike Agree, and thanks for the followup. Spencer p.s. Just for general background, I got sucked into the void of TCP vs UDP for wireless devices in the late 1990s, when the Wireless Application Protocol (WAP) people were totally freaked out about the way TCP seemed to work on GPRS links, etc. This was one of the hottest topics when the PILC TSV working group started up. They did a lot of work on WAP-specific alternatives to TCP, but when they did WAP 2.0, they ended up with a recommendation for "wireless profiled TCP" anyway - and the "wireless profile" from several years ago is now pretty much mainstream TCP. They were solving a different problem, so I'm not saying this will happen for SIP, I'm just saying that trying to shave milliseconds without looking at the entire picture - as Michael pointed out - "misses the boat". _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jan 07 15:38:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3eku-0005MR-T1; Sun, 07 Jan 2007 15:36:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3ekt-0005MM-9f for sip@ietf.org; Sun, 07 Jan 2007 15:36:35 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3ekp-0005i7-Jo for sip@ietf.org; Sun, 07 Jan 2007 15:36:35 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A56371A3; Sun, 7 Jan 2007 21:36:22 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 7 Jan 2007 21:36:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TCP connection establishment [was: RE: [Sip] QuestionaboutPoll:Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Date: Sun, 7 Jan 2007 21:36:22 +0100 Message-ID: <7374777208BDC7449D5620EF9423256701474BD9@esealmw113.eemea.ericsson.se> In-Reply-To: <07f401c73279$b9c2c710$807b68da@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP connection establishment [was: RE: [Sip] QuestionaboutPoll:Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Thread-Index: Accyem1iglqsOpmtTBCzlPagpdYKHgAIJ3sA From: "Christer Holmberg \(JO/LMF\)" To: "Spencer Dawkins" , "SIP" X-OriginalArrivalTime: 07 Jan 2007 20:36:22.0196 (UTC) FILETIME=[7E334F40:01C7329B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, So, then we need to identify the cost of having a "permanent" (alive during the whole registration) TCP connection. We DO use it for outbound, so... Regards, Christer =20 > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org]=20 > Sent: 7. tammikuuta 2007 18:34 > To: SIP > Subject: Re: TCP connection establishment [was: RE: [Sip]=20 > QuestionaboutPoll:Proposal relating to keepalive, TCP,and UDP=20 > usage in draft-ietf-sip-outbound] >=20 > Hi, Christer, >=20 > Sorry I wasn't clearer (beyond jet-lag, to a place I call=20 > "jet-stupid"). I wasn't thinking about the number of RTTs=20 > just from the UA's perspective, I was thinking about the=20 > total amount of stop-and-wait delays that happen while the=20 > INVITE is being processed. >=20 > There is an optimization path that says "this action takes so=20 > long that I want to shave every millisecond, no matter what=20 > problems that causes", but if we're talking about a rather=20 > slow action anyway, will anyone actually notice the=20 > milliseconds we save? Maybe yes, maybe not, but since=20 > optimizations have a cost, we need to understand the benefit=20 > associated with that cost. >=20 > And looking further down in your response, I wasn't clearer=20 > on another topic - I agree that the strategy you've seen at=20 > SIPits is questionable, I'm just saying that the people who=20 > used that strategy may be reusing it from another environment=20 > where it made more sense, without thinking about how SIP and=20 > HTTP/1.1 differ in their transport needs. I agree with your=20 > comment that this can be a problem because users think=20 > "real-time" means "real-soon". >=20 > Thanks, >=20 > Spencer >=20 > ----- Original Message ----- > From: "Christer Holmberg (JO/LMF)" >=20 >=20 > Hi, >=20 > >I had pinged Cullen for more details about the SIPit "TCP > >connections per transaction" experience, but since you > >followed up onlist, I will, too... > > > >(1) Re: "the establishment of the TCP connection takes too > >much time" - the TCP handshake is three-way, so you're adding > >one RTT to the establishment of a dialog. How many RTTs are > >already required for DNS, etc. for a typical INVITE in your > >environment? >=20 > If you can use the TCP connection to send the INVITE, there is no need > for DNS when sending the INVITE. >=20 > >(2) More generally - the alternatives would be opening a new > >TCP connection per (a) message, (b) transaction, (c) dialog, > >or (d) registration, right? >=20 > Yes. >=20 > >I had observed to Cullen that SIP is normatively dependent on > >HTTP/1.1, and HTTP spent a LONG time coming up with a > >coherent transport story, even for the restricted case where > >NAT and FW traversal tended to be initiated unidirectionally > >(that story turned out to be, roughly, the clients leave > >connections open, up to some limited number of connections, > >and servers leave the connections open as long as it seems > >reasonable to do so - and a server might choose to close > >connections immediately). It's not surprising that we are > >seeing some server implementations use the same strategy for > >SIP. >=20 > The difference is that SIP is often used for real-time type of > applications (a good old "phone call" is probably the best example :). > You don't mind if you have to wait a few seconds for your webpage to > open, but you do mind if it takes a long time to reach the=20 > remote party > when making a phone call (maybe there could even be regulatory > issues...). >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > >Apps programmers tend to ignore transport considerations until they > recognize a problem. > > > >Whatever the final guidance on connection lifetime turns out=20 > to be, SIP > over TCP is likely to work better if we write it > >down fairly soon ... and I don't think more than an Informational > document is needed. >=20 >=20 >=20 >=20 >=20 > > > > Thanks, > > > > Spencer > > > > From: "Christer Holmberg (JO/LMF)" > > > > Hi, > > > > Since this issue is not outbound specific, I propose we start > > a separate thread for it. > > > > I believe I have also seen (and not only at SIPit) clients > > that establish TCP connections per transaction. > > > > But, even if you would establish the connection when the > > dialog is established, and keep it open during the dialog, > > you still have the > > question: are there cases/scenarios where the establishment > > of the TCP connection takes too much time? Would the TCP > > connection have to be established already prior to the > > establishment of the dialog? > > > > If so, would it be useful to maintain the TCP connection > > during the whole registration - also in non-outbound cases? > > > > Regards, > > > > Christer > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jan 07 16:58:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3g1U-0003hR-P9; Sun, 07 Jan 2007 16:57:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3g1T-0003hD-On for sip@ietf.org; Sun, 07 Jan 2007 16:57:47 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3g1S-0005WB-Ft for sip@ietf.org; Sun, 07 Jan 2007 16:57:47 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 07 Jan 2007 13:57:45 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l07LvjWS001297; Sun, 7 Jan 2007 13:57:45 -0800 Received: from [192.168.4.2] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l07LvYlc023499; Sun, 7 Jan 2007 13:57:34 -0800 (PST) In-Reply-To: <7374777208BDC7449D5620EF9423256701474AA1@esealmw113.eemea.ericsson.se> References: <7374777208BDC7449D5620EF9423256701474AA1@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3C9795FE-4BE9-4D30-B7C4-E397BAA320F3@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Date: Sun, 7 Jan 2007 13:57:26 -0800 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=653; t=1168207065; x=1169071065; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20TCP=20connection=20establishment=20[was=3A=20RE=3A=20 [Sip]=20Question=20about=20Poll=3A=20Proposal=20relating=20to=20keepalive, =20TCP,and=20UDP=20usage=20in=20draft-ietf-sip-outbound] |Sender:=20; bh=yhSeFfOE1oCHr6BbchYBkxaGrgpLiC4XmYQoVpVI8xE=; b=cJw7cMRn7T1/Vg/OJjO1lOjA0gdXLVnuzXlE5wJ5IJiCpUT9kKCJaJlvsEox4Z4c3bllkuSq A48KsRRwnINN1Km68T7qqisx6VP/49l6y85Q6JsAVpJwXVeAUV0GlHxn; Authentication-Results: sj-dkim-7; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Marc Petit-Huguenin , SIP , Francois Audet , Brian Stucker , Juha Heinanen , "Frank W. Miller" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jan 7, 2007, at 6:31 AM, Christer Holmberg ((JO/LMF)) wrote: > If so, would it be useful to maintain the TCP connection during the > whole registration - also in non-outbound cases? Nothing to do with outbound but my 2 cents on this is a UA should try to keep the TCP connection open as long as the registration (that means forever in most cases or until the UA reboots or shutdown). Proxies should try and keep TCP connections open until they run out of resources then have some algorithm to determine which connections to kill to clear up resources. I suspect most people will give you about the same answer. Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jan 07 17:45:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3glA-0005LB-3a; Sun, 07 Jan 2007 17:45:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3gl9-0005L5-4f for sip@ietf.org; Sun, 07 Jan 2007 17:44:59 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3gl4-0004B4-Oz for sip@ietf.org; Sun, 07 Jan 2007 17:44:59 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l07Mil02003655; Sun, 7 Jan 2007 16:44:47 -0600 (CST) Received: from [135.244.32.14] (vkg.lra.lucent.com [135.244.32.14]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l07Milu11669; Sun, 7 Jan 2007 16:44:47 -0600 (CST) Message-ID: <45A177DE.6090102@lucent.com> Date: Sun, 07 Jan 2007 16:44:46 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" , spencer@mcsr-labs.org Subject: Re: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF9423256701474AA1@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF9423256701474AA1@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > Since this issue is not outbound specific, I propose we start a > separate thread for it. > > I believe I have also seen (and not only at SIPit) clients that > establish TCP connections per transaction. [...] > > If so, would it be useful to maintain the TCP connection during the > whole registration - also in non-outbound cases? and Spencer Dawkins further wrote: > Whatever the final guidance on connection lifetime turns out to be, > SIP over TCP is likely to work better if we write it down fairly soon > ... and I don't think more than an Informational document is needed. There is already a document that discusses TCP connection maintenance (i.e., reuse) orthogonal to the outbound case. The document is connect-reuse-07, http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-07.txt, although lately, it always seems to be hanging under the sword of Damoclese. The document itself is ready, has been implemented, and does talk about the distilled wisdom in client and server TCP socket management (see S8). It is an aggregation from the original work some of us did as a loose design team in TCP connection guidelines([1], which has since expired and portions subsumed in connect-reuse), and Rohan's connection alias draft, before outbound came into the picture. Please read it, and if this does not satisfy your requirements, I would be more than glad to start a dialog to accommodate them to an agreed consensus. Given the regularity with which TCP connection reuse gets asked on the list, it would be a shame to jettison the current work on it. [1] Vijay K. Gurbani, Chris Boulton, Rajnish Jain, and Cullen Jennings, "Guidelines for implementors using connection-oriented transports in the Session Initiation Protocol (SIP)," IETF Internet-Draft, February 2005, expired. Available at Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jan 07 17:50:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3gqJ-0007YU-SS; Sun, 07 Jan 2007 17:50:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3gqI-0007VM-Kr for sip@ietf.org; Sun, 07 Jan 2007 17:50:18 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3gqH-00054L-CW for sip@ietf.org; Sun, 07 Jan 2007 17:50:18 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 07 Jan 2007 14:50:16 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l07MoGdu008478; Sun, 7 Jan 2007 14:50:16 -0800 Received: from [192.168.4.2] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id l07MoF05024394; Sun, 7 Jan 2007 14:50:15 -0800 (PST) In-Reply-To: <7374777208BDC7449D5620EF9423256701474B2A@esealmw113.eemea.ericsson.se> References: <7374777208BDC7449D5620EF9423256701474B2A@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll:Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Date: Sun, 7 Jan 2007 14:50:06 -0800 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=621; t=1168210216; x=1169074216; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20TCP=20connection=20establishment=20[was=3A=20RE=3A=20 [Sip]=20Question=20aboutPoll=3AProposal=20relating=20to=20keepalive, =20TCP ,=20and=20UDP=20usage=20in=20draft-ietf-sip-outbound] |Sender:=20; bh=utx3sb+2HNeeGPFGOKjaURj6KISVc85O5zx/IXwyfFA=; b=H9FsEyYsQHljbAsX0OdxL/T94tfRhi6S4kkZL+DbaESfVPCk/8jQGCZOdH6C20IfrIU22NMf 7kztb8CDpoTP/WGOPHYcprEdLGn3hf5VMiDMyOm7vwr+UMNSPQNHhqPv; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jan 7, 2007, at 8:13 AM, Christer Holmberg ((JO/LMF)) wrote: > The difference is that SIP is often used for real-time type of > applications (a good old "phone call" is probably the best example :). > You don't mind if you have to wait a few seconds for your webpage to > open, but you do mind if it takes a long time to reach the remote > party > when making a phone call (maybe there could even be regulatory > issues...). Irrelevant side comment but ... oddly, I am perfectly willing to wait 2 seconds for a phone post dial delay but waiting even one second for my web page drives me insane. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 08 00:43:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3nGg-00049X-VP; Mon, 08 Jan 2007 00:41:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3nGf-000491-IF for sip@ietf.org; Mon, 08 Jan 2007 00:41:57 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3nGc-0004RJ-4Y for sip@ietf.org; Mon, 08 Jan 2007 00:41:57 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 07 Jan 2007 21:41:53 -0800 X-IronPort-AV: i="4.13,158,1167638400"; d="scan'208"; a="99030870:sNHT45473238" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l085frrb032671; Sun, 7 Jan 2007 21:41:53 -0800 Received: from [192.168.4.2] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id l085fmUh023345; Sun, 7 Jan 2007 21:41:53 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Sun, 7 Jan 2007 21:41:41 -0800 To: SIP X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3949; t=1168234913; x=1169098913; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Update=20of=20outbound |Sender:=20; bh=XbaV9H0iUlD2oNqC3DczqTDEGHx9kOGGrbSmrXpdkVs=; b=HR2myMswWHksEi+H/4EghSt9TbvDxSxiJ4q59jdWql6EI6oJI0iEMjzcNQrWEZfo5jucnYwR dlZoX2NMWLPF4+HTFL39BUkrHvsg+VfHs+slnYzNK4BQd5EXqmE9/LKm; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Rohan Mahy Subject: [Sip] Update of outbound X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I just put out an updated version of outbound. Now before you even look at it, I did not touch the TCP keep alive. I realize the questions of if the TCP keep alive are STUN or Double CRLF is still a hot topic. I don't know if it is an open issue or not - I'm working with the chairs on trying to figure that out. However, this topic is totally orthogonal from all the other issues so I did my best to resolve the other issues. Specifically: The draft makes it clear that if you can do TCP Keep alive, you can use those instead of other Keep alive approaches for TCP. The draft makes it clear that deployments that want to use only TCP can use only TCP and do not not have to do any UDP based outbound registrations. The draft makes it clear that deployments that want to use only UDP can use only UDP but that large requests will not work and lots of the functional of SIP will not work If there are drawbacks of using UDP that I missed, I am glad to add them. The draft makes it clear that deployments that want to use both TCP and UDP or some combination of them can do that and can use the current RFC 3261 message switchover approaches if you have both. If future works such as draft-petithuguenin-sip-outbound-fragmentation defined some way to dynamical start TCP connections, it would work fine with outbound and outbound would not forbid something like that. Pekka (and others) have been regularly pointing out that for standards track documents, the normative statements need to be testable for the document to be able to advance. Because of this, certain types of normative operational advice need to be done in BCPs. The draft has no normative language that would block it from moving forward in the standards track but it does have very clear operational advice on what the problems of using UDP are. The draft does not change in 3261 the protocols a UA, Proxy, or Registrar need to implement. This would be a very difficult thing for us to get consensus on and I see no need to get consensus on a change here to move this document forward *soon* in a way that meets everyone needs. Until it shows up in the directory, you can find it at: http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip- outbound-07.html http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip- outbound-07.txt Now more on the big hot item: Bit of history on this - we have had this as an open issues slide at countless IETF meetings. I thought we had closed it a few meetings ago but one of the authors reopened it. Then at a later meeting we took a big hum to close it once and for all and it was a the usual big room full of people and we had a pretty strong hum towards use the same thing for both UDP and TCP. Then very recently on the list, the chairs took a poll on the subject. The poll had very few responses but were overwhelming in favor of using CRLF. I counted 12 people in favor of CRLF. (Jeroen, Ekki, Elwell, Aki, Markus, ALfred, Miguel, Hisham, Francois, Byron, Mac, Fredrik). Unfortunately, none of the people that were proponents of STUN in the wg hum commented on the most recent poll. So where does this leave us. Well luckily for me, it leaves the issue firmly in the lap of the chairs to determine consensus and I just have to edit the document. My personal view on the topic is that 12 people is no where near enough to overturn the huge hum however given the strong direction of the recent poll, it may however be enough for the chairs to decide this is an "Open Issue". If it is an open issue, then I suspect the only place to get strong enough consensus to overturn the previous hum is in the next WG meeting. I'll work with the chairs in trying to find out what they want to do here. Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 08 02:35:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3p25-0002FY-3O; Mon, 08 Jan 2007 02:35:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3p24-0002FP-3B for sip@ietf.org; Mon, 08 Jan 2007 02:35:00 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3p20-00025f-Cx for sip@ietf.org; Mon, 08 Jan 2007 02:35:00 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0B7368FB; Mon, 8 Jan 2007 08:34:32 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 08:34:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Update of outbound Date: Mon, 8 Jan 2007 08:34:29 +0100 Message-ID: <7374777208BDC7449D5620EF9423256701474EB0@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Update of outbound Thread-Index: Accy6Cftjx4IbVEKT5mw3j6RVOrZRAADPhhA From: "Christer Holmberg \(JO/LMF\)" To: "Cullen Jennings" , "SIP" X-OriginalArrivalTime: 08 Jan 2007 07:34:31.0834 (UTC) FILETIME=[6FDBDFA0:01C732F7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Thanks for the draft! A few comments/questions on chapter 8. First, the text now says that the edge proxy can indicate support of keepalive by inserting the parameter e.g. in the Path header. So, maybe the following text futher down could also be modified: "For example, automatic or manual configuration of an outbound-proxy-set which contains the keepalive=3Dstun parameter is considered sufficient explicit indication." ...would be: "For example, automatic or manual configuration of an outbound-proxy-set which contains the keepalive=3Dstun parameter, or the receival of the parameter in the Path header of the edge proxy, is considered..." Second, the text says that the explicit indication is needed before any traffic is sent. I said earlier that one could send the REGISTER before any STUN is sent. And, if the indication comes in the REGISTER response the REGISTER has to be sent before. OPTIONS is another example there "traffic" may be sent before the indication has be retrieved. So, maybe some clarification text is needed, saying that "STUN traffic" (the way the text is now written could be understood to also cover SIP traffic) shall not be sent before the indication has been retrieved. Regards, Christer =20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: 8. tammikuuta 2007 7:42 > To: SIP > Cc: Rohan Mahy > Subject: [Sip] Update of outbound >=20 >=20 > I just put out an updated version of outbound. Now before you=20 > even look at it, I did not touch the TCP keep alive. I=20 > realize the questions of if the TCP keep alive are STUN or=20 > Double CRLF is still a hot topic. I don't know if it is an=20 > open issue or not - I'm working with the chairs on trying to=20 > figure that out. However, this topic is totally orthogonal=20 > from all the other issues so I did my best to resolve the=20 > other issues. >=20 > Specifically: >=20 > The draft makes it clear that if you can do TCP Keep alive,=20 > you can use those instead of other Keep alive approaches for TCP. >=20 > The draft makes it clear that deployments that want to use=20 > only TCP can use only TCP and do not not have to do any UDP=20 > based outbound registrations. >=20 > The draft makes it clear that deployments that want to use=20 > only UDP can use only UDP but that large requests will not=20 > work and lots of the functional of SIP will not work If=20 > there are drawbacks of using UDP that I missed, I am glad to add them. >=20 > The draft makes it clear that deployments that want to use=20 > both TCP and UDP or some combination of them can do that and=20 > can use the current RFC 3261 message switchover approaches if=20 > you have both. If future works such as=20 > draft-petithuguenin-sip-outbound-fragmentation > defined some way to dynamical start TCP connections, it would=20 > work fine with outbound and outbound would not forbid=20 > something like that. >=20 > Pekka (and others) have been regularly pointing out that for=20 > standards track documents, the normative statements need to=20 > be testable for the document to be able to advance. Because=20 > of this, certain types of normative operational advice need=20 > to be done in BCPs. The draft has no normative language that=20 > would block it from moving forward in the standards track but=20 > it does have very clear operational advice on what the=20 > problems of using UDP are. >=20 > The draft does not change in 3261 the protocols a UA, Proxy,=20 > or Registrar need to implement. This would be a very=20 > difficult thing for us to get consensus on and I see no need=20 > to get consensus on a change here to move this document=20 > forward *soon* in a way that meets everyone needs. >=20 > Until it shows up in the directory, you can find it at: >=20 > http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip- > outbound-07.html > http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip- > outbound-07.txt >=20 > Now more on the big hot item: >=20 > Bit of history on this - we have had this as an open issues=20 > slide at countless IETF meetings. I thought we had closed it=20 > a few meetings ago but one of the authors reopened it. Then=20 > at a later meeting we took a big hum to close it once and for=20 > all and it was a the usual big room full of people and we had=20 > a pretty strong hum towards use the same thing for both UDP=20 > and TCP. Then very recently on the list, the chairs took a=20 > poll on the subject. The poll had very few responses but were=20 > overwhelming in favor of using CRLF. I counted 12 =20 > people in favor of CRLF. (Jeroen, Ekki, Elwell, Aki, Markus,=20 > ALfred, =20 > Miguel, Hisham, Francois, Byron, Mac, Fredrik). =20 > Unfortunately, none of the people that were proponents of=20 > STUN in the wg hum commented on the most recent poll. >=20 > So where does this leave us. Well luckily for me, it leaves=20 > the issue firmly in the lap of the chairs to determine=20 > consensus and I just have to edit the document. My personal=20 > view on the topic is that 12 people is no where near enough=20 > to overturn the huge hum however given the strong direction=20 > of the recent poll, it may however be enough for the chairs=20 > to decide this is an "Open Issue". If it is an open issue,=20 > then I suspect the only place to get strong enough consensus=20 > to overturn the previous hum is in the next WG meeting. I'll=20 > work with the chairs in trying to find out what they want to do here. >=20 >=20 > Cullen >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 08 02:41:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3p7u-0006BQ-Nc; Mon, 08 Jan 2007 02:41:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3p7t-0006BG-Qo for sip@ietf.org; Mon, 08 Jan 2007 02:41:01 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3p7o-0003sP-Cq for sip@ietf.org; Mon, 08 Jan 2007 02:41:01 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B2C25FB0; Mon, 8 Jan 2007 08:40:53 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 08:40:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Date: Mon, 8 Jan 2007 08:40:52 +0100 Message-ID: <7374777208BDC7449D5620EF9423256701474EFA@esealmw113.eemea.ericsson.se> In-Reply-To: <3C9795FE-4BE9-4D30-B7C4-E397BAA320F3@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Thread-Index: AccypuF8Fq0RexULRSCpsQ2RnIbPfQAUN+Sg From: "Christer Holmberg \(JO/LMF\)" To: "Cullen Jennings" X-OriginalArrivalTime: 08 Jan 2007 07:40:53.0503 (UTC) FILETIME=[5359F0F0:01C732F8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Marc Petit-Huguenin , SIP , Francois Audet , Brian Stucker , Juha Heinanen , "Frank W. Miller" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>If so, would it be useful to maintain the TCP connection during the=20 >>whole registration - also in non-outbound cases? >=20 >Nothing to do with outbound but my 2 cents on this is a UA=20 >should try to keep the TCP connection open as long as the=20 >registration (that means forever in most cases or until the=20 >UA reboots or shutdown). =20 >Proxies should try and keep TCP connections open until they=20 >run out of resources then have some algorithm to determine=20 >which connections to kill to clear up resources. >=20 >I suspect most people will give you about the same answer. Yes, people may say that it is how things SHOULD work. But, from what I hear from peoples SIPit experience etc some people seem to do things in a different way. And, at the end what is implemented and deployed is what really matters :) Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 08 03:32:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3puz-0003hU-If; Mon, 08 Jan 2007 03:31:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3pux-0003hF-9n for sip@ietf.org; Mon, 08 Jan 2007 03:31:43 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3pur-0003sN-Rb for sip@ietf.org; Mon, 08 Jan 2007 03:31:43 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 08940692; Mon, 8 Jan 2007 09:31:29 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 09:31:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TCP connection establishment [was: RE: [Sip] Question aboutPoll:Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Date: Mon, 8 Jan 2007 09:31:26 +0100 Message-ID: <7374777208BDC7449D5620EF942325670147524F@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP connection establishment [was: RE: [Sip] Question aboutPoll:Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Thread-Index: AccyrjUoq3UvdAj/QvqlleEVOC4rXwAUJ+oQ From: "Christer Holmberg \(JO/LMF\)" To: "Cullen Jennings" X-OriginalArrivalTime: 08 Jan 2007 08:31:28.0815 (UTC) FILETIME=[6489CBF0:01C732FF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 >Irrelevant side comment but ... oddly, I am perfectly willing to wait >2 seconds for a phone post dial delay but waiting even one=20 >second for my web page drives me insane. Most people on this list probably care more about the protocol itself than the delays. But, the majority of people think the other way around, I would assume :) Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From adamh@future-shapers.com Mon Jan 08 03:39:30 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3q2U-0006ki-Ge for sip-archive@lists.ietf.org; Mon, 08 Jan 2007 03:39:30 -0500 Received: from 82-40-121-141.cable.ubr01.pert.blueyonder.co.uk ([82.40.121.141] helo=bandp-83d375233) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3pyX-0004ug-5k for sip-archive@lists.ietf.org; Mon, 08 Jan 2007 03:36:29 -0500 Received: from 83.244.130.24 (HELO mailforward.lcn.com) by lists.ietf.org with esmtp (W3'+>M32' .+'4) id ,(,YO,-ZM-=7F-/R for sip-archive@lists.ietf.org; Mon, 8 Jan 2007 08:35:28 +0000 Message-ID: <01c732ff$f342f790$6c822ecf@adamh> From: "Keisha Lyon" To: Subject: OEM Windows and Office Software - Question. Date: Mon, 8 Jan 2007 08:35:28 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C732FF.F342F790" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2905 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2905 X-Spam-Score: 3.4 (+++) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C732FF.F342F790 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C732FF.F342F790" ------=_NextPart_001_0010_01C732FF.F342F790 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To run, as in the time of the bee, seekingBefore those virile women!Come, s= wallows, it's good-bye.She stretches a hand toward the toothy sleeperOut of= the picture of life, as it were, outgiddy as good kids playing hookey. Now= ,and turn it into something cartoon-funny.By what it seems to have moved to= ward. In anyAs if your human shape were what the stormTo run, as in the tim= e of the bee, seekingAnd so I gaze avidlyOf too much truth to do much more = than lievisitors' dugout. The osprey whose nest is atopWould their world no= t remain comfortablyLike an old soldier, wakeful, in his tent!XII. The Myst= ery of the Missing Ships: The Franklin SearchAs if your absence now conclud= ed long ago.And I would likeMerely a mockery of spring ------=_NextPart_001_0010_01C732FF.F342F790 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
To run, as in the time of the bee, seeking
Before those virile wome= n!
Come, swallows, it's good-bye.
She stretches a hand toward the too= thy sleeper
Out of the picture of life, as it were, out
giddy as good= kids playing hookey. Now,
and turn it into something cartoon-funny.
= By what it seems to have moved toward. In any
As if your human shape wer= e what the storm
To run, as in the time of the bee, seeking
And so I = gaze avidly
Of too much truth to do much more than lie
visitors' dugo= ut. The osprey whose nest is atop
Would their world not remain comfortab= ly
Like an old soldier, wakeful, in his tent!
XII. The Mystery of the= Missing Ships: The Franklin Search
As if your absence now concluded lon= g ago.
And I would like
Merely a mockery of spring
------=_NextPart_001_0010_01C732FF.F342F790-- ------=_NextPart_000_000F_01C732FF.F342F790 Content-Type: image/gif; name="tnup.gif" Content-ID: <006901c732ff$f342f790$6c822ecf@9D3712C> Content-Transfer-Encoding: base64 R0lGODlhMAPxApEAAAAA/////wAAAAAAACwAAAAAMAPxAgAC/oyPqcvtD6OctNqLs968+w+G4kiW 5omm6sq27gvH8kzX9o3n+s73/g8MCofEovGITCqXzKbzCY1Kp9Sq9YrNarfcrvcLDovH5LL5jE6r 1+y2+w2Py+f0uv2Oz+v3/L7/DxgoOEhYaHiImKi4yNjo+AgZKTlJOSFQeSWguakZwbkZ8PnZINpp cBlaWiqx6jl6SirqoEqbStvKKstw28orexurG3rqy5kLOoscjKrgu1x8gIuwWvxajXy9UD29rV3L bQxLnH1smuB8Hm6p7i2Mmaz83M48nx5vS4+fD57P3myO7x/AgMva2eIHztVAfwgF2tt3MNq9hw/7 TWQo8JU3/mKxOGaUVpAiv4ESmcVjd4+hv5UYCY5bmLKly4Ql96mcuHFYzG8lxx3zOU/jO3kPhNYM 6bChyKVK7SU9mhFpulRMqRbF2TKrRZIeX0qlCfUfBJ7cyoqV+NHdV7QjIYrr6tVs2KlN59qdiVEr yYt7cVpNFg3oS2knuTrtmdbw0LazZt6Na7CuXZk3uQKk7FfrsKqb1z7WLBmuXrcRH//dZdJo4a1g B6tFbXihvl3Top7jDNfx3bzKRtcL3Tc2acGp2wpdPby0blWLi+quzduyX7amUWLeCdGc0ZG/A8Oy eRGe4u0rvU82/1xmbpS1G3NvvRN+9uRz6fUbrK295K32/vVD5hxdasJJB5N0tr3VGWzoFXfWf8od KBiCzbEy20YBfjQWbnipxxJWNQ13oX5uqReUeBB2xt9tCFamGHp4+VfOYREqdxJqMS6oYoUwnthd gin26CBkvp24XYL/9Weijy5S59h1P0o4YYbPbRZiaM1oaF2LTZJn2mcpjTUdbMmxmCORYvKYX1P0 XXUZcvWFmZtUIL63pIZqJsljlUNW9Rp4l1EwyppybTkedh9G6Ql+V6aHnaBY9kaiaq/pKKaf9tFH YkVsFnipnCM2eoE6WoL5pEtZjumoqHMeuqOdYbW4p5faZYYVX0UqNWpFjp5GKGkdCpjphMAuyiin u8p6/imckvYZKZkzArkpqoY+++qA/B0bF5ykMqVqm1rmmi2smtZpZUNhVrmfm2guB5JI2qa1Dp/T /fphsEMBe1+QvWK777hEGefttyxO6iqG4l17qz63/sovWaFaiqu6HZWTsJE6Sospc18tjFyplOLm cL3vwusKhByqywuiaR4JHKgWQONvpZVCqqyzD0J7cLRLzUvzmXQCig24CnJLc7Ig7hrOuSVaXDBB 56ITFMcpe+YagaiMnNhVPk9ZrdVCV2K0f+h+fKPUAj9tTbO2drop0DVPG+ebWytagaoaWB1xwICt M6t7GGJMKoM+V8y1u5mqbfPXJNs487sh/6yyj0mD/uxy3UXP9/bZxhBO3pdt8625x756TqS93GZg bd5hT3wjlK3OBvjnrncN68jdah443EyDznProG8buYuTtxxcwx3jXNenQeNupuy+Q1ve3Lvb7DaS L4+u95G9V//67Ao7P/fRAWMv6Kni52twfXfryyuev7MZvPCd4x3z8/PXLtvgJ9NPbrkyrxU9ICnP UthiT/fKtCJvyehmg1KI9VaUM/eFr0wMk97GnITA5NXogPkCjUIeVj5+QYKAaBqbA0vIs75sDYPI k+AJLVi4punLdF3aXQYll6wFPs1y4uof+2r4QxxCrIUASqFFpMchv72FVj+5XqpE+AgSUs5rzknX /toAqLxyxep5L8SZ6ewVoDHZaVTAQMyMVsO69+XEe2aE4RhXB7kgWjF1DWzjD2snIgN9sEGRaY0P m4M5L9IKj8QrniADWUiqubCLVvqi7QZ5tEflrnN1PA0hubdGNjKJiOzj1NL8V0jMseYp1ZGWeYQT uEOKkljxQ+QUz8fHUtZqlJ9k4IMy50QoxkeR6+olu6CXuXZZpVBxqyT4NpSxY+ZJd5ADIySHyCpq Ue83VxvdIh3kJO3ET2Hoqxooyhi14jErjN+q1yTPRzCAKU5kz0gYOHWVzbXBrHFmU6Yx6fkNYb7u nd7MZ8iuMcBxfjOf5oQnPxu3N05a0nHp3KZD/h8K0TNAMaIUrahFL4rRjGp0oxztqEc/CtKQinSk JC2pSU+K0pSqdKUsbalLXwrTmMp0pjStqU1vitOc6nSnPO2pT38K1KAKdahELapRj4rUpCp1qUxt qlOfCtWoSnWqVK2qVa+K1axqdatc7apXvwrWsIp1rGQtq1nPita0qnWtbG2rW98K17jKda50ratd 74rXvOp1r3ztq1//CtjACnawhC2sYQ+L2MQqdrGMbaxjHwvZyEp2spStrGUvi9nManaznO2sZz8L 2tCKdrSkLa1pT4va1Kp2taxtrWtfC9vYyna2tK2tbW+L29zqdrestCvGDnqwQs2znxqrGwg1/lLN 4QYXncBdWWKmFtxcOvCd5JiucLsBUFFqU1enfFzV2qndHoIXa/Ujrjhzydx1epShnpQgC+k2Rydi MprYfG8QzQc8UmYJftRinNDwq0G0eYx4RQxOgOOLxGdmER6MtNx3jKWW5fGtv95FKXuliEI6IjiW e2ywHU1YLPL50pbt3eQCbUmXYi4ze4/inyQbScs22mpdIE5nxtZEQ7kkV50KtOPQpKnPlF64lnec 5SphLF8PfxiSb9Sw/zKTpwve2I8wvJ0F7VvKF89wWBwGcZAusbD8XpO/KDIaYVgcjDnm+KOEm9Jx spnhUj1wuqlMaCeP979X/mtHKpGymId8/qAtunOaJjndgmrlpRVft4N50Zk9yWw9PdY3dh/GaZtH Y2YXjs2AmkxfnknR4kx7xstkc+OntYXGOu+MyXHc8BINnUAPwXdJA3MvfTV5afJCJdKMmzQs72RT MCPOU8xLJLBDVWogSihWw44zbdocQ3+hWmKjLlqCi32eCc6MWH1SNPhE7UNh4xK9Nux1r9x7OZom l9IG4xy9Ciy4lxVZ13eeVTC9TZto65sx00Zzla3dI3fr7romNg54v424B6rGPc1GL9JEJ+BVQ5uk +Bpz2u6tphDRe4mYPm7AE24yytxaoVlj5OGuiKzy1q9bIREwpiPe6p9dq3sV52W0nigv/vw9qcIm hWMLLx46g75840L8tBpnLXBxBrnoj16uyfsNbl9j2OjN5WboyMnqkccMw756MtFdk4uQYztpVS+p z3sJ9N/m3JAormK91avcZI+8gs49OdyXrj0yejfuckd6z/SHY30WN8BBr5M1QF3DNcNTa92xO5e5 y1Joop3sGN/Nu9uXqFcazxRmUzu8bTLiNXPe8aDcN+UX7Wi5rfCJg76fymUusxFNXr2Ly6TQKbY/ 2mNU8k0efeW3TO2GxXnzNX/93I3cTTnmON3uI30XO596bMqpekZkZtLnfCjZ974DQQaX4u2+Uu2a +lTHDOOxLUFkOYaP1MAXv+Fz77aY/r9J797Hc+hR3j9O95ZVAYX3t9vpXFpXOOVzZ0dngH1kYVAT alGHb1u3QX9kdUUycYQ3dc7maXynbH4Efj5Gcv3iaQ3oPfqHIi0nZRXIJxEkdFt0Q0aybuZGZjwU dio1QG60LCI2fE8mJTRGb9M0bzN4gaa2b2fUb1TWgTzYgx04gAXnND6YclemTEz4RvnWXZ/SRElW MkK2SOa3fTfYJeVUbcryebMHhdH0a0h4S4WhX7niTOclhkiIGUoIKT/WhNAjZmxEaqg0hbaXZhx2 Ygw0URSlc7z3dshTa0hmZx94XwNGNncoT0o4axnYQNQmGiFUf1RkgSNmiEAmIAg4/ogldIWOuIhM 9GPxdk9zqGcrGFIuVzr014cZx4P7g4LLRIjR0Yqu+HdGB4lmxEwe8V+PZC0LxoG5SD1vFnVGxmBE 2HaTiE4ZRoKYp2JcY4Rg12kdJVCBgoEIhU8RBlAAeHv09FxKF07LNXjVeDsNVXuOGCzNdVAE030V ll151GfSyGMHF45+Q44DVV3Y6IKlV2JOx1v/WAV/CJADSZAFaZAHiZAJqZALyZAN6ZAPCZERKZET SZEVaZEXiZEZqZEbyZEd6ZEfCZIhKZIjSZIlaZIniZIpqZIryZIt6ZIvCZMxKZMzSZM1aZM3iZM5 qZM7yZM96ZM/CZRBKZRDSZRF/mmUR4mUSamUS8mUTemUTwmVUSmVU0mVVWmVV4mVWamVW8mVXemV XwmWYSmWY0mWZWmWZ4mWaamWa8mWjSWQYJVeeLd42ViD1zhegZGPPCaXcVlGwOAwuvCO1uUd/EQN tZBd62aX8qeXjQJcgTl49HiYEMZz7JQ7nwgmuBh9zwVSUFcwlyd2LqZ+FCiaV/Y2e5h3ayc+IGia 57aapzl//ndzvTg+q+hkUleZwIQ/xieAZyFuNudjErZHCvZ1KsOZr+dlryiKSkYjxjiLL5hi9RWG ++hmU3ZikfJx8qJl40WJvFdjyfmIiPhlYKib39kgOwZ5CJdDL4h8w0mc9Od+/lrEnGsnnT/nb6ZY iigmiIoocs2ZhYrYKiK4HNm5RubYfjDGdrHUUOI2hjFEQHOygWU2l+gJSpJodZvZcA5YfZfIMhDI oGdnitgXc/l5igGoPn/EG50ZcFF2fmKkmB+adSW6bEmogtZ5G0n0oCAabcQYY6uIimx2oTIHfyO6 oZ12aQZ6ZBC0Z03Xiaiof56HQDTamcWJpPPVn/UZnn8iPMnWCTMqntChGc6Ho9ZJfvDZj2/ZSn1n Xz8aYrDGRXX3ojDqHBPnfJ6obbjXW1A6oVJabsoppFyKpfmWFUsKRKDnZuoXKHz6YP6GZeVIcYmI en33McjZN7wjXaoEiu2x/oY31n8cFIfUp3Nul6fueal1+IUeeqWkqCISKKjKtyiqqm8EmoTI5J+s yU2puJtwBqk12GqUR32VGmr9lSPQNqfNA3g81HosGqWimoykSpr92IRK82WyJIgZ9HhTuJ3KujJj 2oVwM5mASKbkg5iZqYDq1KvGanzdynRKCo2kE07r9Dh4OqhQN4Hz+XH4R548V3wcV5sMym0B5Ehq GmtyBnPhgq4PZao9GK6x6IHm8jXzal6fuqzpOmaJ1xufQ3SPya/3p6zDiTVVd428inhDOp0HKoWH 9qdBWKs0uGENR07UqIOPen3RWS3likm5NqlKZKh6Gmiyo3spO6icNKc9/tuwHbs8xSZeLyKtocdK TbqD9XSn63lhFeOwxPmy4Eqet6aFInub85V0BwQlwwqEh+o8f3hmXpismuq1h6hqqia1D+im2PCr KEpBw5OLlAkgmCh6Q6hR7/mtoTqtOpq2MkQ0A7unfKtQw4a2HEougIuzyqenIuSuRDubdRqAdLuq GQsjlouy4mBCdpm3rLi34/p2DAibGDpnTmo/afqkots0iLu2ycekFHpDAMume0pra4ueTtZNCFO1 Sru60Zi5BZqCaANCMZhRCzqyzmpsptu4mFi6vgS7joutvhmr86mtJRuv07t/JGq7/zqt1Wsxroeb yEprwJulmtig7bh5/vFyvJqGfG3IhUW2tSVbiJPHqRA7saH5hmlEZdCqsYmrh98IwLhbavv7tdFI iyHLZ+YrGhyYjsTLh79pGaGrsMcZnzJbgIhqpRLonYHomw9qT2fDiYUKhDnqndmIqJqng7MLmva5 uCNswoVWTA+8r2uqohelioRXh4QrUM5reVWbn7eYfsr2wFwEcsEYjyUMth2Krt5LdfbKNBdspNvr OlJMTSpms99Lq4tjppJwj9vIO4tGmGDsqZIpTwoKM19sZveToL/FuvAor8LJmAPzxg8rjmJMx44Z YSlIXO1aj/KDsRHKx8SWTBkol22JWF2MyIvMyI3syI8MyZEsyZNM/smVbMmXjMmZrMmbzMmd7Mmf DMqhLMqjTMqlbMqnjMqprMqrzMqt7MqvDMuxLMuzTMu1bMu3jMu5rMu7zMu97Mu/DMzBLMzDTMzF bMzHjMzJrMzLzMzN7MzPDM3RLM3TTM3VbM3XjM3ZrM3bzM3d7M2ZrMg6yZcIg8YYqL7QNbyTIgz4 oqOiF5tzfJj0iHvb1bwic8jg6bd0ea2WOZ4O27aw2lo6KyPB56yLakQr5mqCW4uuApyuqcPoVpq5 G8bE5IzDFF7CejX4CbUL5osUFsizJdBzi50ufKpH+pw3A8X3eYxKSoosIaQt5pzjG3jC1CaZpHS5 Npjg+I1pSJ3o/qt4qBXSYnPDWNZ+37vBWjxRgBayIrqtLRyMT40sqFJQMlYgGlh2pdHSzDLVEaI2 asaeo9W1SsTUx2rUnqlwiEY5d7PEwTrUuBqvCgvEOLssVp2ecQO6SkKHQFrVfha4tRXWCkyfhDu6 bEq64RseG5DFoAq9QXq14Ua7/rxLQljX05O4YarUWyyfigvSaNql4zdufXt+51m++bM+f429DP3Z rwpq/2yDR6et10uv2ZfCeTerlze1rNWCNsduLaqrp9ap+rh63Ce95CuGnnfbmCrYLVqdEgPbEXyO JSzZtc2tAB3Qt9rZs/h764oygQhzPWutZXja32rcP62vBIeZ/q352rKr0lsN3WeovJNxOeRNWgeL uTR4xE09PgnnG/IdsPkL3v18ekkN2kPMv7I6f1IdxuqKec1ti+aFW/QNr3FdwRm6a2pI0wWrwIwd 3vg93hw74Pg8wultpaNacoerYSy7nrdV1mZr39nt1qbCes5y3IZt3oDdex2ueytutcbb4LSttnZq 4ndsXTlMWzqu2BKepC8OoP5Y4V+H1Nd9444240Z+3hEs4vRd0bEJtA8XuXctW4bLqhaX2kcY2vtk 299H4BHudWN3sUNM1PR65fCJOsIb22aYs+GMWXyn5uLtvr9YuzIsQPY30ewI5WuOv5Cqzyat3F8r HzG2QxSC/txOfbsrHX/8DFvIu+cUW+NGOqsQGujGYlzYTdxni0Vw929+noNi02NUHUmQnodox71Q 3Zo/Xt1fWM+GXqrpZ8ADomipck3+q8QH3c89aoQYPY6rztUUzeObCMStF8ASnB1FvoxYksIW7NQe 5Icku5ulyMGxQcAa6nXc7pmG/E9s85yX1GGoWtRO+9LR+uUefMMKHtmf3toHPtlRbUpJuhuzLdkE vNdP/N7titYULTA1i8UM08PXBq6AfulsjHWaSqDnrI5kXGZ5XLSEbvEBFUzGTkMYq8bdMOTsHuzH Jce+RxYnV3o++807hecr7/IvD/MxL/MzT/M1b/M3j/M5/q/zO8/zPe/zPw/0QS/0Q0/0RW/0R4/0 Sa/0S8/0Te/0Tw/1US/1U0/1VW/1V4/1Wa/1W8/1Xe/1Xw/2YS/2Y0/2ZW/2Z4/2aa/2a8/2be/2 bw/3cS/3c0/3df/KLb+UHy3IsS6OOZ2YBufH5xSBGgPyAnzkCV7e2zDGkYnCwO2pxjrtVa7vAEOS WTzTBtjb2z7u2/6dhLaLKb9xzI1m6h3dW0jvlR6xnIfSvhcZkuvR92yRlt9hIfzeKhhiEM+flvem cliFughxE9rrol6E/95r5pnsjm7h9+5NJZmgr5r82BO3Hy6P+WHBKuy8unaiB7wXwG/9y4u38/4U 8UbQ/lh+/OmL9wWpoI3heLuNoG9K1jWqNOhyus/0/eSV/TROqGHO6RgM4MQf/nBMALElL/WCXUTQ 0SVx1pt3/8FQHMnSPNFUXVlPeJgXU+IulrPbjurZmn6S3kXngzV4P9wjiWw6gcvc0EW9aKzCoFAL XVizxan3udxWKOYvtAc+r6VUaYtet9/xef2e389F/47meAQHAXfQyASfOMAOuRa71LDeIhMNibIo wzY0LxslN+O2POEahyqjXgzdGloxLR/F/GhrbW9xc3XrZGavShEey0g85YALK1RnhE0nOit9j3tT Jak/nxWvrn2UgnyrT2usb1i908yzYy3JYXfd3+Hj/uXnQZmZ7JOVwUc0X9tncXDC1yZdqWipAh67 pBDftkAOhzWD808hOxDkuI1yhQ7Wq4kM6YUUOZJkSREJvUlcpnIiMY5zvkUMpk9bP3YdoXnEAjEc xp4/O4Ua48Rfz3aq0pUZZAwJU4pEz908apJqVatXdZlRwjPfQJBKLe4TNUmYVjIEcWY7WJCrUWrS 3grNaFZj0pjVrH2EacEpy4x+C03FOphwYcMl6HZVp9jeXaCOHdO8V5YrqrSY1mKWGyLsUKA7GQ1N vNCojWl5F+7trDcp68uCD8eWPZsw3V6hV/KMLKrl3NLakE32ShQbZp25AVeB/DYubrHqdkdv+jXw /uXPnMe1pr2de/d5dWcmXxoGtfO7cNmEBr/ZumfnjCU/lLn5b9D3EMnbZW6bc0P//3kLx7sBCSzw nbq8KEYqUqhjJqbIHEmNPsoUU5BBRRYcJ8D6NpSvocyem7CJ+xg7LS3TYBuxCgNZbNFFPFRL8I1y zirPLwuNSzDExXgEDscYPUwODfc4JDLIH0k0KLv1PERpExQR086ZF6ms0sr+5huouB0J0c0mtUjZ 8UvjKhsTORGH5GZLAUFLMr/xwGyNo2e6mlHOGtlM5Mwr+ezzSjiLnFI0NAUdrsZDl1JTRAXdxJDB 4k7sYs1Ju1z0DBwDpUTFJ8ND9DrxLg3Tz1FJ/nURUPoQwjSJTONbY1NIXgXszfeAaQXSW12ltMPw UM2pIDakBCLXNach1L9ZRQuo1GWZ3W414aqDwKfU7JzWtRgdPc9aaBeMViqkbhpLh229fYhcapd8 MMNsn6U2yq/aRe8oYLVrt9l78c1X3335VSHFfgEOWOCBCS7Y4IMRTljhhRlu2OGHIY5Y4okprtji izHOWOONOe7Y449BDlnkkUku2eSTUU5Z5ZVZbtnll2GOWeaZaa7Z5ptxzlnnnXnu2eefgQ5a6KGJ Ltroo5FOWumlmW7a6aehjlrqqamu2uqrsc5a66257trrr8EOW+yxyS7b7LPRTlvttdlu2+23/uGO W+656a7b7rvxzlvvvfnu2++/AQ9c8MEJL9zwwxFPXPHFGW/c8cchj1zyySmv3PLLMc9c880579zz z0EPXfTRSS/d9NNRT1311Vlv3fXXYY9d9tlpr93223HPXffdee/d99+BD1744Ykv3vjjkZfn3yrD RREte6P9Zd1goVcKOLxynH4V7ast4tttuq1uLu5hq77572UVI3uAvJ/erebBhd95X7X3Vv6Prkeq JvTBghRRaOa3G3FJb10fECCXpjCok9SqeisQoLbihCBaMZBeOSpTBXclrG5AZX0I9BRexjDBX2FQ TIySlJBadYQiPXCDJOyNkXrEoxZOaIav/kJWryKYLWwY0EYndFALX1MeV6gwT7kS4kZodK4WsLB7 MByWoZwoQxkBCU2McmGhLKUWVikRWotR1wcbpZlYEVFX+WvMfqgIxS020QigGiM6fJg+MFovSGOM Ig9Vcx8lNfALBNTVBpWjJ+wtjx8Q6pGZQtiWG+JwPCRSoxa6KJA79iOK25tRFq+oRzZWKn3zgxUm y7iOTQoJkZB0YydR6aUILuM8RQylchp5wVgGJk8J+SMH54XLQe7Bkh055IUo4siiKNArpCEmS5SV RjPKck9aCg4nP2QZ+ilTVpaCJVnWOEI4oSSJWTImfny0lXDiKZXI3KOOngmfb77SeW2U/mOi1qko 4XTQnE/RCDT90Mty/LKC8xLmSyj1oHhqMj28aksoKbnFF+YPSSm8UajOwiXByAGhqQKjqhZKw5Tw iqLjjGhGDQodCsIEpK+B5bs++k482pOjf+jLQUVKnFuYKBAYBZBBbRrDsnxjNBmMEDvHQoifLiqe 1AQfGkPUS3zScqm+6WIYKzoddjnyoQVlzwA5SS5qyuuT0dgJEwnJ1BJBdKJoXIULYnGcQEkzWA5M IU1X2KBo4tKetmFXXc2Ty7YiEzoZnOdQjyUOeW21r+MLqzjaaaxS2lQ6c+ojh7RpUa6CNEv8UedM KtJDd/kVJHnhIgF7+p/j8HGJNwIV/l1dMsd0OjV+rD2mKPVKSEd0tJLzMWpLGjvFOKRVXHtFYVVZ mlfV5pZJbJTsOUc60Mra1lyTTe1ydHsRKX2Wm/iRLG74B6OMVjeumo2pbvGKLgni6lqJXSBfJNIe fKqPUOMarFi4+1TXFDJdyhVuJnn6XvEmkbg/Yqx+GYoK+Tj3uV+0LA+xUwzr6jKgUbmfHUIbWocc cJAGDi9YDvxaaZr3vMqSBUKdeltlEBey6Q2gbzP74N52L7sO3S5fpkpG/+WQrPbdbogHjFQUPDh8 Ce6wqM4o1di+07f8mLAigfhcF5M4Wdy88E45nODbNCO4TR1XewVr1vqMpnyfdS2r/lYa5tXaOD7G IBL1qKvVJJM3pCPeU3L9tS25mpK+4iRyZ1VM2dL2hkn3lS2MWfybJru4zBsF6k/AU+XLXpmq7tXy XxItZSGOGaaf2hAE9ePYZdL2mpG9IpM3jdhPita7g/6taUwQFhFX+o6C1O41+rzgP6MWzCrh728X KV9W8ybSIE4WloVsaVP0upmUzg2clXxSPRPYQUYSI3w1rGknro+kCNTps21baiye5BDu82uU5XkH BIl4mFL2prEpBFlk81XYK8UWuHU95oaiO4b5Rci3YQXdsOpU1ttUL7uvWqdL76rcmTIphvVtn2Kn VduRVDhmHdxiV58XwXl49z+j/tvhKtJvVd3NXq3xrWyqVrOM8663jkce43osW9t4zjiwtynm5p65 m6r8+Khp2GolacrjqV44t4xYwETSV7p6uDiSwbvyIKvWukMPLNPhLV2oJwlKYYx1pUvpTjvinJ/7 dvnRD5p1dk7H6Tok6M2bOvF45zRNWlf7nO1Hp/2hPdyP5ZTa20yHU2E85jwncjbzGMdHjrzVgax7 bVENVVC68omHl3EdKQ13fv998cZCMt5lDNHKK3JFdv9yNHco+Dn3eOi2/LbYVZp2Fuwd6XTfdtdp tHX2WRDzp7Z84t0+7Tsx0pVH9Psxl/TayYe89bGv/U2Xvk6ANv7pW3+8O4+b/k02A7POfGzD623u 02l6WNxyRriJlMjjFoefuvg78YrvlGdEJBD9+rTLteDlZa57/thgBWKWSVtewwLzrjT2b4bqRKD0 5/tMzbDqQc1UjXwUTs4kbv8YIv9eSu5sL/+SpwIRZt8sMAM1cAM5sAM98ANBMARFcARJsARN8ARR MAVVcAVZsAVd8AVhMAZlcAZpsAZt8AZxMAd1cAd5sAd98AeBMAiFcAiJsAiN8AiRMAmVcAmZsAmd 8AmhMAqlcAqpsAqt8AqxMAu1cAu5sAu98AvBMAzFcAzJsAzN8AzRMA3VcA3ZsA3d8A3hMA7lcA7p sA7t8A7xMA/1cA/5sA/9/vAPATEQBXEQCbEQDfEQERFgMFAIg0j9DLDJ7od8GnE1eoz0+gcSLVEv 3C2Z0CcTNdEBKQxdzGhawG7G+mkqQhH5rE2jeghCKJB26gvrpM3PDM6z1oyUOE6VJgy/LGoXVwmG /gs1Ck5YbI0CXVGviLHz2mqIUC7oyuo0MFF4YtG+UC/5/knkivEXNw8GJoiZDq+GwKwacy0c6SWO GtDa0u/42o4bO+8eRumJgo/5okca08/fYA7wrhHe2IqzcjGkJOmcrAkXp86LagzfwLHthGy6AKjq AASQaon+5koWJWwegSe3gA+5tpHTULEgTy7piMmowC+oyiTs+E8kUw/k/tixmHDq69qE4DJNHZMR m+bqnlxyt5LHIl3rGG9LrWSykgDN9eht3c6tnlKqI0tRhPpuFTkqoQqP6qKMgmAyEmQSIEny024y KPuR38bxuy4rquKLFRXtHm9JkozS8tTqtFBRQlQv/oqyJunuvehprbIStopsduBK557nyQjy5VCM I6lSzwDT5L7MfOYS1KTofwoMzVLEq7CxLE+Ni4TyL2VB/m7HyQwyLwVtpwpSsxZJMukN3QQzqaDH Mw1zKz8TEvFI47oSKTvkATENRKqyuByxMmNTJA3TfvqPM28xfrLrNosvM3mzwiIRwBhumlCKhepM 9e6rNYXR3oItG/8t/i8p0y5rU4Fucxilsi/zjDSJk+/0kjUabflMMu6A88d6MTnz7tKyki0jkCsb 8ifH53fIzTg/EzaLCsbQM+q+6zvRkj8/8enGazzlKhULkM5UM96ikTn3ihRn8RzFi810Zz5ziNBW a0wiLD/bbT/Lsz83dLMcEzAlY0Alz0PX8ccQtDGXU9KQ6Op2jfCejzYlaj2b0VAu9EAz1DRRyDNR 5SPnUitnUeYuQvjqcthSYN0aBK7O0kVvr+FOx9u8k8y2cvamUj/D0yMLDyMJTj21EUST9Jq4bdrm j9eKNB3lEZqQ9Eej0vFyD0a38cW2lPJEi0qrs0rDkk4N9KjeFEBv/q8p7xTgVpNPGTL0krElJwPQ qjS1im53/o1GxdLqSFJOBTIpzfK6dK/sevRDbe/zssr49M/cTiBUbGj35i4b765E36gtK/PgTlLx wJJFU/LQItUn61HYviTcdHTwMhXkOMhWHbRUMdScTFWeTA8eoU4cgQx3ok/WAvVFofPlJrA58/Tt FLJeyvEiXfXaqhUlwc1KM88T29FGNQn7hKJYToj6gHH7lskunVMSlxEy62e/GshbK/EcIbBXxWcB pZRB1W807dUUm8sfXrHjPFUClZRES0hUkS9gExF5FnFhHfZhITZiJXZiKbZiLfZiMTZjNXZjObZj PfZjQTZkRXZk/km2ZE32ZFE2ZVV2ZVm2ZV32ZWE2ZmV2Zmm2Zm32ZnE2Z3V2Z3m2Z332Z4E2aIV2 aIm2aI32aJE2aZV2aZm2aZ32aaE2aqV2aqm2aq32arE2a7V2a7m2a732a8E2bMV2bMm2bM32bNE2 bdV2bdm2bd32beE2buV2bum2bu32bvE2b/V2b/m2b/32bwE3cAV3cAm3cA33cBE3cRV3cRm3cR33 cSE3ciV3cim3ci33cjE3czV3czm3cz33c0E3dEV3dEm3dE33dFE3dVV3dVm3dV33dWE3dmV3dmm3 dm33dnE3d3V3d3m3d333d4E3eIV3eIm3eI33eJE3eZV3eZm3/nmd93mhN3qld3qpt3qt93qxN3u1 d3u5t3u993vBN3zFd3zJt3zN93zRN33Vd33Zt33d933hN37ld37pt37t937xN3/1d3/5t3/9938v p2EBOGIEeIAfpoANuGEQmGsBoIEdGAAy4IElGIIdYIIpOII1wII12IEDYIMnGAQseAVCOIM9+IM7 eIQ5AIU9QIMP4IIlQIUjgIU7IIQXOGs5uIIbmIRzWIdTeIdf2IdPGIhv2AAeOIaLWIddOIiTGISH mIib+IeB2ImjWIJn+IiZeIqtuIWfOIuN+IkxgIrTVW25WIqXWIlTuIrL+IS7OImF2IvN+IvdeIzR uIzlmIwj/piN6xiH3RiJ7xiPo9iO4XiP9RiIa7hq83iM85iI0RiD1/iFB7mPl/iQBTmQ0/iNoTiN sTiRITiRG7mPHxmSKfmPK9iST9RsJfmPObmSyZiOL9mRtViUSVmJKxmM53iW5TiLXZiNYzmGdxmU N8CHafmSI7mXW5iUC3lqg7mVPzmDe3iSl9mXlfmVYRmQa/mX47iJc5mXk1mLiXmNVVmRV9maUVmW 79iY4zaVt9iZVXmTOZmaobmTpbmZvzmexZmOsfmX3XmUu/mZmTmfo7mYiZmCs/iYo3abvZmfXZmR 23mfAxqb0dmZybmeI3mIp7mDw9mV29mgkfibk1mgb9md/gkaajVamnNZnfs5outZnin5oCW6mlu6 kyf5ghGZnl/6A0b6ogF6l2W6iUP6aW8apRl6lhH6n1d6kCdanTP6oVFZhhkZqC3an4U5BH66o0ma l0Eabqcal026qRk6qEvYnpEaorPai484pp+5pCsap1dYqXWZpp/6qt92rNs4rTGZqO0apk+ZrpM6 rJcamNf5rIeapW2ara3andHahXvaaeX6sM/4i+86sGlaoxfbpTf6n/+6qt8aqgV7rfm6rS/ajxH7 nPkanrk6p406pVFbrSGbmplaqYsanEu7rEmbj6V6tAsbkEH7T01Zk9OZrkOZqV/7nZ1ateG5tXlb lHH5/rZBu6/nebhrOrhhe5WPOrSxOq9zG58Tera1W7vrOK9re5q726xNm7gXuqu3G6qne7p1e7fB +5ov+7Yf26uZG6xtOa3Pu6HbW59Pe7aRO5Uh+6M3G65Fu79hubvh+LlXu5cN+pYh+q69+8D1W4+D m8ErOpPpu7SlOLgTu6B7e53JOpAR3K2hG7OhuItPoLdVmr9B3LIFGZHr28RPWsL/ecOldoMH24S9 Ob2t2INz3MXD+6ev+Li/eodheLnB2L6Be6Pbm6qNmoppHJnL23OeHMobXMrjesixPMu1fMu5vMu9 /MvBPMzFfMzJnMtLWWzLPM3VfM3ZvM3d/M3hfMjP/jxs47zO7fzO8TzP9bzL5zyBL2bK/ZxfAF1p wY/7+mB5zgqtdG2ivhQxHD09QcOXCNXnwrTRIf1TN3zQI30NDd0dawHRz9yfIOxTH73PL/3U/eXn SJ0XDh0eOr0MO33KitMsLqhQ0esnA8/TY7IrZd3W79LEpMXBMuETLInkbgO9rufYVU5aXEXZJ5PW uQAct0c97AzimiIfpj0TOBEQuA/au40dX30Mp1TXMQvbf6FEHmsSrp0J4EnXZf3d7UPdz72rBCXR 5+n1htXeHc4dPezVyXXfg8H0BN7Q7R3eBbbX/91H/FGozF166OzftaImJP7eZQrVt3DcEX4lqg2n /hq+3BUe56as2v6hpQC+QlqK4PMO5Xsy5BsennqS4efd40++0l++1z++3TP+3p9K3hX+rPR949k9 q9DQrkCLwcjI+2Ke3HV+vWSeCBCBLJCdjtTAyWx+4gOep5r+2Gtq0Zg96RG+fbzd5KkMOaq+UEme 54V+6YPe5zcFI2zS4rXw5ZVe4LpE0rOe5NtM5P1R3zUePsq+3YM+780lGUZe6YvF5dUpmTre8B9u 4a3+7xef8G8+8s/e5NmeFRz/481Q7iGfoSAd7Rl/FCGh6sPd60e/maZe9I9N8uO98h1/5Vn/7tUe 5Old5wG/7APf9ilf93t+7bfeTNf74hfN9cHd/vQDkPhnv1M8vt/D+N0N/vZnHvnpPuD9Xvb9He/3 x9Y7JeepX+b3IuaHqPYxH+W1f+eZf/I5/u7tHtaHXzN9vdbjC5suBPzXvem3v+ClSi6mfkVD7eed KecJQHkY5mkvEpKl6aRRruE4/RZVW6dB4HWKC0Zaz5l9FLrSINvdd6j6PzAoHBKLxiMyqVwym84n NCrdTatWY6933XK73m8MLA6Py+YzOq1en7XstyoLn9PrQ7d9ic/z+/4/oNheINoM4SEilGEi0SDj I2Sk5CRlpeUlZqbmJmen5ydoqOgoaanpKWqq6iprq+srbKzsLG2t7S1uru4ub6/vL3Cw8DBx/rHx MXKy8jJzs/MzdLT0NHW19TV2tvY2d7f3N3i4+Dh5ufk5err6Onu7+zt8vPw8fb39PX6+/j5/v/8/ wIACBxIsaPAgwoQKFzJs6PAhxIgSJ1KsaPEixowaN3Ls6PEjyJAiR5IsafIkypQqV7Js6TKYo5cy Zw6LSfMmzlw2c/Ls+Wqnz6BCSwEdavTopqJIlzKNpLQp1Kh/nkqtavUN1atatwri6vUrnKxgx5JV IrYs2rRAzqpt65at27hl4cqt65Wu3bx69/Lt6/cv4MCCBxMubPgw4sSKFzNu7Pgx5MiSJ1OubPky 5syaN3Pu7Pkz6NCiR5Mubfo06tSqV7NuMu36NezYsmfTrm37Nu7cunfz7u37N/DgwocTL278OPLk ypczb+78OfTo0qdTr279+sICADs= ------=_NextPart_000_000F_01C732FF.F342F790-- From sip-bounces@ietf.org Mon Jan 08 03:51:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3qD0-0003WV-9Z; Mon, 08 Jan 2007 03:50:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3qCz-0003WQ-2n for sip@ietf.org; Mon, 08 Jan 2007 03:50:21 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3qCx-0000Wq-I2 for sip@ietf.org; Mon, 08 Jan 2007 03:50:21 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EAE4E4F004F; Mon, 8 Jan 2007 09:50:16 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 09:50:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Date: Mon, 8 Jan 2007 09:50:16 +0100 Message-ID: <7374777208BDC7449D5620EF9423256701475385@esealmw113.eemea.ericsson.se> In-Reply-To: <45A177DE.6090102@lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Thread-Index: AccyrXEdl4avwIjWQty+67BdjpuIpwAUuMKg From: "Christer Holmberg \(JO/LMF\)" To: "Vijay K. Gurbani" , X-OriginalArrivalTime: 08 Jan 2007 08:50:16.0731 (UTC) FILETIME=[04D41EB0:01C73302] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Vijay, It's a good document, and I don't think the main issue is that we would have to design something new. I think it's more about how people have understood the specs and implemented things. However, the draft does not talk about re-using registration TCP connections. No, it may not forbid it either, but maybe it would be good to add some text and/or example flows about that case also into chapter 4, together with the INVITE ones? Maybe also some text in chapter 8, talking about keeping the connection alive during the whole registration (and not only say that the connection should not be disconnected together with the dialog) would be useful. Regards, Christer =20 > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com]=20 > Sent: 8. tammikuuta 2007 0:45 > To: Christer Holmberg (JO/LMF); spencer@mcsr-labs.org > Cc: SIP > Subject: Re: TCP connection establishment [was: RE: [Sip]=20 > Question about Poll: Proposal relating to keepalive, TCP, and=20 > UDP usage in draft-ietf-sip-outbound] >=20 > Christer Holmberg (JO/LMF) wrote: > > Since this issue is not outbound specific, I propose we start a=20 > > separate thread for it. > >=20 > > I believe I have also seen (and not only at SIPit) clients that=20 > > establish TCP connections per transaction. [...] > >=20 > > If so, would it be useful to maintain the TCP connection during the=20 > > whole registration - also in non-outbound cases? >=20 > and Spencer Dawkins further wrote: > > Whatever the final guidance on connection lifetime turns out to be,=20 > > SIP over TCP is likely to work better if we write it down=20 > fairly soon=20 > > ... and I don't think more than an Informational document is needed. >=20 > There is already a document that discusses TCP connection=20 > maintenance (i.e., reuse) orthogonal to the outbound case. > The document is connect-reuse-07, > http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reu > se-07.txt, > although lately, it always seems to be hanging under the=20 > sword of Damoclese. >=20 > The document itself is ready, has been implemented, and does=20 > talk about the distilled wisdom in client and server TCP=20 > socket management (see S8). It is an aggregation from the=20 > original work some of us did as a loose design team in TCP=20 > connection guidelines([1], which has since expired and=20 > portions subsumed in connect-reuse), and Rohan's connection=20 > alias draft, before outbound came into the picture. >=20 > Please read it, and if this does not satisfy your=20 > requirements, I would be more than glad to start a dialog to=20 > accommodate them to an agreed consensus. Given the=20 > regularity with which TCP connection reuse gets asked on the=20 > list, it would be a shame to jettison the current work on it. >=20 > [1] Vijay K. Gurbani, Chris Boulton, Rajnish Jain, and Cullen=20 > Jennings, "Guidelines for implementors using=20 > connection-oriented transports in the Session Initiation=20 > Protocol (SIP)," IETF Internet-Draft, February 2005, expired.=20 > Available at=20 > n-guidelines-01.txt> >=20 > Thanks, >=20 > - vijay > -- > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Bell Laboratories, Lucent Technologies, Inc. > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 08 07:10:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3tJN-0001RC-9j; Mon, 08 Jan 2007 07:09:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3tJM-0001Qz-89 for sip@ietf.org; Mon, 08 Jan 2007 07:09:08 -0500 Received: from sip.tutpro.com ([192.98.100.10] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3tJ7-0006F2-HN for sip@ietf.org; Mon, 08 Jan 2007 07:09:08 -0500 Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id DFC251EC63D; Mon, 8 Jan 2007 14:08:47 +0200 (EET) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BV39DByFlaB8; Mon, 8 Jan 2007 14:08:43 +0200 (EET) Received: from rautu (adsl1500-91.dyn98.pacific.net.sg [202.42.98.91]) by tutpro.com (Postfix) with ESMTP; Mon, 8 Jan 2007 14:08:43 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 7648FF0163; Mon, 8 Jan 2007 13:28:41 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17826.10985.248535.174979@rautu.test.fi> Date: Mon, 8 Jan 2007 13:28:41 +0200 From: Juha Heinanen To: Cullen Jennings Subject: [Sip] Update of outbound In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: SIP , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen Jennings writes: > I counted 12 > people in favor of CRLF. (Jeroen, Ekki, Elwell, Aki, Markus, ALfred, > Miguel, Hisham, Francois, Byron, Mac, Fredrik). you can add me to that list too (lacking tcp keepalive support in ua tcp stack). > If it is an open issue, > then I suspect the only place to get strong enough consensus to > overturn the previous hum is in the next WG meeting. the mailing list needs to be the authority that determines consensus, not the meeting that is attended only by those who can afford it. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 08 07:22:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3tW6-00079X-Dq; Mon, 08 Jan 2007 07:22:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3tW5-00079R-HY for sip@ietf.org; Mon, 08 Jan 2007 07:22:17 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3tVz-0001jW-Mp for sip@ietf.org; Mon, 08 Jan 2007 07:22:17 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EB5F754D; Mon, 8 Jan 2007 13:22:06 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 13:22:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Update of outbound Date: Mon, 8 Jan 2007 13:22:06 +0100 Message-ID: <7374777208BDC7449D5620EF94232567014B6FAF@esealmw113.eemea.ericsson.se> In-Reply-To: <17826.10985.248535.174979@rautu.test.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Update of outbound Thread-Index: AcczHhqvp2CUdz0IR/ulE3oCLFpxTAAALQLA From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" , "Cullen Jennings" X-OriginalArrivalTime: 08 Jan 2007 12:22:06.0432 (UTC) FILETIME=[9C669600:01C7331F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: SIP , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 >>I counted 12 people in favor of CRLF. (Jeroen, Ekki, Elwell, Aki,=20 >>Markus, ALfred, Miguel, Hisham, Francois, Byron, Mac, Fredrik).=20 >=20 >you can add me to that list too (lacking tcp keepalive=20 >support in ua tcp stack). >=20 >>If it is an open issue, then I suspect the only place to get strong enough=20 >>consensus to overturn the previous hum is in the next WG meeting. >=20 >the mailing list needs to be the authority that determines=20 >consensus, not the meeting that is attended only by those who=20 >can afford it. Well, then we don't need any hums in the future, do we? :) Seriously, I do agree, but I (and I am sure others too) have received comments saying that "there was a concensus in this-or-that IETF meeting", without the issue really even being discussed on the mailing list. In some cases things have been discussed on the list, and have even got some support, but then being turned down at the meeting. So, does that mean that all decissions made at meetings should be agreed also on the list after that? Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 08 10:37:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3wXs-00033Y-Dp; Mon, 08 Jan 2007 10:36:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3wXq-00031K-QW for sip@ietf.org; Mon, 08 Jan 2007 10:36:18 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3wXp-0002Vr-EU for sip@ietf.org; Mon, 08 Jan 2007 10:36:18 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 08 Jan 2007 07:36:15 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l08FaEIP014738; Mon, 8 Jan 2007 07:36:14 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l08Fa2Iv011685; Mon, 8 Jan 2007 07:36:13 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 10:36:04 -0500 Received: from [10.86.242.10] ([10.86.242.10]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 10:36:04 -0500 Message-ID: <45A264E3.4090200@cisco.com> Date: Mon, 08 Jan 2007 10:36:03 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF9423256701474AA1@esealmw113.eemea.ericsson.se> <45A177DE.6090102@lucent.com> In-Reply-To: <45A177DE.6090102@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jan 2007 15:36:04.0070 (UTC) FILETIME=[B4F93860:01C7333A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2260; t=1168270574; x=1169134574; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20TCP=20connection=20establishment=20[was=3A=20RE=3A=20 [Sip]=20Question=20about=20Poll=3A=0A=20Proposal=20relating=20to=20keepali ve,=20TCP,=09and=20UDP=20usage=20in=20draft-ietf-sip-outbound] |Sender:=20; bh=NY2uWfVqeXeVC/tWJ7lVY/e5s4+6vregSxpKW9qRaL8=; b=yh1hESDLNbP2aWVZkUhp3Jdlejbt8AptrvrD/p/hvgSXtZapM56Ek03RZphfpUZUAh0hh+qe XOm35ajrAbR0/W9D+TQPj77OfdztbVIY614pKVAxEmOcwuNbN++/ZCAo; Authentication-Results: sj-dkim-5; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: SIP , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vijay K. Gurbani wrote: > There is already a document that discusses TCP connection > maintenance (i.e., reuse) orthogonal to the outbound case. > The document is connect-reuse-07, > http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-07.txt, > although lately, it always seems to be hanging under the sword > of Damoclese. > > The document itself is ready, has been implemented, and does > talk about the distilled wisdom in client and server TCP socket > management (see S8). It is an aggregation from the original > work some of us did as a loose design team in TCP connection > guidelines([1], which has since expired and portions subsumed in > connect-reuse), and Rohan's connection alias draft, before outbound > came into the picture. It hasn't always been clear in this thread what kinds of usage connection reuse that is assumed. I get the impression that some of the people talking in this thread think that sip-outbound is needless complexity and that connection reuse is enough, even in the presence of NATs. The doc referenced above is quite clear that TCP connections can only be reused for *requests* by the end that established the connection - if requests are to flow in both directions then there must be a separate connection established in each direction. This is needed to prevent hijacking by bad guys. When a NAT is involved it won't be possible to establish a connection in the reverse direction. For typical deployments it seems unlikely that connection-reuse will be sufficient. Paul > Please read it, and if this does not satisfy your requirements, > I would be more than glad to start a dialog to accommodate > them to an agreed consensus. Given the regularity with which TCP > connection reuse gets asked on the list, it would be a shame > to jettison the current work on it. > > [1] Vijay K. Gurbani, Chris Boulton, Rajnish Jain, and Cullen > Jennings, "Guidelines for implementors using connection-oriented > transports in the Session Initiation Protocol (SIP)," IETF > Internet-Draft, February 2005, expired. Available at > > > > Thanks, > > - vijay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 08 10:40:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3wbb-0004b8-6K; Mon, 08 Jan 2007 10:40:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3wbZ-0004b2-Pw for sip@ietf.org; Mon, 08 Jan 2007 10:40:09 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3wbX-0003UQ-Ch for sip@ietf.org; Mon, 08 Jan 2007 10:40:09 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 08 Jan 2007 10:40:08 -0500 X-IronPort-AV: i="4.13,159,1167627600"; d="scan'208"; a="111094423:sNHT54016564" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l08Fe7cr002610; Mon, 8 Jan 2007 10:40:07 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l08Fe62s012905; Mon, 8 Jan 2007 10:40:06 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 10:39:49 -0500 Received: from [10.86.242.10] ([10.86.242.10]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 10:39:49 -0500 Message-ID: <45A265C4.1010107@cisco.com> Date: Mon, 08 Jan 2007 10:39:48 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF9423256701475385@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF9423256701475385@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jan 2007 15:39:49.0267 (UTC) FILETIME=[3B338E30:01C7333B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4178; t=1168270807; x=1169134807; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20TCP=20connection=20establishment=20[was=3A=20RE=3A=20 [Sip]=20Question=20about=20Poll=3A=0A=20Proposal=20relating=20to=20keepali ve,=20TCP,=09and=20UDP=20usage=20in=20draft-ietf-sip-outbound] |Sender:=20 |To:=20=22Christer=20Holmberg=20(JO/LMF)=22=20; bh=EyqemafJWnLwROzCj7Q9gvQ2fa0HlisihwLwDCcHh3U=; b=rjRLMx4OMa088LjRtgNSGJ4akGMLb2XOV9ERm3rq/XUmmTDKjbh6Aa489H41uiu+/oMfCFYi rLkD6x8PuhoNqqALG/HBn5OkGJ/e6PILgrGzgySkdOXlJtX3DXaMCAHZ; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > Hi Vijay, > > It's a good document, and I don't think the main issue is that we would > have to design something new. I think it's more about how people have > understood the specs and implemented things. > > However, the draft does not talk about re-using registration TCP > connections. No, it may not forbid it either, but maybe it would be good > to add some text and/or example flows about that case also into chapter > 4, together with the INVITE ones? Maybe also some text in chapter 8, > talking about keeping the connection alive during the whole registration > (and not only say that the connection should not be disconnected > together with the dialog) would be useful. Are you suggesting that a *registration connection* can be used bidirectionally? One of Rohan's versions of connection reuse attempted to piggyback on registration to authenticate the connection for use in the opposite direction. IIRC that what found to have a number of security holes and so was given up, in favor of using outbound for that. Paul > Regards, > > Christer > > >> -----Original Message----- >> From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] >> Sent: 8. tammikuuta 2007 0:45 >> To: Christer Holmberg (JO/LMF); spencer@mcsr-labs.org >> Cc: SIP >> Subject: Re: TCP connection establishment [was: RE: [Sip] >> Question about Poll: Proposal relating to keepalive, TCP, and >> UDP usage in draft-ietf-sip-outbound] >> >> Christer Holmberg (JO/LMF) wrote: >>> Since this issue is not outbound specific, I propose we start a >>> separate thread for it. >>> >>> I believe I have also seen (and not only at SIPit) clients that >>> establish TCP connections per transaction. [...] >>> >>> If so, would it be useful to maintain the TCP connection during the >>> whole registration - also in non-outbound cases? >> and Spencer Dawkins further wrote: >>> Whatever the final guidance on connection lifetime turns out to be, >>> SIP over TCP is likely to work better if we write it down >> fairly soon >>> ... and I don't think more than an Informational document is needed. >> There is already a document that discusses TCP connection >> maintenance (i.e., reuse) orthogonal to the outbound case. >> The document is connect-reuse-07, >> http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reu >> se-07.txt, >> although lately, it always seems to be hanging under the >> sword of Damoclese. >> >> The document itself is ready, has been implemented, and does >> talk about the distilled wisdom in client and server TCP >> socket management (see S8). It is an aggregation from the >> original work some of us did as a loose design team in TCP >> connection guidelines([1], which has since expired and >> portions subsumed in connect-reuse), and Rohan's connection >> alias draft, before outbound came into the picture. >> >> Please read it, and if this does not satisfy your >> requirements, I would be more than glad to start a dialog to >> accommodate them to an agreed consensus. Given the >> regularity with which TCP connection reuse gets asked on the >> list, it would be a shame to jettison the current work on it. >> >> [1] Vijay K. Gurbani, Chris Boulton, Rajnish Jain, and Cullen >> Jennings, "Guidelines for implementors using >> connection-oriented transports in the Session Initiation >> Protocol (SIP)," IETF Internet-Draft, February 2005, expired. >> Available at >> > n-guidelines-01.txt> >> >> Thanks, >> >> - vijay >> -- >> Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} >> Bell Laboratories, Lucent Technologies, Inc. >> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 08 13:35:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3zKW-00024S-IR; Mon, 08 Jan 2007 13:34:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3zKU-00024I-TN for sip@ietf.org; Mon, 08 Jan 2007 13:34:42 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3zKQ-00036R-BI for sip@ietf.org; Mon, 08 Jan 2007 13:34:42 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A59C14E0; Mon, 8 Jan 2007 19:34:29 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 19:34:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Date: Mon, 8 Jan 2007 19:34:28 +0100 Message-ID: <7374777208BDC7449D5620EF94232567014E07CA@esealmw113.eemea.ericsson.se> In-Reply-To: <45A265C4.1010107@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Thread-Index: AcczO0l9ysTi0YLOSMSryYMMHLC5JAABIHSg From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 08 Jan 2007 18:34:29.0307 (UTC) FILETIME=[A1CAC0B0:01C73353] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Paul,=20 >>It's a good document, and I don't think the main issue is that we=20 >>would have to design something new. I think it's more about how people >>have understood the specs and implemented things. >>=20 >>However, the draft does not talk about re-using registration TCP=20 >>connections. No, it may not forbid it either, but maybe it would be=20 >>good to add some text and/or example flows about that case also into=20 >>chapter 4, together with the INVITE ones? Maybe also some text in=20 >>chapter 8, talking about keeping the connection alive=20 >>during the whole registration (and not only say that the connection should not be=20 >>disconnected together with the dialog) would be useful. >=20 >Are you suggesting that a *registration connection* can be used bidirectionally? That is one of the options presented earlier in the thread, yes. That is how outbound works, and my understanding of Vijay's commant was that connection-reuse can be used for that non-outbound cases. If not, I missunderstood Vijay, or he missunderstood me :) >One of Rohan's versions of connection reuse attempted to=20 >piggyback on registration to authenticate the connection for=20 >use in the opposite direction. IIRC that what found to have a=20 >number of security holes and so was given up, in favor of=20 >using outbound for that. So, you are saying that connection-reuse can only be used to reuse dialog initiated TCP connections, and that registration initiaded connections are only used for registartion purpose? Regards, Christer >=20 > Paul >=20 > > Regards, > >=20 > > Christer > > =20 > >=20 > >> -----Original Message----- > >> From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] > >> Sent: 8. tammikuuta 2007 0:45 > >> To: Christer Holmberg (JO/LMF); spencer@mcsr-labs.org > >> Cc: SIP > >> Subject: Re: TCP connection establishment [was: RE: [Sip] Question=20 > >> about Poll: Proposal relating to keepalive, TCP, and UDP usage in=20 > >> draft-ietf-sip-outbound] > >> > >> Christer Holmberg (JO/LMF) wrote: > >>> Since this issue is not outbound specific, I propose we start a=20 > >>> separate thread for it. > >>> > >>> I believe I have also seen (and not only at SIPit) clients that=20 > >>> establish TCP connections per transaction. [...] > >>> > >>> If so, would it be useful to maintain the TCP connection=20 > during the=20 > >>> whole registration - also in non-outbound cases? > >> and Spencer Dawkins further wrote: > >>> Whatever the final guidance on connection lifetime turns=20 > out to be,=20 > >>> SIP over TCP is likely to work better if we write it down > >> fairly soon > >>> ... and I don't think more than an Informational document=20 > is needed. > >> There is already a document that discusses TCP connection=20 > maintenance=20 > >> (i.e., reuse) orthogonal to the outbound case. > >> The document is connect-reuse-07, > >> http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reu > >> se-07.txt, > >> although lately, it always seems to be hanging under the sword of=20 > >> Damoclese. > >> > >> The document itself is ready, has been implemented, and does talk=20 > >> about the distilled wisdom in client and server TCP socket=20 > management=20 > >> (see S8). It is an aggregation from the original work=20 > some of us did=20 > >> as a loose design team in TCP connection guidelines([1], which has=20 > >> since expired and portions subsumed in connect-reuse), and Rohan's=20 > >> connection alias draft, before outbound came into the picture. > >> > >> Please read it, and if this does not satisfy your requirements, I=20 > >> would be more than glad to start a dialog to accommodate=20 > them to an=20 > >> agreed consensus. Given the regularity with which TCP connection=20 > >> reuse gets asked on the list, it would be a shame to jettison the=20 > >> current work on it. > >> > >> [1] Vijay K. Gurbani, Chris Boulton, Rajnish Jain, and Cullen=20 > >> Jennings, "Guidelines for implementors using connection-oriented=20 > >> transports in the Session Initiation Protocol (SIP)," IETF=20 > >> Internet-Draft, February 2005, expired. > >> Available at > >> >> n-guidelines-01.txt> > >> > >> Thanks, > >> > >> - vijay > >> -- > >> Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > >> Bell Laboratories, Lucent Technologies, Inc. > >> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > >> > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 08 13:40:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3zPZ-00050X-Su; Mon, 08 Jan 2007 13:39:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3zPY-00050S-KV for sip@ietf.org; Mon, 08 Jan 2007 13:39:56 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3zPX-0004TT-4r for sip@ietf.org; Mon, 08 Jan 2007 13:39:56 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7E5E3C4E; Mon, 8 Jan 2007 19:39:52 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 19:39:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Date: Mon, 8 Jan 2007 19:39:51 +0100 Message-ID: <7374777208BDC7449D5620EF94232567014E07D3@esealmw113.eemea.ericsson.se> In-Reply-To: <45A264E3.4090200@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Thread-Index: AcczOr6tKzvxifIHSZGaSjL4MZvNHwAGRfUg From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" , "Vijay K. Gurbani" X-OriginalArrivalTime: 08 Jan 2007 18:39:52.0140 (UTC) FILETIME=[623728C0:01C73354] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >> There is already a document that discusses TCP connection=20 > maintenance=20 > > (i.e., reuse) orthogonal to the outbound case. > > The document is connect-reuse-07, > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-07.tx > > t, although lately, it always seems to be hanging under the=20 > sword of=20 > > Damoclese. > >=20 > > The document itself is ready, has been implemented, and does talk=20 > > about the distilled wisdom in client and server TCP socket=20 > management=20 > > (see S8). It is an aggregation from the original work some=20 > of us did=20 > > as a loose design team in TCP connection guidelines([1], which has=20 > > since expired and portions subsumed in connect-reuse), and Rohan's=20 > > connection alias draft, before outbound came into the picture. >=20 >It hasn't always been clear in this thread what kinds of=20 >usage connection reuse that is assumed. I get the impression=20 >that some of the people talking in this thread think that=20 >sip-outbound is needless complexity and that connection reuse=20 >is enough, even in the presence of NATs. Well, if you use connection-reuse with TCP keepalive you will solve the NAT issue, won't you (assuming the connection is bidirectional)? But, you will not have the multiflow feature that outbound provides. >The doc referenced above is quite clear that TCP connections=20 >can only be reused for *requests* by the end that established=20 >the connection - if requests are to flow in both directions=20 >then there must be a separate connection established in each=20 >direction. I am not sure I understand. Isn't the re-use per direction (unidirectional usage of a connection) already specified in RFC3261? The connection-reuse drafts, as far as I understand (I'm sure Vijay can give more details :) defines the bidirectional usage of a connection. Regards, Christer This is needed to prevent hijacking by bad guys.=20 > When a NAT is involved it won't be possible to establish a=20 > connection in the reverse direction. >=20 > For typical deployments it seems unlikely that=20 > connection-reuse will be sufficient. >=20 > Paul >=20 > > Please read it, and if this does not satisfy your requirements, I=20 > > would be more than glad to start a dialog to accommodate them to an=20 > > agreed consensus. Given the regularity with which TCP connection=20 > > reuse gets asked on the list, it would be a shame to jettison the=20 > > current work on it. > >=20 > > [1] Vijay K. Gurbani, Chris Boulton, Rajnish Jain, and Cullen=20 > > Jennings, "Guidelines for implementors using connection-oriented=20 > > transports in the Session Initiation Protocol (SIP)," IETF=20 > > Internet-Draft, February 2005, expired. Available at=20 > >=20 > > ines-01.txt> > >=20 > >=20 > > Thanks, > >=20 > > - vijay >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 08 15:12:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H40qR-000341-9m; Mon, 08 Jan 2007 15:11:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H40qP-00033w-Ue for sip@ietf.org; Mon, 08 Jan 2007 15:11:45 -0500 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H40qN-00015e-OE for sip@ietf.org; Mon, 08 Jan 2007 15:11:45 -0500 Received: from s73602 (failure[218.104.123.2]) by comcast.net (sccrmhc14) with SMTP id <20070108201142014003g17oe>; Mon, 8 Jan 2007 20:11:42 +0000 Message-ID: <010101c73360$baaaa110$867b68da@china.huawei.com> From: "Spencer Dawkins" To: "SIP" References: <7374777208BDC7449D5620EF94232567014B6FAF@esealmw113.eemea.ericsson.se> Subject: Re: [Sip] Update of outbound Date: Tue, 9 Jan 2007 04:08:09 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: sob@harvard.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Christer Holmberg (JO/LMF)" "So, does that mean that all decissions made at meetings should be agreed also on the list after that?" Yes, precisely. This is required in our WG BCP, RFC 2418. Scott Bradner graciously pointed me to 3.2. Session venue Each working group will determine the balance of email and face-to- face sessions that is appropriate for achieving its milestones. Electronic mail permits the widest participation; face-to-face meetings often permit better focus and therefore can be more efficient for reaching a consensus among a core of the working group participants. In determining the balance, the WG must ensure that its process does not serve to exclude contribution by email-only -> participants. Decisions reached during a face-to-face meeting about -> topics or issues which have not been discussed on the mailing list, -> or are significantly different from previously arrived mailing list -> consensus MUST be reviewed on the mailing list. The last sentence is the relevant part. Thanks, Scott, for helping me find this during jet lag! Spencer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 08 15:50:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H41Rc-0003Ai-QO; Mon, 08 Jan 2007 15:50:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H41RU-0002pI-NX; Mon, 08 Jan 2007 15:50:04 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H41RS-000149-S2; Mon, 08 Jan 2007 15:50:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id CC8A532932; Mon, 8 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H41RS-0004vV-LD; Mon, 08 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 08 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-uri-list-message-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP) Author(s) : M. Garcia-Martin, G. Camarillo Filename : draft-ietf-sip-uri-list-message-01.txt Pages : 18 Date : 2007-1-8 This document specifies a mechanism that allows a SIP User Agent Client (UAC) to request a SIP URI-list (Uniform Resource Identifier list) service to send a SIP MESSAGE request to a set of destinations. The client sends a SIP MESSAGE request that includes the payload along with the URI-list to the MESSAGE URI-list service, which sends a similar MESSAGE request to each of the URIs included in the list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-uri-list-message-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-uri-list-message-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-uri-list-message-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-8125829.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-uri-list-message-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-uri-list-message-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-8125829.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Mon Jan 08 15:51:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H41SJ-0003uZ-Ix; Mon, 08 Jan 2007 15:50:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H41Ry-0003Ip-1p; Mon, 08 Jan 2007 15:50:34 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H41Rx-0005v1-Hq; Mon, 08 Jan 2007 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 10C1817600; Mon, 8 Jan 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H41RS-0004vS-Kf; Mon, 08 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 08 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-multiple-refer-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Referring to Multiple Resources in the Session Initiation Protocol (SIP) Author(s) : G. Camarillo, et al. Filename : draft-ietf-sip-multiple-refer-01.txt Pages : 15 Date : 2007-1-8 This document defines extensions to the SIP REFER method so that this method can be used to refer servers to multiple resources. These extensions include the use of pointers to Uniform Resource Identifier (URI)-lists in the Refer-To header field and the "multiple-refer" SIP option-tag. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-multiple-refer-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-multiple-refer-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-multiple-refer-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-8125640.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-multiple-refer-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-multiple-refer-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-8125640.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Mon Jan 08 15:51:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H41SX-0004WY-54; Mon, 08 Jan 2007 15:51:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H41SS-0004Mz-8g; Mon, 08 Jan 2007 15:51:04 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H41SR-0005vk-VI; Mon, 08 Jan 2007 15:51:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 3383E17606; Mon, 8 Jan 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H41RS-0004ve-N4; Mon, 08 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 08 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-outbound-07.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Managing Client Initiated Connections in the Session Initiation Protocol (SIP) Author(s) : C. Jennings, R. Mahy Filename : draft-ietf-sip-outbound-07.txt Pages : 42 Date : 2007-1-8 The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections and send asynchronous UDP datagrams to User Agents in order to deliver requests. However, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs), prevent servers from connecting to User Agents in this way. This specification defines behaviors for User Agents, registrars and proxy servers that allow requests to be delivered on existing connections established by the User Agent. It also defines keep alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-outbound-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-outbound-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-8130222.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-outbound-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-outbound-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-8130222.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Mon Jan 08 16:06:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H41hI-0000i0-Nb; Mon, 08 Jan 2007 16:06:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H41hG-0000hU-Vh for sip@ietf.org; Mon, 08 Jan 2007 16:06:22 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H41hE-0007f4-AL for sip@ietf.org; Mon, 08 Jan 2007 16:06:22 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 08 Jan 2007 13:06:19 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l08L6JqJ013954; Mon, 8 Jan 2007 13:06:19 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l08L68JD022683; Mon, 8 Jan 2007 13:06:19 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 16:06:07 -0500 Received: from [10.86.242.10] ([10.86.242.10]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 16:06:06 -0500 Message-ID: <45A2B23E.8070903@cisco.com> Date: Mon, 08 Jan 2007 16:06:06 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF94232567014E07CA@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF94232567014E07CA@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jan 2007 21:06:06.0568 (UTC) FILETIME=[D02E9E80:01C73368] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5682; t=1168290379; x=1169154379; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20TCP=20connection=20establishment=20[was=3A=20RE=3A=20 [Sip]=20Question=20about=20Poll=3A=0A=20Proposal=20relating=20to=20keepali ve,=20TCP,=09and=20UDP=20usage=20in=20draft-ietf-sip-outbound] |Sender:=20; bh=LJ6XBiGaSBmgH2qK/6P31XNkK+uLDM4pB+qq9RpL6bU=; b=mhmCZdew1GoFb+QAlJ7uom0FgIrw1xjdVpYhjDh0wnQ2YNUssY/esOHCgragGk4KTqXr3+Yy bFho6MiP1VAK+H9yR8BrYb3y/PjJqVK4XwrCktYwmB6QZuW6Z9l5I9au; Authentication-Results: sj-dkim-8; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > Hi Paul, > >>> It's a good document, and I don't think the main issue is that we >>> would have to design something new. I think it's more about how people > >>> have understood the specs and implemented things. >>> >>> However, the draft does not talk about re-using registration TCP >>> connections. No, it may not forbid it either, but maybe it would be >>> good to add some text and/or example flows about that case also into >>> chapter 4, together with the INVITE ones? Maybe also some text in >>> chapter 8, talking about keeping the connection alive >>> during the whole registration (and not only say that the connection > should not be >>> disconnected together with the dialog) would be useful. >> Are you suggesting that a *registration connection* can be used > bidirectionally? > > That is one of the options presented earlier in the thread, yes. > > That is how outbound works, and my understanding of Vijay's commant was > that connection-reuse can be used for that non-outbound cases. > > If not, I missunderstood Vijay, or he missunderstood me :) AFAIK the connection can be established any time and used for any requests send in the direction that the connection was established. It doesn't matter whether the first request is REGISTER, INVITE, or something else. >> One of Rohan's versions of connection reuse attempted to >> piggyback on registration to authenticate the connection for >> use in the opposite direction. IIRC that what found to have a >> number of security holes and so was given up, in favor of >> using outbound for that. > > So, you are saying that connection-reuse can only be used to reuse > dialog initiated TCP connections, and that registration initiaded > connections are only used for registartion purpose? No, I'm not saying anything about dialogs. I am saying that once you have established the connection in one direction you believe you know who you have connected to, and so can continue to use that for other requests to the same direction. But a server that accepts an incoming TCP connection cannot ascertain the source of that connection and so can't use it to originate requests in the opposite direction. The situation is different for TLS. That is why the connection reuse draft specifies how/when a TLS connection can be used in the reverse direction. Paul > Regards, > > Christer > > > > > > > > >> Paul >> >>> Regards, >>> >>> Christer >>> >>> >>>> -----Original Message----- >>>> From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] >>>> Sent: 8. tammikuuta 2007 0:45 >>>> To: Christer Holmberg (JO/LMF); spencer@mcsr-labs.org >>>> Cc: SIP >>>> Subject: Re: TCP connection establishment [was: RE: [Sip] Question >>>> about Poll: Proposal relating to keepalive, TCP, and UDP usage in >>>> draft-ietf-sip-outbound] >>>> >>>> Christer Holmberg (JO/LMF) wrote: >>>>> Since this issue is not outbound specific, I propose we start a >>>>> separate thread for it. >>>>> >>>>> I believe I have also seen (and not only at SIPit) clients that >>>>> establish TCP connections per transaction. [...] >>>>> >>>>> If so, would it be useful to maintain the TCP connection >> during the >>>>> whole registration - also in non-outbound cases? >>>> and Spencer Dawkins further wrote: >>>>> Whatever the final guidance on connection lifetime turns >> out to be, >>>>> SIP over TCP is likely to work better if we write it down >>>> fairly soon >>>>> ... and I don't think more than an Informational document >> is needed. >>>> There is already a document that discusses TCP connection >> maintenance >>>> (i.e., reuse) orthogonal to the outbound case. >>>> The document is connect-reuse-07, >>>> http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reu >>>> se-07.txt, >>>> although lately, it always seems to be hanging under the sword of >>>> Damoclese. >>>> >>>> The document itself is ready, has been implemented, and does talk >>>> about the distilled wisdom in client and server TCP socket >> management >>>> (see S8). It is an aggregation from the original work >> some of us did >>>> as a loose design team in TCP connection guidelines([1], which has >>>> since expired and portions subsumed in connect-reuse), and Rohan's >>>> connection alias draft, before outbound came into the picture. >>>> >>>> Please read it, and if this does not satisfy your requirements, I >>>> would be more than glad to start a dialog to accommodate >> them to an >>>> agreed consensus. Given the regularity with which TCP connection >>>> reuse gets asked on the list, it would be a shame to jettison the >>>> current work on it. >>>> >>>> [1] Vijay K. Gurbani, Chris Boulton, Rajnish Jain, and Cullen >>>> Jennings, "Guidelines for implementors using connection-oriented >>>> transports in the Session Initiation Protocol (SIP)," IETF >>>> Internet-Draft, February 2005, expired. >>>> Available at >>>> >>> n-guidelines-01.txt> >>>> >>>> Thanks, >>>> >>>> - vijay >>>> -- >>>> Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} >>>> Bell Laboratories, Lucent Technologies, Inc. >>>> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >>>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 08 16:08:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H41ip-0001Aw-Uj; Mon, 08 Jan 2007 16:07:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H41io-0001Aq-QJ for sip@ietf.org; Mon, 08 Jan 2007 16:07:58 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H41in-0008EO-DB for sip@ietf.org; Mon, 08 Jan 2007 16:07:58 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 08 Jan 2007 13:07:56 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l08L7uxY007564; Mon, 8 Jan 2007 13:07:56 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l08L7cJ3023811; Mon, 8 Jan 2007 13:07:55 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 16:07:46 -0500 Received: from [10.86.242.10] ([10.86.242.10]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 16:07:46 -0500 Message-ID: <45A2B2A1.4010303@cisco.com> Date: Mon, 08 Jan 2007 16:07:45 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF94232567014E07D3@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF94232567014E07D3@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jan 2007 21:07:46.0289 (UTC) FILETIME=[0B9ED610:01C73369] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3183; t=1168290476; x=1169154476; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20TCP=20connection=20establishment=20[was=3A=20RE=3A=20 [Sip]=20Question=20about=20Poll=3A=0A=20Proposal=20relating=20to=20keepali ve,=20TCP,=09and=20UDP=20usage=20in=20draft-ietf-sip-outbound] |Sender:=20; bh=+e/ipFvTPXeZ6CvxxTiPG0ywatQ3Ul96DXssTtPPsvA=; b=ftCssjPNFjXN3r8rLTUQjMj+jO/LDW3h+/Cs635xY3Y50vzEChBOGwo0JZ3danZ62IxFKiCp H0U/DodEd58NvQ5r7nMYr4t2744sbDkSJ8Wu9XRSBIMrN1Kw/F1GLH9k; Authentication-Results: sj-dkim-5; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > Hi, > >>> There is already a document that discusses TCP connection >> maintenance >>> (i.e., reuse) orthogonal to the outbound case. >>> The document is connect-reuse-07, >>> >> http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-07.tx >>> t, although lately, it always seems to be hanging under the >> sword of >>> Damoclese. >>> >>> The document itself is ready, has been implemented, and does talk >>> about the distilled wisdom in client and server TCP socket >> management >>> (see S8). It is an aggregation from the original work some >> of us did >>> as a loose design team in TCP connection guidelines([1], which has >>> since expired and portions subsumed in connect-reuse), and Rohan's >>> connection alias draft, before outbound came into the picture. >> It hasn't always been clear in this thread what kinds of >> usage connection reuse that is assumed. I get the impression >> that some of the people talking in this thread think that >> sip-outbound is needless complexity and that connection reuse >> is enough, even in the presence of NATs. > > Well, if you use connection-reuse with TCP keepalive you will solve the > NAT issue, won't you (assuming the connection is bidirectional)? But, > you will not have the multiflow feature that outbound provides. No you don't because the connection can't be used for requests in the reverse direction. >> The doc referenced above is quite clear that TCP connections >> can only be reused for *requests* by the end that established >> the connection - if requests are to flow in both directions >> then there must be a separate connection established in each >> direction. > > I am not sure I understand. Isn't the re-use per direction > (unidirectional usage of a connection) already specified in RFC3261? The > connection-reuse drafts, as far as I understand (I'm sure Vijay can give > more details :) defines the bidirectional usage of a connection. I'm sure Vijay will chime in here, but it seems clear to me that it does not. Paul > Regards, > > Christer > > > > > > > This is needed to prevent hijacking by bad guys. >> When a NAT is involved it won't be possible to establish a >> connection in the reverse direction. >> >> For typical deployments it seems unlikely that >> connection-reuse will be sufficient. >> >> Paul >> >>> Please read it, and if this does not satisfy your requirements, I >>> would be more than glad to start a dialog to accommodate them to an >>> agreed consensus. Given the regularity with which TCP connection >>> reuse gets asked on the list, it would be a shame to jettison the >>> current work on it. >>> >>> [1] Vijay K. Gurbani, Chris Boulton, Rajnish Jain, and Cullen >>> Jennings, "Guidelines for implementors using connection-oriented >>> transports in the Session Initiation Protocol (SIP)," IETF >>> Internet-Draft, February 2005, expired. Available at >>> >> >> ines-01.txt> >>> >>> >>> Thanks, >>> >>> - vijay > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 08 17:01:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H42Xv-0006Bf-H4; Mon, 08 Jan 2007 17:00:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H42Xu-0006BK-Se for sip@ietf.org; Mon, 08 Jan 2007 17:00:46 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H42Xr-00069o-7k for sip@ietf.org; Mon, 08 Jan 2007 17:00:46 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 431814CF; Mon, 8 Jan 2007 23:00:32 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 23:00:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Date: Mon, 8 Jan 2007 23:00:30 +0100 Message-ID: <7374777208BDC7449D5620EF94232567014E0908@esealmw113.eemea.ericsson.se> In-Reply-To: <45A2B2A1.4010303@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Thread-Index: AcczaRMkYDIQ2jtzQFO80rCLE5psUwABjRzw From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 08 Jan 2007 22:00:31.0692 (UTC) FILETIME=[6A5900C0:01C73370] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Paul, You are right. The connection-reuse bidirectionaltity is for TLS only.=20 Vijay did only talk about TCP in his mail, though. Was that a misstake, or did I missunderstand? So, that means that you can re-use the registration connection unidirectionally (and, in the end the INVITE sent from the client is the critical one, as far a post dial delay is concerned) already using RFC3261. So, again, it's not about defining/using new extensions - it's about how to implement core SIP in a most effective way. But, I still think the registraion clarifications I mentioned earlier would be good for the connect-reuse draft. Regards, Christer=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 8. tammikuuta 2007 23:08 > To: Christer Holmberg (JO/LMF) > Cc: Vijay K. Gurbani; spencer@mcsr-labs.org; SIP > Subject: Re: TCP connection establishment [was: RE: [Sip]=20 > Question about Poll: Proposal relating to keepalive, TCP, and=20 > UDP usage in draft-ietf-sip-outbound] >=20 >=20 >=20 > Christer Holmberg (JO/LMF) wrote: > > Hi, > >=20 > >>> There is already a document that discusses TCP connection > >> maintenance > >>> (i.e., reuse) orthogonal to the outbound case. > >>> The document is connect-reuse-07, > >>> > >>=20 > http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-07.t > >> x > >>> t, although lately, it always seems to be hanging under the > >> sword of > >>> Damoclese. > >>> > >>> The document itself is ready, has been implemented, and does talk=20 > >>> about the distilled wisdom in client and server TCP socket > >> management > >>> (see S8). It is an aggregation from the original work some > >> of us did > >>> as a loose design team in TCP connection guidelines([1],=20 > which has=20 > >>> since expired and portions subsumed in connect-reuse),=20 > and Rohan's=20 > >>> connection alias draft, before outbound came into the picture. > >> It hasn't always been clear in this thread what kinds of usage=20 > >> connection reuse that is assumed. I get the impression=20 > that some of=20 > >> the people talking in this thread think that sip-outbound=20 > is needless=20 > >> complexity and that connection reuse is enough, even in=20 > the presence=20 > >> of NATs. > >=20 > > Well, if you use connection-reuse with TCP keepalive you will solve=20 > > the NAT issue, won't you (assuming the connection is=20 > bidirectional)?=20 > > But, you will not have the multiflow feature that outbound provides. >=20 > No you don't because the connection can't be used for=20 > requests in the reverse direction. >=20 > >> The doc referenced above is quite clear that TCP=20 > connections can only=20 > >> be reused for *requests* by the end that established the=20 > connection -=20 > >> if requests are to flow in both directions then there must be a=20 > >> separate connection established in each direction. > >=20 > > I am not sure I understand. Isn't the re-use per direction=20 > > (unidirectional usage of a connection) already specified in=20 > RFC3261?=20 > > The connection-reuse drafts, as far as I understand (I'm sure Vijay=20 > > can give more details :) defines the bidirectional usage of=20 > a connection. >=20 > I'm sure Vijay will chime in here, but it seems clear to me=20 > that it does not. >=20 > Paul >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > This is needed to prevent hijacking by bad guys.=20 > >> When a NAT is involved it won't be possible to establish a=20 > connection=20 > >> in the reverse direction. > >> > >> For typical deployments it seems unlikely that=20 > connection-reuse will=20 > >> be sufficient. > >> > >> Paul > >> > >>> Please read it, and if this does not satisfy your requirements, I=20 > >>> would be more than glad to start a dialog to accommodate=20 > them to an=20 > >>> agreed consensus. Given the regularity with which TCP connection=20 > >>> reuse gets asked on the list, it would be a shame to jettison the=20 > >>> current work on it. > >>> > >>> [1] Vijay K. Gurbani, Chris Boulton, Rajnish Jain, and Cullen=20 > >>> Jennings, "Guidelines for implementors using connection-oriented=20 > >>> transports in the Session Initiation Protocol (SIP)," IETF=20 > >>> Internet-Draft, February 2005, expired. Available at > >>> > >>=20 > >> l > >>> ines-01.txt> > >>> > >>> > >>> Thanks, > >>> > >>> - vijay > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 08 17:21:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H42qx-0000KK-4E; Mon, 08 Jan 2007 17:20:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H42qu-0000K0-Pv for sip@ietf.org; Mon, 08 Jan 2007 17:20:24 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H42qt-0003Fp-7g for sip@ietf.org; Mon, 08 Jan 2007 17:20:24 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l08MKIwI018055; Mon, 8 Jan 2007 16:20:18 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l08MKHu03466; Mon, 8 Jan 2007 16:20:17 -0600 (CST) Message-ID: <45A2C3A1.8040403@lucent.com> Date: Mon, 08 Jan 2007 16:20:17 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: SIP Subject: Re: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF94232567014E07D3@esealmw113.eemea.ericsson.se> <45A2B2A1.4010303@cisco.com> In-Reply-To: <45A2B2A1.4010303@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Paul Kyzivat , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: christer> I am not sure I understand. Isn't the re-use per direction christer> (unidirectional usage of a connection) already specified in christer> RFC3261? The connection-reuse drafts, as far as I understand christer> (I'm sure Vijay can give more details :) defines the christer> bidirectional usage of a connection. > > I'm sure Vijay will chime in here, but it seems clear to me that it does > not. Sorry for the delayed response; yes, let me chime in here. Connection-reuse defines the bidirectional usage of a connection for the TLS transport only, not the TCP transport. For TCP, it is a connection-in-each direction because of the security properties associated with the TCP transport when used in SIP (so, you should not open up a TCP connection for REGISTER and expect to receive requests in the backwards direction over it.) Connect-reuse is NOT a replacement for outbound. Outbound addresses non-transitive trust in the form of NATs that connect-reuse does not. Outbound also addresses keeping multiple flows open, which connect-reuse does not. Basically, connect-reuse provides guidance to implementors that fills in the blanks of what is left unsaid in rfc3261 -- whether a connection is open per transaction, per dialog, or per whatever; connection lifetimes; mutual authentication when using X.509 certificates; connection reuse across virtual SIP servers; etc. *That* is its value, IMHO. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 08 17:33:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H433d-00057Q-NB; Mon, 08 Jan 2007 17:33:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H433b-00055k-PV for sip@ietf.org; Mon, 08 Jan 2007 17:33:31 -0500 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H433a-00071Q-KA for sip@ietf.org; Mon, 08 Jan 2007 17:33:31 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc11) with ESMTP id <2007010822332501100po0u5e>; Mon, 8 Jan 2007 22:33:30 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l08MXObM032083 for ; Mon, 8 Jan 2007 17:33:24 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l08MXOt1032079; Mon, 8 Jan 2007 17:33:24 -0500 Date: Mon, 8 Jan 2007 17:33:24 -0500 Message-Id: <200701082233.l08MXOt1032079@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (Internet-Drafts@ietf.org) Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-uri-list-message-01.txt References: X-Spam-Score: 0.2 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Title : Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP) Author(s) : M. Garcia-Martin, G. Camarillo Filename : draft-ietf-sip-uri-list-message-01.txt Pages : 18 Date : 2007-1-8 There are no form-feeds (^L) in this file. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 08 17:41:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H43B2-0000DJ-4v; Mon, 08 Jan 2007 17:41:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H43B1-0000DC-6n for sip@ietf.org; Mon, 08 Jan 2007 17:41:11 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H43Az-0008Si-B2 for sip@ietf.org; Mon, 08 Jan 2007 17:41:10 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l08Mf375008490; Mon, 8 Jan 2007 16:41:03 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l08Mf2u13148; Mon, 8 Jan 2007 16:41:02 -0600 (CST) Message-ID: <45A2C87E.7020507@alcatel-lucent.com> Date: Mon, 08 Jan 2007 16:41:02 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF94232567014E0908@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF94232567014E0908@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer: Our emails crossed. Christer Holmberg (JO/LMF) wrote: > So, again, it's not about defining/using new extensions - it's > about how to implement core SIP in a most effective way. Bingo! That is what I said in my last email, namely Basically, connect-reuse provides guidance to implementors that fills in the blanks of what is left unsaid in rfc3261 -- whether a connection is open per transaction, per dialog, or per whatever; connection lifetimes; mutual authentication when using X.509 certificates; connection reuse across virtual SIP servers; etc. *That* is its value, IMHO. > But, I still think the registraion clarifications I mentioned earlier > would be good for the connect-reuse draft. I'd be more than happy to work with you on clarifying any aspects in the connect-reuse draft. Your registrations clarifications from a previous email were: However, the draft does not talk about re-using registration TCP connections. No, it may not forbid it either, but maybe it would be good to add some text and/or example flows about that case also into chapter 4, together with the INVITE ones? Maybe also some text in chapter 8, talking about keeping the connection alive during the whole registration (and not only say that the connection should not be disconnected together with the dialog) would be useful. Based on this, it is clear that we cannot use the same TCP connection which we used to register to receive incoming requests. But, the draft can and does provide guidance on when to reclaim the connection (i.e., definitely not after the dialog is over.) Is there anything else that I may have missed? Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 08 19:35:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H44vg-0002nB-OG; Mon, 08 Jan 2007 19:33:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H44vf-0002mt-50; Mon, 08 Jan 2007 19:33:27 -0500 Received: from mgw3.sony.co.jp ([137.153.0.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H44vd-0001bg-7o; Mon, 08 Jan 2007 19:33:27 -0500 Received: from mail6.sony.co.jp ([43.0.1.208]) Received: from mail6.sony.co.jp (localhost [127.0.0.1]) by mail6.sony.co.jp (R8/Sony) with ESMTP id l090XMbs023333; Tue, 9 Jan 2007 09:33:23 +0900 (JST) Received: from jptkyxim01.jp.sony.com (jptkyxim01.jp.sony.com [43.15.17.87]) by mail6.sony.co.jp (R8/Sony) with ESMTP id l090XKPw022965; Tue, 9 Jan 2007 09:33:20 +0900 (JST) Received: from jptkyxms80.jp.sony.com ([43.20.57.1]) by jptkyxim01.jp.sony.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 Jan 2007 09:33:17 +0900 Received: from mail pickup service by jptkyxms80.jp.sony.com with Microsoft SMTPSVC; Tue, 9 Jan 2007 09:15:26 +0900 Received: from mail7.sony.co.jp ([43.0.1.209]) by jptkyxim03.jp.sony.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 Jan 2007 06:03:02 +0900 Received: from mail7.sony.co.jp (localhost [127.0.0.1]) by mail7.sony.co.jp (R8/Sony) with ESMTP id l08L1IVs026315 for ; Tue, 9 Jan 2007 06:01:24 +0900 (JST) Received: from ns5.sony.co.jp (mail11.sony.co.jp [43.15.125.7]) by mail7.sony.co.jp (R8/Sony) with ESMTP id l08L0xo6025349; Tue, 9 Jan 2007 06:00:59 +0900 (JST) Received: from megatron.ietf.org (stiedprmman1.ietf.ORG [156.154.16.145]) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H41SH-0003lx-Lx; Mon, 08 Jan 2007 15:50:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H41Ry-0003Ip-1p; Mon, 08 Jan 2007 15:50:34 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H41Rx-0005v1-Hq; Mon, 08 Jan 2007 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 10C1817600; Mon, 8 Jan 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H41RS-0004vS-Kf; Mon, 08 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 08 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-OriginalArrivalTime: 08 Jan 2007 21:03:28.0960 (UTC) FILETIME=[723D8C00:01C73368] X-Spam-Score: 0.3 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-multiple-refer-01.txt X-BeenThere: sip@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Referring to Multiple Resources in the Session Initiation Protocol (SIP) Author(s) : G. Camarillo, et al. Filename : draft-ietf-sip-multiple-refer-01.txt Pages : 15 Date : 2007-1-8 This document defines extensions to the SIP REFER method so that this method can be used to refer servers to multiple resources. These extensions include the use of pointers to Uniform Resource Identifier (URI)-lists in the Refer-To header field and the "multiple-refer" SIP option-tag. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-multiple-refer-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-multiple-refer-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-multiple-refer-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-8125640.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-multiple-refer-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-multiple-refer-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-8125640.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Tue Jan 09 01:00:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4A16-0005GY-2C; Tue, 09 Jan 2007 00:59:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4A15-0005GH-6K for sip@ietf.org; Tue, 09 Jan 2007 00:59:23 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4A13-0003oB-Sg for sip@ietf.org; Tue, 09 Jan 2007 00:59:23 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CF9E1105B; Tue, 9 Jan 2007 06:59:12 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 06:59:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Date: Tue, 9 Jan 2007 06:59:11 +0100 Message-ID: <7374777208BDC7449D5620EF942325670150A16C@esealmw113.eemea.ericsson.se> In-Reply-To: <45A2C87E.7020507@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Thread-Index: AcczdhVLRq8yrcJGQwuOUTaBk3ENWAAPO3Og From: "Christer Holmberg \(JO/LMF\)" To: "Vijay K. Gurbani" X-OriginalArrivalTime: 09 Jan 2007 05:59:12.0355 (UTC) FILETIME=[49326330:01C733B3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Vijay,=20 >I'd be more than happy to work with you on clarifying any=20 >aspects in the connect-reuse draft. Your registrations=20 >clarifications from a previous email were: >=20 > However, the draft does not talk about re-using registration TCP > connections. No, it may not forbid it either, but maybe it would be > good to add some text and/or example flows about that case also > into chapter 4, together with the INVITE ones? Maybe also some > text in chapter 8, talking about keeping the connection alive > during the whole registration (and not only say that the > connection should not be disconnected together with the dialog) > would be useful. >=20 >Based on this, it is clear that we cannot use the same TCP=20 >connection which we used to register to receive incoming=20 >requests. But, the draft can and does provide guidance on=20 >when to reclaim the connection (i.e., definitely not after=20 >the dialog is over.) >=20 >Is there anything else that I may have missed? In the text you copied from my previous mail, what if you replace TCP with TLS? Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 09 04:01:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Cpi-0008CA-8D; Tue, 09 Jan 2007 03:59:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Cpg-0008Bp-MW for sip@ietf.org; Tue, 09 Jan 2007 03:59:48 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4Cpa-0003ST-2p for sip@ietf.org; Tue, 09 Jan 2007 03:59:48 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3BDCE4F0002; Tue, 9 Jan 2007 09:58:15 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 09:44:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TCP connection establishment [was: RE: [Sip] Question about Poll:Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Date: Tue, 9 Jan 2007 09:44:32 +0100 Message-ID: <7374777208BDC7449D5620EF942325670150A72F@esealmw113.eemea.ericsson.se> In-Reply-To: <45A2C3A1.8040403@lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP connection establishment [was: RE: [Sip] Question about Poll:Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Thread-Index: Acczc3w+a52eWK3DTiqInqUVpKRdgAAVMQRQ From: "Christer Holmberg \(JO/LMF\)" To: "Vijay K. Gurbani" , "SIP" X-OriginalArrivalTime: 09 Jan 2007 08:44:34.0071 (UTC) FILETIME=[63001A70:01C733CA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Vijay,=20 >Sorry for the delayed response; yes, let me chime in here. >=20 >Connection-reuse defines the bidirectional usage of a=20 >connection for the TLS transport only, not the TCP transport.=20 >For TCP, it is a connection-in-each direction because of the=20 >security properties associated with the TCP transport when=20 >used in SIP (so, you should not open up a TCP connection for=20 >REGISTER and expect to receive requests in the backwards=20 >direction over it.) >=20 >Connect-reuse is NOT a replacement for outbound. Outbound=20 >addresses non-transitive trust in the form of NATs that=20 >connect-reuse does not. Outbound also addresses keeping=20 >multiple flows open, which connect-reuse does not. I admit I haven't read version -07 of the draft in detail, but does it talk about how to maintain the TCP connection, e.g. using TCP keepalive or something similar? I can only find a statement saying that the connection shall be open "for as long as the resources on the host operating system allow it to". >Basically, connect-reuse provides guidance to implementors=20 >that fills in the blanks of what is left unsaid in rfc3261 --=20 >whether a connection is open per transaction, per dialog, or=20 >per whatever; connection lifetimes; mutual authentication=20 >when using X.509 certificates; connection reuse across=20 >virtual SIP servers; etc. *That* is its value, IMHO. I agree. And, and that is what my proposal to add text/examples about the registration connection was mainly about. It doesn't matter that the connection is unidirectional. Regards, Christer > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 09 06:30:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4FAJ-0000eZ-SU; Tue, 09 Jan 2007 06:29:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4FAI-0000bo-Qi for sip@ietf.org; Tue, 09 Jan 2007 06:29:14 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4FAG-0006zs-Ps for sip@ietf.org; Tue, 09 Jan 2007 06:29:14 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JBL00MAGM0U61@szxga01-in.huawei.com> for sip@ietf.org; Tue, 09 Jan 2007 19:17:18 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JBL002IOM0TVV@szxga01-in.huawei.com> for sip@ietf.org; Tue, 09 Jan 2007 19:17:18 +0800 (CST) Received: from JAIMINCL5132 ([10.18.8.82]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JBL00FXCM0HE5@szxml04-in.huawei.com> for sip@ietf.org; Tue, 09 Jan 2007 19:17:17 +0800 (CST) Date: Tue, 09 Jan 2007 16:47:05 +0530 From: Jaimin Pancholi Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-multiple-refer-01.txt In-reply-to: To: SIP Message-id: <005e01c733df$b32b6e40$5208120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcczhhtMDtx8hnlzSnSCuQViYdgvnAAIhiGg X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaiminp@huawei.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Question: ======= As per the draft: If the URI-list of the REFER request contains a repeated URI, the REFER-Recipient MUST behave as if that URI appeared in the URI-list only once. The REFER-Recipient uses the comparison rules specific to the URI scheme of each of the URIs in the URI-list to determine if there is any URI which appears more than once. Now if URI is appearing twice with different copy control or other attribute, which URI should REFER-Recipients consider Also this may cause the processing delay at REFER-Recipients side if multiple-refer contains many URIs and each one needs to be compared against Regards Jaimin Email Privacy Declaration **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! >-----Original Message----- >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >Sent: Tuesday, January 09, 2007 2:20 AM >To: i-d-announce@ietf.org >Cc: sip@ietf.org >Subject: [Sip] I-D ACTION:draft-ietf-sip-multiple-refer-01.txt > >A New Internet-Draft is available from the on-line >Internet-Drafts directories. >This draft is a work item of the Session Initiation Protocol >Working Group of the IETF. > > Title : Referring to Multiple Resources in >the Session Initiation Protocol (SIP) > Author(s) : G. Camarillo, et al. > Filename : draft-ietf-sip-multiple-refer-01.txt > Pages : 15 > Date : 2007-1-8 > >This document defines extensions to the SIP REFER method so that this > method can be used to refer servers to multiple resources. These > extensions include the use of pointers to Uniform Resource >Identifier > (URI)-lists in the Refer-To header field and the >"multiple-refer" SIP > option-tag. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sip-multiple-ref >er-01.txt > >To remove yourself from the I-D Announcement list, send a >message to i-d-announce-request@ietf.org with the word >unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > >Internet-Drafts are also available by anonymous FTP. Login >with the username "anonymous" and a password of your e-mail >address. After logging in, type "cd internet-drafts" and then >"get draft-ietf-sip-multiple-refer-01.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html or >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-sip-multiple-refer-01.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant >mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > >Below is the data which will enable a MIME compliant mail >reader implementation to automatically retrieve the ASCII >version of the Internet-Draft. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 09 06:34:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4FF4-0002dm-A7; Tue, 09 Jan 2007 06:34:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4FF3-0002de-6k for sip@ietf.org; Tue, 09 Jan 2007 06:34:09 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4FF2-00088A-KS for sip@ietf.org; Tue, 09 Jan 2007 06:34:09 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l09BY3Sr015388 for ; Tue, 9 Jan 2007 05:34:08 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 05:34:05 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 12:34:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-multiple-refer-01.txt Date: Tue, 9 Jan 2007 12:34:03 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180AB027C@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-multiple-refer-01.txt thread-index: Acczh1EUI7z3lOz8SCi7d+biM8Au2wAWnawQ From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 09 Jan 2007 11:34:03.0738 (UTC) FILETIME=[109823A0:01C733E2] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 731ea0e9f5725b67e634db1918f3b951 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I have just submitted the request to IESG to publish this document as proposed standard. As a result the document will now go through IESG review. The required PROTO writeup follows at the end of this mail Regards Keith Keith Drage drage@alcatel-lucent.com tel: +44 1793 776249 PROTO writeup for http://www.ietf.org/internet-drafts/draft-ietf-sip- multiple-refer-01.txt: "Refering to Multiple Resources in the Session=20 Initiation Protocol (SIP)" (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Keith Drage The document has been reviewed and is ready for forwarding to IESG for=20 publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Document history: * draft-camarillo-sipping-exploders-solution-00 was submitted November=20 22nd 2003 and expired May 22nd 2004. * draft-camarillo-sipping-exploders-00 was submitted September 9th 2003=20 and expired March 9th 2004. * draft-camarillo-sipping-exploders-02 was submitted February 6th 2004=20 and expired August 6th 2004. * draft-camarillo-sipping-exploders-03 was submitted February 2004 and=20 expired August 1st 2004. * draft-camarillo-sipping-multiple-refer-00 was submitted February 2004=20 and expired August 2004. * draft-ietf-sipping-multiple-refer-00 was submitted July 2004 and expired January 2005. * draft-ietf-sipping-multiple-refer-01 was submitted November 2004 and=20 expired April 2005. * draft-ietf-sipping-multiple-refer-02 was submitted 2nd December 2004=20 and expired 2nd June 2005. * draft-ietf-sipping-multiple-refer-03 was submitted 15th April 2005 and=20 expired 15th October 2005. * draft-ietf-sipping-multiple-refer-04 was submitted 24th October 2005=20 and expired 24th April 2006. * draft-ietf-sipping-multiple-refer-05 was submitted 5th November 2005=20 and expired 5th May 2006. * draft-ietf-sipping-multiple-refer-06 was submitted 27th June 2006 and=20 expired 27th December 2006. * draft-ietf-sip-multiple-refer-00 was submitted 24th September 2006 and=20 expires 24th March 2007. * draft-ietf-sip-multiple-refer-01 was submitted 8th January 2007 and=20 expires 8th July 2007. WGLC was initiated in the SIPPING WG on draft-ietf-sipping-multiple-refer-02=20 on 12th January 2005 with comments requested by 12th February 2005. Review was made and comments were received from: Nils Ohlmeier. During the=20 course of the work comments have also been made by: Cullen Jenning, Sharon=20 Fridman, Dale Worley, Jeroen van Bemmel, Darshan Bildikar, Dean Willis. draft-ietf-sipping-multiple-refer-06 was extended to refer to draft-ietf- sipping-capacity-attribute and also synchronized with RFC 4488 (suppression=20 of REFER implicit subscription). The document was moved from the SIPPING WG to the SIP WG in conformance with=20 RFC 3427 because it defines an option tag (this was added at a late stage in=20 the review process). The document was regarded by the SIPPING WG chairs as=20 being adequately reviewed and no further review took place in the SIP WG.=20 The SIP mailing list was polled on this status and no complaint was made. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? The document defines mechanisms that are entirely internal to the Session=20 Initiation Protocol (SIP). The document shepherd considers that no external=20 review from an external specialist is necessary. While the document makes=20 use of XML within a SIP message body, that XML is defined by other documents=20 (RFC 4488, draft-ietf-simple-xcap-list-usage-05), and used in this=20 specification by reference. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The document defines a new SIP protocol extension for a particular purpose=20 in a form that has been used for many other extensions. The document=20 shepherd has no concerns with the document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is a strong requirement from OMA for a SIP solution in this area. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) None indicated. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The document has been reviewed against the guidelines in RFC 4485 and it is=20 believed that the document is conformant with those guidelines. While the document defines a new SIP option tag, these have been performed=20 as a SIP working group item, and therefore this draft is in conformance with=20 RFC 3427. For ID-NITS the document has been checked against idnits 1.123 and no issues=20 have been found. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has split its references into normative and informative=20 references. All the normative references are now published RFCs except as=20 follows: * reference [9] draft-ietf-simple-xcap-list-usage-05 is in IESG review=20 as proposed standard. * reference [10] draft-ietf-sipping-uri-services-06 has been submitted=20 to the IESG by the SIPPING group as proposed standard. * reference [11] draft-ietf-sipping-capacity-attribute-03 is currently=20 in WGLC in the SIPPING group. Of the informative references, there is only one open reference [14] draft- ietf-sip-gruu-11 which is expected to be submitted by the SIP WG to IESG shortly.=20 (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? Section 11 of the document registers a new option-tag; the new option-tag is=20 defined elsewhere in the document. This registration is consistent with RFC=20 3968 which defines the registry and is also consistent with the current=20 format of the registry. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document contains no entries written in formal language. While the=20 document makes use of XML within a SIP message body, that XML is defined by=20 other documents (RFC 4488, draft-ietf-simple-xcap-list-usage-05), and used=20 in this specification by reference. Figures 1 and 3 contain an example of=20 this XML usage which is apparently well-formed. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines extensions to the SIP REFER method so that this method=20 can be used to refer servers to multiple resources. These extensions=20 include the use of pointers to Uniform Resource Identifier (URI)-lists in=20 the Refer-To header field and the "multiple-refer" SIP option-tag. Working Group Summary The document was originally produced by the SIPPING working group, but was=20 transferred to the SIP working group due to the need to define a new option=20 tag, in conformance with RFC 3427. There is consensus in the WG to publish=20 this document. Document Quality There is a strong requirement from OMA for a SIP solution in this area. Personnel Keith Drage is the document shepherd for this document. Cullen Jennings is=20 the responsible Area Director. > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: 08 January 2007 20:50 > To: i-d-announce@ietf.org > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-ietf-sip-multiple-refer-01.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol=20 > Working Group of the IETF. >=20 > Title : Referring to Multiple Resources in=20 > the Session Initiation Protocol (SIP) > Author(s) : G. Camarillo, et al. > Filename : draft-ietf-sip-multiple-refer-01.txt > Pages : 15 > Date : 2007-1-8 > =09 > This document defines extensions to the SIP REFER method so that this > method can be used to refer servers to multiple resources. These > extensions include the use of pointers to Uniform Resource=20 > Identifier > (URI)-lists in the Refer-To header field and the=20 > "multiple-refer" SIP > option-tag. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-multiple-re > fer-01.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message.=20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then=20 > "get draft-ietf-sip-multiple-refer-01.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sip-multiple-refer-01.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 09 09:57:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4IOP-0004kI-At; Tue, 09 Jan 2007 09:56:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4IOO-0004kC-D8 for sip@ietf.org; Tue, 09 Jan 2007 09:56:00 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4IOL-00057Q-AB for sip@ietf.org; Tue, 09 Jan 2007 09:56:00 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l09EtnhS023512; Tue, 9 Jan 2007 08:55:49 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l09Etnu28800; Tue, 9 Jan 2007 08:55:49 -0600 (CST) Message-ID: <45A3ACF5.2000206@alcatel-lucent.com> Date: Tue, 09 Jan 2007 08:55:49 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF942325670150A16C@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF942325670150A16C@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: vkg>Is there anything else that I may have missed? > > In the text you copied from my previous mail, what if you replace TCP > with TLS? Then, that would be fine; i.e., the connection established during registration could be reused for requests coming into the UA. I can add this specific behavior for TLS in a new revision. In another email in the same thread you wrote: vkg> Connect-reuse is NOT a replacement for outbound. Outbound vkg> addresses non-transitive trust in the form of NATs that vkg> connect-reuse does not. Outbound also addresses keeping vkg>multiple flows open, which connect-reuse does not. > > I admit I haven't read version -07 of the draft in detail, but does it > talk about how to maintain the TCP connection, e.g. using TCP keepalive > or something similar? I can only find a statement saying that the > connection shall be open "for as long as the resources on the host > operating system allow it to". Connect-reuse does not talk about the keepalive aspect at all. Since it does not assume NAT presence, there is no reason that the connection should be torn down, unless of course one of the hosts crashes, or actively tears the connection down to reclaim resources. vkg>Basically, connect-reuse provides guidance to implementors vkg>that fills in the blanks of what is left unsaid in rfc3261 -- vkg>whether a connection is open per transaction, per dialog, or vkg>per whatever; connection lifetimes; mutual authentication vkg>when using X.509 certificates; connection reuse across vkg>virtual SIP servers; etc. *That* is its value, IMHO. > > I agree. And, and that is what my proposal to add text/examples about > the registration connection was mainly about. It doesn't matter that the > connection is unidirectional. OK; I will add the registration case for TLS transports. That should not be a problem. Anything else? Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 09 10:44:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4J8a-0001Ts-9h; Tue, 09 Jan 2007 10:43:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4J8Y-0001Tm-Kg for sip@ietf.org; Tue, 09 Jan 2007 10:43:42 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4J8U-0001Uk-6L for sip@ietf.org; Tue, 09 Jan 2007 10:43:42 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l09FfYXP021893; Tue, 9 Jan 2007 17:41:42 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 17:43:29 +0200 Received: from esebe104.NOE.Nokia.com ([172.21.143.44]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 17:43:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Tue, 9 Jan 2007 17:43:28 +0200 Message-ID: <719D5CCC2F6E3644B0A9F5C9B1D000880276764F@esebe104.NOE.Nokia.com> In-Reply-To: <7.0.1.0.0.20070105142623.0255f908@iptel.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Thread-Index: AccwzZDZF4/ExntJSmWmagGBB6pEWADL7wSA From: To: , , X-OriginalArrivalTime: 09 Jan 2007 15:43:29.0250 (UTC) FILETIME=[E8BC0C20:01C73404] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070109174145-55341BB0-5679A37C/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: sip@ietf.org, audet@nortel.com, dean.willis@softarmor.com, bstucker@nortel.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, On 05 January 2007, Jiri Kuthan wrote:=20 >Well, based on sipit observations it appears much easier to=20 >compile a short list of those that do TCP in large scale.=20 >Solely based on what I'm aware of sole presence of TCP is=20 >okay, 50k TCP connections is very good, 200k is fantastic (and=20 >to some extent uncertain) and more than that is sci-fi. these sound about right. But I'd say this is mostly due to lack=20 of demand, rather than fundamental technical limitations of scaling=20 TCP in SIP servers. Once we have more SIP clients with "persistent=20 TCP" (i.e. TCP connections are kept alive as long as registration is=20 active), or "full sip-outbound" support, there is some motivation to improve the TCP support in servers. And there are already quite a few of these clients on the market. Of course, in today's access networks filled=20 with stateful-firewalls-and-nats, without either "persistant TCP" or=20 sip-outbound, TCP is only of limited use on the client-proxy hop (as=20 the proxy won't have much success in initiating TCP connections towards the clients). I was involved in writing a paper concerning TCP scalability in SIP servers (about to be published at ICN'07 [1], titled "Scalability of TCP servers, handling persistent connections"), and the results we got were mostly positive. We were able to hit=20 100k simultanenous registrations with TCP with commodity PC hw=20 and sw combo. All in all, scalability of TCP, although with some=20 per-connection overhead, was nearly identical to UDP (both limited by available CPU&memory, with linear growth of resource usage). And further,=20 the keepalive traffic had very little performance impact in terms of CPU and memory bandwidth&usage (even if the heaviest possible method, i.e.=20 full REGISTERs, was used for keepalives). [1] http://www.iaria.org/conferences2007/ICN07.html --=20 first.surname@nokia.com (Kai Vehmanen), Nokia Research Center _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 09 10:48:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4JDO-0003SD-Nn; Tue, 09 Jan 2007 10:48:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4JDM-0003RQ-Li for sip@ietf.org; Tue, 09 Jan 2007 10:48:40 -0500 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4JDL-0002qZ-Eu for sip@ietf.org; Tue, 09 Jan 2007 10:48:40 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc15) with ESMTP id <20070109154828015004sii9e>; Tue, 9 Jan 2007 15:48:39 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l09FmSbM010595 for ; Tue, 9 Jan 2007 10:48:28 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l09FmSqH010591; Tue, 9 Jan 2007 10:48:28 -0500 Date: Tue, 9 Jan 2007 10:48:28 -0500 Message-Id: <200701091548.l09FmSqH010591@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <005e01c733df$b32b6e40$5208120a@china.huawei.com> (jaiminp@huawei.com) Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-multiple-refer-01.txt References: <005e01c733df$b32b6e40$5208120a@china.huawei.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Jaimin Pancholi As per the draft: If the URI-list of the REFER request contains a repeated URI, the REFER-Recipient MUST behave as if that URI appeared in the URI-list only once. The REFER-Recipient uses the comparison rules specific to the URI scheme of each of the URIs in the URI-list to determine if there is any URI which appears more than once. Now if URI is appearing twice with different copy control or other attribute, which URI should [be used?] The problem is worse than this. Due to the strange rules for SIP URI equivalence, these are equivalent: sip:foo@example.com sip:foo@example.com;parameter=value and these are equivalent: sip:foo@example.com sip:foo@example.com;parameter=other-value but these are *not* equivalent: sip:foo@example.com;parameter=value sip:foo@example.com;parameter=other-value So if all three are present in a URI-list, it's not even clear how many should be used. I seem to remember having a similar problem in the GRUU discussion, and the outcome was that the GRUU I-D needed to define a new comparison between SIP URIs that was stricter than 3261's "equivalence". It appears that we need that same comparison here. This leads me to ask if we should entirely replace the definition of "equivalent URIs" in section 19.1.4 of RFC 3261. I did a quick search of the text of 3261, and it doesn't appear that the equivalence of URIs is *used* anywhere. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 09 11:30:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4JrF-0004T5-DK; Tue, 09 Jan 2007 11:29:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4JrD-0004Ro-Qf for sip@ietf.org; Tue, 09 Jan 2007 11:29:51 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4JrC-0007VF-3P for sip@ietf.org; Tue, 09 Jan 2007 11:29:51 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Jan 2007 11:29:48 -0500 X-IronPort-AV: i="4.13,164,1167627600"; d="scan'208"; a="111175497:sNHT47035624" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l09GTlee019042; Tue, 9 Jan 2007 11:29:47 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l09GTl7h006090; Tue, 9 Jan 2007 11:29:47 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 11:29:47 -0500 Received: from [10.86.242.10] ([10.86.242.10]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 11:29:47 -0500 Message-ID: <45A3C2FA.7020507@cisco.com> Date: Tue, 09 Jan 2007 11:29:46 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-multiple-refer-01.txt References: <005e01c733df$b32b6e40$5208120a@china.huawei.com> <200701091548.l09FmSqH010591@dragon.ariadne.com> In-Reply-To: <200701091548.l09FmSqH010591@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jan 2007 16:29:47.0288 (UTC) FILETIME=[60930180:01C7340B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2402; t=1168360187; x=1169224187; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20I-D=20ACTION=3Adraft-ietf-sip-multiple-refer- 01.txt |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=WFid7mM6HVFr1TEIVtsIH/f3tk/+eB75sMEisUdmX+Q=; b=aKe0SPda6SdJzMS/bZSxQu683x77QwKTVRSUi6KMlvV608UQKsfazii0ZA4x61kKQgEcSqwY aGOqVC/ij1IVJztkP1uceTg5mmt1z6F4b9VX6bK6PrT9PmMj+Xyik8+5; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dale, You make a good point in this case. But we need to step carefully before making sweeping changes. You say you don't find any *use* of URI comparison in 3261. Actually there is at least one, in section 10.3, step 7. It is used to compare Contact URIs in the request to those already registered. It seems to me that there is simply a need for multiple comparison rules for different circumstances. Paul Dale.Worley@comcast.net wrote: > From: Jaimin Pancholi > > As per the draft: > If the URI-list of the REFER request contains a repeated URI, the > REFER-Recipient MUST behave as if that URI appeared in the URI-list > only once. The REFER-Recipient uses the comparison rules specific to > the URI scheme of each of the URIs in the URI-list to determine if > there is any URI which appears more than once. > > Now if URI is appearing twice with different copy control or other > attribute, which URI should [be used?] > > The problem is worse than this. Due to the strange rules for SIP URI > equivalence, these are equivalent: > > sip:foo@example.com > sip:foo@example.com;parameter=value > > and these are equivalent: > > sip:foo@example.com > sip:foo@example.com;parameter=other-value > > but these are *not* equivalent: > > sip:foo@example.com;parameter=value > sip:foo@example.com;parameter=other-value > > So if all three are present in a URI-list, it's not even clear how > many should be used. > > I seem to remember having a similar problem in the GRUU discussion, > and the outcome was that the GRUU I-D needed to define a new > comparison between SIP URIs that was stricter than 3261's > "equivalence". > > It appears that we need that same comparison here. > > This leads me to ask if we should entirely replace the definition of > "equivalent URIs" in section 19.1.4 of RFC 3261. I did a quick search > of the text of 3261, and it doesn't appear that the equivalence of > URIs is *used* anywhere. > > Dale > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 09 13:43:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Luo-0007Qm-Mr; Tue, 09 Jan 2007 13:41:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Lum-0007Qa-Ut for sip@ietf.org; Tue, 09 Jan 2007 13:41:40 -0500 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4Lul-0003X5-DQ for sip@ietf.org; Tue, 09 Jan 2007 13:41:40 -0500 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id D753A20A2F0; Tue, 9 Jan 2007 19:41:31 +0100 (CET) Message-Id: <7.0.1.0.0.20070109193434.05772a58@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 09 Jan 2007 19:41:30 +0100 To: , , From: Jiri Kuthan Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive,TCP, and UDP usage in draft-ietf-sip-outbound In-Reply-To: <719D5CCC2F6E3644B0A9F5C9B1D000880276764F@esebe104.NOE.Noki a.com> References: <7.0.1.0.0.20070105142623.0255f908@iptel.org> <719D5CCC2F6E3644B0A9F5C9B1D000880276764F@esebe104.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: sip@ietf.org, audet@nortel.com, dean.willis@softarmor.com, bstucker@nortel.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 16:43 09/01/2007, Kai.Vehmanen@nokia.com wrote: >Hi, > >On 05 January 2007, Jiri Kuthan wrote: >>Well, based on sipit observations it appears much easier to >>compile a short list of those that do TCP in large scale. >>Solely based on what I'm aware of sole presence of TCP is >>okay, 50k TCP connections is very good, 200k is fantastic (and >>to some extent uncertain) and more than that is sci-fi. > >these sound about right. But I'd say this is mostly due to lack >of demand, rather than fundamental technical limitations of scaling >TCP in SIP servers. I would say both. At least for us, drilling OS kernel and dealing with memory consumption was a laborous exercises. Nevertheless, the demand as driven by existing implementations which are mostly UDP-based has been indeed rather sporadic as of now. >Once we have more SIP clients with "persistent >TCP" (i.e. TCP connections are kept alive as long as registration is >active), or "full sip-outbound" support, there is some motivation to >improve >the TCP support in servers. And there are already quite a few of these >clients on the market. Of course, in today's access networks filled >with stateful-firewalls-and-nats, without either "persistant TCP" or >sip-outbound, TCP is only of limited use on the client-proxy hop (as >the proxy won't have much success in initiating TCP connections towards >the clients). indeed. >I was involved in writing a paper concerning TCP scalability >in SIP servers (about to be published at ICN'07 [1], titled >"Scalability of TCP servers, handling persistent connections"), >and the results we got were mostly positive. We were able to hit >100k simultanenous registrations with TCP with commodity PC hw >and sw combo. All in all, scalability of TCP, although with some >per-connection overhead, was nearly identical to UDP (both limited by >available CPU&memory, with linear growth of resource usage). And >further, >the keepalive traffic had very little performance impact in terms of CPU Was that impact on the overall performance (including database access, processing user profile, etc.) or just stack throughput? Thanks! -jiri >and memory bandwidth&usage (even if the heaviest possible method, i.e. >full REGISTERs, was used for keepalives). > >[1] http://www.iaria.org/conferences2007/ICN07.html > >-- >first.surname@nokia.com (Kai Vehmanen), Nokia Research Center -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 09 14:25:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Mb4-0000Mm-71; Tue, 09 Jan 2007 14:25:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Mb2-0000Hw-G3 for sip@ietf.org; Tue, 09 Jan 2007 14:25:20 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4Mb1-0004e8-8x for sip@ietf.org; Tue, 09 Jan 2007 14:25:20 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Jan 2007 14:25:19 -0500 X-IronPort-AV: i="4.13,164,1167627600"; d="scan'208"; a="111193601:sNHT46315216" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l09JPImX003044; Tue, 9 Jan 2007 14:25:19 -0500 Received: from [192.168.1.9] (rtp-vpn2-602.cisco.com [10.82.242.90]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l09JPH2k029520; Tue, 9 Jan 2007 14:25:18 -0500 (EST) In-Reply-To: <7374777208BDC7449D5620EF94232567014B6FAF@esealmw113.eemea.ericsson.se> References: <7374777208BDC7449D5620EF94232567014B6FAF@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6A7414DE-CBC1-4B24-9E5F-F4AA2D389145@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Update of outbound Date: Tue, 9 Jan 2007 11:25:08 -0800 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1462; t=1168370719; x=1169234719; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20Update=20of=20outbound |Sender:=20 |To:=20Christer=20Holmberg=20((JO/LMF))=20; bh=7i617Fsxe0mVA01H6pJS1AKHcbV7Ve6nwpx5l7CARVg=; b=osS6LqEZiWPc+vMVaUz6v2FFsp0H0B5ffiytaZgRkdnAOotk+hZHoKNHZ4UIhhTxQXpPgVKg r1QfgSOvpBQaFUwcHNNbWe3JbeSA5y0k3lbDJhFYtCe0nSnWz06FIN4g; Authentication-Results: rtp-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: SIP , Rohan Mahy , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think that chairs need to combine the input they receive in a meeting hum with the input they get on the list. Chairs are given pretty broad discretion in how they determine consensus but they certainly needs to be taking into account any input from the list. On Jan 8, 2007, at 4:22 AM, Christer Holmberg ((JO/LMF)) wrote: > >>> I counted 12 people in favor of CRLF. (Jeroen, Ekki, Elwell, Aki, >>> Markus, ALfred, Miguel, Hisham, Francois, Byron, Mac, Fredrik). >> >> you can add me to that list too (lacking tcp keepalive >> support in ua tcp stack). >> >>> If it is an open issue, then I suspect the only place to get strong > enough >>> consensus to overturn the previous hum is in the next WG meeting. >> >> the mailing list needs to be the authority that determines >> consensus, not the meeting that is attended only by those who >> can afford it. > > Well, then we don't need any hums in the future, do we? :) > > Seriously, I do agree, but I (and I am sure others too) have received > comments saying that "there was a concensus in this-or-that IETF > meeting", without the issue really even being discussed on the mailing > list. In some cases things have been discussed on the list, and have > even got some support, but then being turned down at the meeting. > > So, does that mean that all decissions made at meetings should be > agreed > also on the list after that? > > Regards, > > Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 09 14:39:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4MoK-0005oZ-RM; Tue, 09 Jan 2007 14:39:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4MoK-0005oU-BH for sip@ietf.org; Tue, 09 Jan 2007 14:39:04 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4MoI-00014f-3Z for sip@ietf.org; Tue, 09 Jan 2007 14:39:04 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Jan 2007 14:39:02 -0500 X-IronPort-AV: i="4.13,164,1167627600"; d="scan'208"; a="111194559:sNHT46653396" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l09Jd0dj007682; Tue, 9 Jan 2007 14:39:00 -0500 Received: from [192.168.1.9] (rtp-vpn2-602.cisco.com [10.82.242.90]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l09Jcb7g001107; Tue, 9 Jan 2007 14:39:00 -0500 (EST) In-Reply-To: <7374777208BDC7449D5620EF9423256701474EB0@esealmw113.eemea.ericsson.se> References: <7374777208BDC7449D5620EF9423256701474EB0@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2ACB7853-7766-4766-B198-F28DF2C9A5F2@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Update of outbound Date: Tue, 9 Jan 2007 11:38:56 -0800 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1589; t=1168371540; x=1169235540; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20Update=20of=20outbound |Sender:=20 |To:=20Christer=20Holmberg=20((JO/LMF))=20; bh=B1FEIyoRBczejliFK5/rIAJJ7Ea1YgMTpJNRpbuKGQQ=; b=lt8zlx79+hL3Q7MGqjMnE0IEsMPcATG1BjLo0+3eyhrPYu2AEL5MhsrPzWw98rEe1eyEzvCC lzAn7laRv6qAGIhT7DCjBAG6543T+XyJ4WwwuwuQsWr3Zl/3RjbVn9WA; Authentication-Results: rtp-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: SIP , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jan 7, 2007, at 11:34 PM, Christer Holmberg ((JO/LMF)) wrote: > > Hi, > > Thanks for the draft! > > A few comments/questions on chapter 8. > > First, the text now says that the edge proxy can indicate support of > keepalive by inserting the parameter e.g. in the Path header. So, > maybe > the following text futher down could also be modified: > > "For example, automatic or manual configuration of an outbound- > proxy-set > which contains the keepalive=stun parameter is > considered sufficient explicit indication." > > ...would be: > > "For example, automatic or manual configuration of an outbound- > proxy-set > which contains the keepalive=stun parameter, or the receival of the > parameter in the Path header of the edge proxy, is considered..." works for me. > > > Second, the text says that the explicit indication is needed before > any > traffic is sent. I said earlier that one could send the REGISTER > before > any STUN is sent. And, if the indication comes in the REGISTER > response > the REGISTER has to be sent before. OPTIONS is another example there > "traffic" may be sent before the indication has be retrieved. So, > maybe > some clarification text is needed, saying that "STUN traffic" (the way > the text is now written could be understood to also cover SIP traffic) > shall not be sent before the indication has been retrieved. Yep - I think that everyone meant what you are saying and we just typed it up wrong. I will change this to say "STUN traffic". > > Regards, > > Christer > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 09 15:23:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4NUa-0005Ks-83; Tue, 09 Jan 2007 15:22:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4NUY-0005Kn-Fh for sip@ietf.org; Tue, 09 Jan 2007 15:22:42 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4NUT-0004TM-QP for sip@ietf.org; Tue, 09 Jan 2007 15:22:42 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D0080173; Tue, 9 Jan 2007 21:22:26 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 21:22:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Date: Tue, 9 Jan 2007 21:22:25 +0100 Message-ID: <7374777208BDC7449D5620EF942325670155B192@esealmw113.eemea.ericsson.se> In-Reply-To: <45A3ACF5.2000206@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Thread-Index: Accz/oDdtrvO9QYITAKq4FPbszRL2gADQNhQ From: "Christer Holmberg \(JO/LMF\)" To: "Vijay K. Gurbani" X-OriginalArrivalTime: 09 Jan 2007 20:22:26.0700 (UTC) FILETIME=[E1083CC0:01C7342B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>In the text you copied from my previous mail, what if you replace TCP=20 >>with TLS? >=20 >Then, that would be fine; i.e., the connection established=20 >during registration could be reused for requests coming into=20 >the UA. ...and naturally for requests going out from the UA also. >I can add this specific behavior for TLS in a new revision. Good. And, again, maybe an example flow in chapter 4 would be good too. =20 >In another email in the same thread you wrote: >=20 >vkg> Connect-reuse is NOT a replacement for outbound. Outbound =20 >vkg>addresses non-transitive trust in the form of NATs that =20 >vkg>connect-reuse does not. Outbound also addresses keeping multiple=20 >vkg>flows open, which connect-reuse does not. >=20 >I admit I haven't read version -07 of the draft in detail,=20 >but does it talk about how to maintain the TCP connection, e.g. using TCP=20 >keepalive or something similar? I can only find a statement saying=20 >that the connection shall be open "for as long as the resources on the=20 >host operating system allow it to". >=20 >Connect-reuse does not talk about the keepalive aspect at all. >Since it does not assume NAT presence, there is no reason=20 >that the connection should be torn down, unless of course one=20 >of the hosts crashes, or actively tears the connection down=20 >to reclaim resources. Ok. I don't know TCP well enough. I was thinking about cases where the connection is unused for long periods of time. Also, IF the connection, for whatever reasons, goes down I think it would be good to suggest that it shall be re-established. In the registration connection case, would a re-REGISTER have to be sent also? >vkg>Basically, connect-reuse provides guidance to implementors that=20 >vkg>fills in the blanks of what is left unsaid in rfc3261 --=20 >whether a=20 >vkg>connection is open per transaction, per dialog, or per whatever;=20 >vkg>connection lifetimes; mutual authentication when using X.509=20 >vkg>certificates; connection reuse across virtual SIP servers; etc. =20 >vkg>*That* is its value, IMHO. >>=20 >>I agree. And, and that is what my proposal to add text/examples about=20 >>the registration connection was mainly about. It doesn't matter that=20 >>the connection is unidirectional. >=20 >OK; I will add the registration case for TLS transports. =20 >That should not be a problem. Anything else? I will look at the whole document more in detail later. For now I was mostly focusing on the parts affecting this discussion, so... :) Regards, Christer =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 09 17:19:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4PIu-0000bk-MD; Tue, 09 Jan 2007 17:18:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4PIs-0000bf-Hw for sip@ietf.org; Tue, 09 Jan 2007 17:18:46 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4PIr-00080e-8Y for sip@ietf.org; Tue, 09 Jan 2007 17:18:46 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 09 Jan 2007 17:18:45 -0500 X-IronPort-AV: i="4.13,164,1167627600"; d="scan'208"; a="111207538:sNHT49371032" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l09MIj2N032250; Tue, 9 Jan 2007 17:18:45 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l09MIi2k009764; Tue, 9 Jan 2007 17:18:44 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 17:18:44 -0500 Received: from [10.86.242.10] ([10.86.242.10]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 17:18:44 -0500 Message-ID: <45A414C3.5010401@cisco.com> Date: Tue, 09 Jan 2007 17:18:43 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF942325670155B192@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF942325670155B192@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jan 2007 22:18:44.0146 (UTC) FILETIME=[1FEA0120:01C7343C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2560; t=1168381125; x=1169245125; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20TCP=20connection=20establishment=20[was=3A=20RE=3A=20 [Sip]=20Question=20about=20Poll=3A=0A=20Proposal=20relating=20to=20keepali ve,=20TCP,=09and=20UDP=20usage=20in=20draft-ietf-sip-outbound] |Sender:=20 |To:=20=22Christer=20Holmberg=20(JO/LMF)=22=20; bh=4P5xbo1hkvXV4UPRvE/fIiCK7NDHnBqTVDSV9hXXvRw=; b=yDGjn8FSRw1W+FEIU3nJR7rpAUQ0lgTajT5gAr6OnG536pTI1uYJJ96r2qDViG1ngkXzPydO iSVamFwf3Xw89Yu8au69xdmcv44BVIGSfsQ3CzljR2p7jBC0ikviS49H; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > Hi, > >>> In the text you copied from my previous mail, what if you replace TCP >>> with TLS? >> Then, that would be fine; i.e., the connection established >> during registration could be reused for requests coming into >> the UA. > > ...and naturally for requests going out from the UA also. > >> I can add this specific behavior for TLS in a new revision. > > Good. And, again, maybe an example flow in chapter 4 would be good too. > >> In another email in the same thread you wrote: >> >> vkg> Connect-reuse is NOT a replacement for outbound. Outbound >> vkg>addresses non-transitive trust in the form of NATs that >> vkg>connect-reuse does not. Outbound also addresses keeping multiple >> vkg>flows open, which connect-reuse does not. >> >> I admit I haven't read version -07 of the draft in detail, >> but does it talk about how to maintain the TCP connection, e.g. using > TCP >> keepalive or something similar? I can only find a statement saying >> that the connection shall be open "for as long as the resources on the >> host operating system allow it to". >> >> Connect-reuse does not talk about the keepalive aspect at all. >> Since it does not assume NAT presence, there is no reason >> that the connection should be torn down, unless of course one >> of the hosts crashes, or actively tears the connection down >> to reclaim resources. > > Ok. I don't know TCP well enough. I was thinking about cases where the > connection is unused for long periods of time. > > Also, IF the connection, for whatever reasons, goes down I think it > would be good to suggest that it shall be re-established. In the > registration connection case, would a re-REGISTER have to be sent also? I'm not sure if you are discussing the TCP case or the TLS case here. For the TCP case, where separate connections are used for each direction, there is no reason to reestablish a connection when it goes down, until it is needed for the same direction. For TLS, the reason to do so would be if the connection can't be established in the other direction. But that is the outbound case. Since we aren't talking about that case here, and instead assume that a connection *can* be established in either direction, again there is no real reason to reestablish a connection at the time one goes down. Early reestablishment of connections is instead likely to prevent the servers from dropping connections when they get too many. Paul Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 09 18:24:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4QJu-0003rW-8k; Tue, 09 Jan 2007 18:23:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4QJr-0003pg-SK for sip@ietf.org; Tue, 09 Jan 2007 18:23:51 -0500 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4QEF-0000Yk-7m for sip@ietf.org; Tue, 09 Jan 2007 18:18:04 -0500 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 3357520A2F0; Wed, 10 Jan 2007 00:17:59 +0100 (CET) Message-Id: <7.0.1.0.0.20070110000229.05c93d78@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 10 Jan 2007 00:17:58 +0100 To: "Christer Holmberg (JO/LMF)" , "Vijay K. Gurbani" From: Jiri Kuthan Subject: RE: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] In-Reply-To: <7374777208BDC7449D5620EF942325670155B192@esealmw113.eemea. ericsson.se> References: <45A3ACF5.2000206@alcatel-lucent.com> <7374777208BDC7449D5620EF942325670155B192@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 21:22 09/01/2007, Christer Holmberg (JO/LMF) wrote: >Ok. I don't know TCP well enough. I was thinking about cases where the >connection is unused for long periods of time. thats no problem, it can "sleep" as long as it stays alive. >Also, IF the connection, for whatever reasons, goes down I think it >would be good to suggest that it shall be re-established. In the >registration connection case, would a re-REGISTER have to be sent also? I think this is more a behave agenda item than sip(ping). In any case, an app which wishes to stay reachable should reconnect and re-REGISTER too because the contacts valid for previous TCP connections have changed. -jiri -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 09 18:50:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4QjG-0006vX-1w; Tue, 09 Jan 2007 18:50:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4QjD-0006v6-39; Tue, 09 Jan 2007 18:50:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4QjC-0000GI-Nd; Tue, 09 Jan 2007 18:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 6B3A326E91; Tue, 9 Jan 2007 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H4QjC-00045h-8m; Tue, 09 Jan 2007 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 09 Jan 2007 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-connected-identity-03.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Connected Identity in the Session Initiation Protocol (SIP) Author(s) : J. Elwell Filename : draft-ietf-sip-connected-identity-03.txt Pages : 24 Date : 2007-1-9 Because of retargeting of a Session Initiation Protocol (SIP) dialog- forming request (changing the value of the Request-URI), the User Agent Server (UAS) can have a different identity from that in the To header field. This document provides a means for that User Agent (UA) to supply its identity to the peer UA by means of a request in the reverse direction and for that identity to be signed by an Authentication Service. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in the Public Switched Telephone Network (PSTN) behind a gateway. This document normatively updates RFC 3261 (SIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-identity-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-connected-identity-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-connected-identity-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-9151925.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-connected-identity-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-connected-identity-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-9151925.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Wed Jan 10 02:00:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4XQV-00037m-Ek; Wed, 10 Jan 2007 01:59:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4XQT-00036n-Ez for sip@ietf.org; Wed, 10 Jan 2007 01:59:09 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4XQP-0003xh-Sy for sip@ietf.org; Wed, 10 Jan 2007 01:59:09 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 26F6E4F0002; Wed, 10 Jan 2007 07:58:59 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 07:58:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Date: Wed, 10 Jan 2007 07:58:58 +0100 Message-ID: <7374777208BDC7449D5620EF942325670155B415@esealmw113.eemea.ericsson.se> In-Reply-To: <45A414C3.5010401@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Thread-Index: Acc0PCNAPiwKjFW+TIOsHpe/kzssBAASGYPQ From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 10 Jan 2007 06:58:58.0954 (UTC) FILETIME=[CD63B6A0:01C73484] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>>I admit I haven't read version -07 of the draft in detail, but does=20 >>>it talk about how to maintain the TCP connection, e.g. using >>>TCP keepalive or something similar? I can only find a statement saying=20 >>>that the connection shall be open "for as long as the resources on=20 >>>the host operating system allow it to". >>> >>>Connect-reuse does not talk about the keepalive aspect at all. >>>Since it does not assume NAT presence, there is no reason that the=20 >>>connection should be torn down, unless of course one of the hosts=20 >>>crashes, or actively tears the connection down to reclaim resources. >>=20 >>Ok. I don't know TCP well enough. I was thinking about cases where the >>connection is unused for long periods of time. >>=20 >>Also, IF the connection, for whatever reasons, goes down I think it=20 >>would be good to suggest that it shall be re-established. In the=20 >>registration connection case, would a re-REGISTER have to be sent also? >=20 >I'm not sure if you are discussing the TCP case or the TLS case here. > >For the TCP case, where separate connections are used for=20 >each direction, there is no reason to reestablish a=20 >connection when it goes down, until it is needed for the same=20 >direction. >=20 >For TLS, the reason to do so would be if the connection can't=20 >be established in the other direction. But that is the=20 >outbound case. Since we aren't talking about that case here,=20 >and instead assume that a connection *can* be established in=20 >either direction, again there is no real reason to=20 >reestablish a connection at the time one goes down. >=20 >Early reestablishment of connections is instead likely to=20 >prevent the servers from dropping connections when they get too many. The idea behind reestablishing the connections is to avoid the post dial delay of establishing the connection when an INVITE is to be sent. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 10 03:19:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Yfd-0004fd-47; Wed, 10 Jan 2007 03:18:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Yfb-0004fV-PT for sip@ietf.org; Wed, 10 Jan 2007 03:18:51 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4YfZ-0002u6-AI for sip@ietf.org; Wed, 10 Jan 2007 03:18:51 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JBN00B1Y8FGT0@siemenscomms.co.uk> for sip@ietf.org; Wed, 10 Jan 2007 08:18:52 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 10 Jan 2007 08:18:48 +0000 Content-return: allowed Date: Wed, 10 Jan 2007 08:18:47 +0000 From: "Elwell, John" Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-connected-identity-03.txt To: sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670AB8B6A4@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This has been updated following the San Diego meeting and taking into account post-WGLC comments from JDR. As far as I am concerned all open issues are resolved and it is ready for forwarding (it has been through WGLC). The main changes from 02 are as follows: - Numerous nits and minor editorial improvements - Addition of a few explanatory notes - Reformulation of 1st para of Intro - In section 4.4.1, revised text on populating From and To header field URIs - In section 4.4.2, revised text on updating the remote URI - In section 4.7, simplified proxy behaviour text - In section 5.2, improved description of the example - In section 4.6, verifier behaviour re-aligned with RFC 4474 - In section 4.4.1, recommendation to regard the dialog as terminated if 428, 436, 437 or 438 is received in response to mid-dialog request These last two points constitute resolution of the open issue discussed in San Diego. The signatures in the Identity header fields in the examples will need to be recalculated before publication. John > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 09 January 2007 23:50 > To: i-d-announce@ietf.org > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-ietf-sip-connected-identity-03.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Session Initiation Protocol > Working Group of the IETF. > > Title : Connected Identity in the Session > Initiation Protocol (SIP) > Author(s) : J. Elwell > Filename : draft-ietf-sip-connected-identity-03.txt > Pages : 24 > Date : 2007-1-9 > > Because of retargeting of a Session Initiation Protocol (SIP) dialog- > forming request (changing the value of the Request-URI), the User > Agent Server (UAS) can have a different identity from that > in the To > header field. This document provides a means for that User Agent > (UA) to supply its identity to the peer UA by means of a request in > the reverse direction and for that identity to be signed by an > > Authentication Service. The same mechanism can be used to > indicate a > change of identity during a dialog, e.g., because of some action in > the Public Switched Telephone Network (PSTN) behind a > gateway. This > document normatively updates RFC 3261 (SIP). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-i > dentity-03.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in > the body of > the message. > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-sip-connected-identity-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-ietf-sip-connected-identity-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 10 06:02:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4bCQ-0005os-AP; Wed, 10 Jan 2007 06:00:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4bCP-0005ok-EZ for sip@ietf.org; Wed, 10 Jan 2007 06:00:53 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4bCL-0002Qz-FE for sip@ietf.org; Wed, 10 Jan 2007 06:00:53 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B8D674CF; Wed, 10 Jan 2007 12:00:40 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 12:00:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Date: Wed, 10 Jan 2007 12:00:39 +0100 Message-ID: <7374777208BDC7449D5620EF94232567015876D3@esealmw113.eemea.ericsson.se> In-Reply-To: <7.0.1.0.0.20070110000229.05c93d78@iptel.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Thread-Index: Acc0RGn1tWTjHBkeQMKNProeyog6pwAYfS5g From: "Christer Holmberg \(JO/LMF\)" To: "Jiri Kuthan" , "Vijay K. Gurbani" X-OriginalArrivalTime: 10 Jan 2007 11:00:40.0577 (UTC) FILETIME=[9107C710:01C734A6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >>Ok. I don't know TCP well enough. I was thinking about cases where the >>connection is unused for long periods of time. >=20 >thats no problem, it can "sleep" as long as it stays alive. >=20 >=20 >>Also, IF the connection, for whatever reasons, goes down I think it=20 >>would be good to suggest that it shall be re-established. In the=20 >>registration connection case, would a re-REGISTER have to be sent also? >=20 >I think this is more a behave agenda item than sip(ping). In=20 >any case, an app which wishes to stay reachable should=20 >reconnect and re-REGISTER too because the contacts valid for=20 >previous TCP connections have changed. Correct. The reason I think it's a sip(ping) issue is, again, due to the post dial delay. Ie it has nothing to do with whether there is a NAT or not in the network. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 10 06:28:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4bce-0007m3-8L; Wed, 10 Jan 2007 06:28:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4bcc-0007lx-U6 for sip@ietf.org; Wed, 10 Jan 2007 06:27:58 -0500 Received: from mail.tataelxsi.co.in ([203.200.1.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4bcb-00078U-Dx for sip@ietf.org; Wed, 10 Jan 2007 06:27:58 -0500 Received: from rathod ([10.50.42.1]) by mail.tataelxsi.co.in (MOS 3.8.3-GA) with ESMTP id CEL09482 (AUTH rathod); Wed, 10 Jan 2007 16:57:43 +0530 (IST) From: Rathod Subhashchandra To: , Date: Wed, 10 Jan 2007 16:58:51 +0530 Message-ID: <000b01c734aa$812097b0$012a320a@telxsi.com> MIME-Version: 1.0 X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: High X-Junkmail-Status: score=10/50, host=mail.tataelxsi.co.in X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090204.45A4CBE2.0001,ss=1,fgs=0, ip=10.50.42.1, so=2006-12-09 10:45:40, dmn=5.2.125/2006-10-10 X-Spam-Score: 0.4 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Subject: [Sip] Any freely available SIP/IMS server X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rathod Subhashchandra List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1005935320==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1005935320== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C734D8.9AD8D3B0" This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C734D8.9AD8D3B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I have implemented SIP stack with SUBSCRIBE and NOTIFY features. To test these, I need a SIP/IMS server. Can you please revert me with any freely available server? Thanks in advance. Thanks ! Rathod. ------=_NextPart_000_000C_01C734D8.9AD8D3B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I have = implemented=20 SIP stack with SUBSCRIBE and NOTIFY features. To test these, I need = a=20 SIP/IMS server.
Can = you please=20 revert me with any freely available server?
 
Thanks = in=20 advance.
 
Thanks = !
Rathod.
 
------=_NextPart_000_000C_01C734D8.9AD8D3B0-- --===============1005935320== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1005935320==-- From sip-bounces@ietf.org Wed Jan 10 06:48:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4bvw-000107-NY; Wed, 10 Jan 2007 06:47:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4bvv-0000zM-Ak for sip@ietf.org; Wed, 10 Jan 2007 06:47:55 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H4bvg-0002Tp-GZ for sip@ietf.org; Wed, 10 Jan 2007 06:47:49 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l0ABlYWq008995; Wed, 10 Jan 2007 05:47:34 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 05:47:34 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 12:47:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-connected-identity-03.txt Date: Wed, 10 Jan 2007 12:47:31 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180AB0735@DEEXC1U01.de.lucent.com> In-Reply-To: <50B1CBA96870A34799A506B2313F26670AB8B6A4@ntht201e.siemenscomms.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-connected-identity-03.txt thread-index: Acc0kFi/eDgsZuJYTGG6XQGbUoCukQAHA4vg From: "Drage, Keith \(Keith\)" To: "Elwell, John" , X-OriginalArrivalTime: 10 Jan 2007 11:47:32.0677 (UTC) FILETIME=[1D2C2F50:01C734AD] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) This document has been through WGLC and at IETF #67 people seemed to think we were pretty much finished apart from the discussion point that took place in IETF #67. I therefore intend to give a few days for people to check their understanding of resolution of the issues discussed in IETF#67 is correctly documented, and then send this document to the IESG. Please therefore comment by say end Tuesday 16th January if you have any concerns. If you consider an extension is needed please request. No comments and no request for extension means this version (or an update to recalculate the examples) goes to IESG. Regards Keith > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: 10 January 2007 08:19 > To: sip@ietf.org > Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-connected-identity-03.txt >=20 > This has been updated following the San Diego meeting and=20 > taking into account post-WGLC comments from JDR. As far as I=20 > am concerned all open issues are resolved and it is ready for=20 > forwarding (it has been through WGLC). The main changes from=20 > 02 are as follows: >=20 > - Numerous nits and minor editorial improvements > - Addition of a few explanatory notes > - Reformulation of 1st para of Intro > - In section 4.4.1, revised text on populating From and To=20 > header field URIs > - In section 4.4.2, revised text on updating the remote URI > - In section 4.7, simplified proxy behaviour text > - In section 5.2, improved description of the example > - In section 4.6, verifier behaviour re-aligned with RFC 4474 > - In section 4.4.1, recommendation to regard the dialog as=20 > terminated if 428, 436, 437 or 438 is received in response to=20 > mid-dialog request >=20 > These last two points constitute resolution of the open issue=20 > discussed in San Diego. >=20 > The signatures in the Identity header fields in the examples=20 > will need to be recalculated before publication. >=20 > John > =20 >=20 > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: 09 January 2007 23:50 > > To: i-d-announce@ietf.org > > Cc: sip@ietf.org > > Subject: [Sip] I-D ACTION:draft-ietf-sip-connected-identity-03.txt > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > > This draft is a work item of the Session Initiation=20 > Protocol Working=20 > > Group of the IETF. > >=20 > > Title : Connected Identity in the Session=20 > > Initiation Protocol (SIP) > > Author(s) : J. Elwell > > Filename : draft-ietf-sip-connected-identity-03.txt > > Pages : 24 > > Date : 2007-1-9 > > =09 > > Because of retargeting of a Session Initiation Protocol=20 > (SIP) dialog- > > forming request (changing the value of the Request-URI), the User > > Agent Server (UAS) can have a different identity from=20 > that in the=20 > > To > > header field. This document provides a means for that User Agent > > (UA) to supply its identity to the peer UA by means of a=20 > request in > > the reverse direction and for that identity to be signed by an > >=20 > > Authentication Service. The same mechanism can be used=20 > to indicate=20 > > a > > change of identity during a dialog, e.g., because of=20 > some action in > > the Public Switched Telephone Network (PSTN) behind a gateway. =20 > > This > > document normatively updates RFC 3261 (SIP). > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-i > > dentity-03.txt > >=20 > > To remove yourself from the I-D Announcement list, send a=20 > message to=20 > > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > > the message. > > You can also visit > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > >=20 > > Internet-Drafts are also available by anonymous FTP. Login with the=20 > > username "anonymous" and a password of your e-mail address. After=20 > > logging in, type "cd internet-drafts" and then "get=20 > > draft-ietf-sip-connected-identity-03.txt". > >=20 > > A list of Internet-Drafts directories can be found in=20 > > http://www.ietf.org/shadow.html or=20 > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >=20 > > Internet-Drafts can also be obtained by e-mail. > >=20 > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE > > /internet-drafts/draft-ietf-sip-connected-identity-03.txt". > > =09 > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > >=20 > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 10 06:58:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4c60-0005Lx-Te; Wed, 10 Jan 2007 06:58:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4c5z-0005Lr-Nm for sip@ietf.org; Wed, 10 Jan 2007 06:58:19 -0500 Received: from gesmail.globaledgesoft.com ([203.76.137.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4c5u-0004YK-Oj for sip@ietf.org; Wed, 10 Jan 2007 06:58:19 -0500 Received: from Siddhuxp (unknown [172.16.7.154]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by gesmail.globaledgesoft.com (Postfix) with ESMTP id 4D67E252E2D; Wed, 10 Jan 2007 11:57:59 +0000 (UTC) Message-ID: <001801c734af$2a2a39c0$9a0710ac@globaledgesoft.com> From: "Siddhu" To: "Rathod Subhashchandra" , , References: <000b01c734aa$812097b0$012a320a@telxsi.com> Subject: Re: [Sip] Any freely available SIP/IMS server Date: Wed, 10 Jan 2007 17:32:13 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=neXtPaRt_1168430087" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ------=neXtPaRt_1168430087 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C734DD.43CAA800" This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C734DD.43CAA800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Try Jain-Sip proxy(NIST server) ----- Original Message -----=20 From: Rathod Subhashchandra=20 To: sip@ietf.org ; sip-implementors@cs.columbia.edu=20 Sent: Wednesday, January 10, 2007 4:58 PM Subject: [Sip] Any freely available SIP/IMS server Hi, I have implemented SIP stack with SUBSCRIBE and NOTIFY features. To = test these, I need a SIP/IMS server. Can you please revert me with any freely available server? Thanks in advance. Thanks ! Rathod. -------------------------------------------------------------------------= ----- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------=_NextPart_000_0015_01C734DD.43CAA800 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Try Jain-Sip proxy(NIST server)
----- Original Message -----
From:=20 Rathod=20 Subhashchandra
To: sip@ietf.org ; sip-implementors@cs.colu= mbia.edu=20
Sent: Wednesday, January 10, = 2007 4:58=20 PM
Subject: [Sip] Any freely = available=20 SIP/IMS server

Hi,
 
I = have implemented=20 SIP stack with SUBSCRIBE and NOTIFY features. To test these, I = need a=20 SIP/IMS server.
Can = you please=20 revert me with any freely available server?
 
Thanks in=20 advance.
 
Thanks=20 !
Rathod.
 

_______________________________________________
Sip mailing=20 list  https://www1.ietf.org= /mailman/listinfo/sip
This=20 list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.colu= mbia.edu=20 for questions on current sip
Use sipping@ietf.org for new = developments on=20 the application of sip ------=_NextPart_000_0015_01C734DD.43CAA800-- ------=neXtPaRt_1168430087 Content-Type: text/plain; This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message.Global Edge Software Ltd has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Global Edge Software Ltd reserves the right to monitor and review the content of all messages sent to or from this e-mail address ------=neXtPaRt_1168430087 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------=neXtPaRt_1168430087-- From sip-bounces@ietf.org Wed Jan 10 11:04:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4fum-0000eQ-DX; Wed, 10 Jan 2007 11:03:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4ful-0000eL-A1 for sip@ietf.org; Wed, 10 Jan 2007 11:02:59 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4fug-0003ok-AA for sip@ietf.org; Wed, 10 Jan 2007 11:02:59 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 10 Jan 2007 08:02:53 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l0AG2r2O031326; Wed, 10 Jan 2007 08:02:53 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0AG2kJB000133; Wed, 10 Jan 2007 08:02:53 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 11:02:46 -0500 Received: from [10.86.242.10] ([10.86.242.10]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 11:02:46 -0500 Message-ID: <45A50E25.4060803@cisco.com> Date: Wed, 10 Jan 2007 11:02:45 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF942325670155B415@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF942325670155B415@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jan 2007 16:02:46.0103 (UTC) FILETIME=[C4AF8E70:01C734D0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1541; t=1168444973; x=1169308973; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20TCP=20connection=20establishment=20[was=3A=20RE=3A=20 [Sip]=20Question=20about=20Poll=3A=0A=20Proposal=20relating=20to=20keepali ve,=20TCP,=09and=20UDP=20usage=20in=20draft-ietf-sip-outbound] |Sender:=20; bh=DcPnOIP3rx98uw0qabxO+NfSYSCl9t0M7NkGP/wPTms=; b=TA4rf6E7XLh+m0whS/QxrO90erf8HIOstXi+HQS+lmE+Fwp3aNcpvw4jxtmYksg0gt8tpyvI bCtYO1UjrL/vTyGl+WavUCRIpUdfwT1Dtqukm+mECKn1Vhv8SbonY/Ze; Authentication-Results: sj-dkim-5; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: >> For the TCP case, where separate connections are used for >> each direction, there is no reason to reestablish a >> connection when it goes down, until it is needed for the same >> direction. >> >> For TLS, the reason to do so would be if the connection can't >> be established in the other direction. But that is the >> outbound case. Since we aren't talking about that case here, >> and instead assume that a connection *can* be established in >> either direction, again there is no real reason to >> reestablish a connection at the time one goes down. >> >> Early reestablishment of connections is instead likely to >> prevent the servers from dropping connections when they get too many. > > The idea behind reestablishing the connections is to avoid the post dial > delay of establishing the connection when an INVITE is to be sent. For a UAC, there is typically a lot of extra time between the initiation and the completion of dialing, which can mask a lot of network delay. It has been suggested that ICE begin during this time. Establishing a TCP connection could also happen during this time. But in any case the issue is largely irrelevant I think, because the use of TCP in this way only works if there are no NATs or FWs between the UAC and the proxy, which is likely not to be the case, or at least not known to be the case. Connection reuse is more relevant to connections between servers, with outbound being used for phones. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 10 12:47:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4hX0-0000PE-If; Wed, 10 Jan 2007 12:46:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4hWy-0000JW-PM for sip@ietf.org; Wed, 10 Jan 2007 12:46:32 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4hWx-0000TS-FE for sip@ietf.org; Wed, 10 Jan 2007 12:46:32 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l0AHkQIs020491; Wed, 10 Jan 2007 11:46:26 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l0AHkPu00146; Wed, 10 Jan 2007 11:46:26 -0600 (CST) Message-ID: <45A52671.2030504@alcatel-lucent.com> Date: Wed, 10 Jan 2007 11:46:25 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF942325670155B415@esealmw113.eemea.ericsson.se> <45A50E25.4060803@cisco.com> In-Reply-To: <45A50E25.4060803@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: SIP LIST X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > But in any case the issue is largely irrelevant I think, because the > use of TCP in this way only works if there are no NATs or FWs between > the UAC and the proxy, which is likely not to be the case, or at > least not known to be the case. This I do not understand -- maybe I am missing something. It is true that in many deployments, especially inter-domain deployments, NATs and FWs will dominate, and thus outbound is the only solution here. However, it is also true that a lot of communication traffic between a UAC and proxy will be intra-domain. In such cases, connect-reuse can help because all the communicating endpoints are behind the same enterprise NAT. Hence the assumption in connect-reuse of transitive connectivity. Outbound is the most general and the most expansive solution since it includes multiple flows and keepalives, and Other Nice Things (TM). Connect-reuse simply attempts to fill in some of the blanks of rfc3261. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 10 12:47:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4hWb-0007jC-FG; Wed, 10 Jan 2007 12:46:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (ExFrom sip-bounces@ietf.org Wed Jan 10 12:47:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4hX0-0000PE-If; Wed, 10 Jan 2007 12:46:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4hWy-0000JW-PM for sip@ietf.org; Wed, 10 Jan 2007 12:46:32 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4hWx-0000TS-FE for sip@ietf.org; Wed, 10 Jan 2007 12:46:32 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l0AHkQIs020491; Wed, 10 Jan 2007 11:46:26 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l0AHkPu00146; Wed, 10 Jan 2007 11:46:26 -0600 (CST) Message-ID: <45A52671.2030504@alcatel-lucent.com> Date: Wed, 10 Jan 2007 11:46:25 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF942325670155B415@esealmw113.eemea.ericsson.se> <45A50E25.4060803@cisco.com> In-Reply-To: <45A50E25.4060803@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: SIP LIST X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > But in any case the issue is largely irrelevant I think, because the > use of TCP in this way only works if there are no NATs or FWs between > the UAC and the proxy, which is likely not to be the case, or at > least not known to be the case. This I do not understand -- maybe I am missing something. It is true that in many deployments, especially inter-domain deployments, NATs and FWs will dominate, and thus outbound is the only solution here. However, it is also true that a lot of communication traffic between a UAC and proxy will be intra-domain. In such cases, connect-reuse can help because all the communicating endpoints are behind the same enterprise NAT. Hence the assumption in connect-reuse of transitive connectivity. Outbound is the most general and the most expansive solution since it includes multiple flows and keepalives, and Other Nice Things (TM). Connect-reuse simply attempts to fill in some of the blanks of rfc3261. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 10 12:47:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4hWb-0007jC-FG; Wed, 10 Jan 2007 12:46:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4hWZ-0007fz-Kf for sip@ietf.org; Wed, 10 Jan 2007 12:46:07 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4hWY-0000PP-8r for sip@ietf.org; Wed, 10 Jan 2007 12:46:07 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l0AHk4Hb020136; Wed, 10 Jan 2007 11:46:04 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l0AHjxu29825; Wed, 10 Jan 2007 11:45:59 -0600 (CST) Message-ID: <45A52656.4060806@alcatel-lucent.com> Date: Wed, 10 Jan 2007 11:45:58 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF942325670155B192@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF942325670155B192@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: SIP LIST X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: vkg>Connect-reuse does not talk about the keepalive aspect at all. vkg>Since it does not assume NAT presence, there is no reason vkg>that the connection should be torn down, unless of course one vkg>of the hosts crashes, or actively tears the connection down vkg>to reclaim resources. > > Ok. I don't know TCP well enough. I was thinking about cases where the > connection is unused for long periods of time. Certain shells (tcsh) and some versions of telnet may have an inactivity timer that causes the session to be closed on the absence of I/O for a certain time period. However, this method of timing out TCP connections is application specific and presumably will not be used for SIP. Assuming the application itself does not close the TCP session, the session should stay up. Look at ssh, for instance. On Linux FC5, the ssh server sends out a keepalive probe every 2 hours by default. Assuming that the endpoints do not loose TCP state through a crash or a connection termination, or that your shell does not close the connection, the TCP session is kept alive even if a router reboots in between that 2 hour window. > Also, IF the connection, for whatever reasons, goes down I think it > would be good to suggest that it shall be re-established. In the > registration connection case, would a re-REGISTER have to be sent also? Probably; won't hurt except updating the registration. The advantage would be reducing delay in the session setup requests. vkg>OK; I will add the registration case for TLS transports. vkg>That should not be a problem. Anything else? > > I will look at the whole document more in detail later. For now I was > mostly focusing on the parts affecting this discussion, so... :) OK; if you do get a chance, I'd appreciate a more detailed read- through. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _____im 4.43) id 1H4hWZ-0007fz-Kf for sip@ietf.org; Wed, 10 Jan 2007 12:46:07 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4hWY-0000PP-8r for sip@ietf.org; Wed, 10 Jan 2007 12:46:07 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l0AHk4Hb020136; Wed, 10 Jan 2007 11:46:04 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l0AHjxu29825; Wed, 10 Jan 2007 11:45:59 -0600 (CST) Message-ID: <45A52656.4060806@alcatel-lucent.com> Date: Wed, 10 Jan 2007 11:45:58 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF942325670155B192@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF942325670155B192@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: SIP LIST X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: vkg>Connect-reuse does not talk about the keepalive aspect at all. vkg>Since it does not assume NAT presence, there is no reason vkg>that the connection should be torn down, unless of course one vkg>of the hosts crashes, or actively tears the connection down vkg>to reclaim resources. > > Ok. I don't know TCP well enough. I was thinking about cases where the > connection is unused for long periods of time. Certain shells (tcsh) and some versions of telnet may have an inactivity timer that causes the session to be closed on the absence of I/O for a certain time period. However, this method of timing out TCP connections is application specific and presumably will not be used for SIP. Assuming the application itself does not close the TCP session, the session should stay up. Look at ssh, for instance. On Linux FC5, the ssh server sends out a keepalive probe every 2 hours by default. Assuming that the endpoints do not loose TCP state through a crash or a connection termination, or that your shell does not close the connection, the TCP session is kept alive even if a router reboots in between that 2 hour window. > Also, IF the connection, for whatever reasons, goes down I think it > would be good to suggest that it shall be re-established. In the > registration connection case, would a re-REGISTER have to be sent also? Probably; won't hurt except updating the registration. The advantage would be reducing delay in the session setup requests. vkg>OK; I will add the registration case for TLS transports. vkg>That should not be a problem. Anything else? > > I will look at the whole document more in detail later. For now I was > mostly focusing on the parts affecting this discussion, so... :) OK; if you do get a chance, I'd appreciate a more detailed read- through. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip __________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 10 16:45:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4lF0-0004V7-Ki; Wed, 10 Jan 2007 16:44:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4lEy-0004V2-RI for sip@ietf.org; Wed, 10 Jan 2007 16:44:12 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4lEw-0004gW-3b for sip@ietf.org; Wed, 10 Jan 2007 16:44:12 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 10 Jan 2007 13:44:09 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l0ALi9V1030286; Wed, 10 Jan 2007 13:44:09 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0ALi7JL009231; Wed, 10 Jan 2007 13:44:08 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 13:44:08 -0800 Received: from [10.32.241.158] ([10.32.241.158]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 13:44:07 -0800 Message-ID: <45A55E25.3080904@cisco.com> Date: Wed, 10 Jan 2007 16:44:05 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Lawrence Subject: Re: [Sip] Issue: Expiration of temp-gruu References: <456E15CD.60805@cisco.com> <1165200634.3607.3.camel@localhost.localdomain> <45749DF6.7040803@cisco.com> <1165336240.3208.72.camel@scott.skrb.org> In-Reply-To: <1165336240.3208.72.camel@scott.skrb.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jan 2007 21:44:08.0085 (UTC) FILETIME=[74E5FC50:01C73500] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6726; t=1168465449; x=1169329449; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Issue=3A=20Expiration=20of=20temp-gruu |Sender:=20; bh=ofiL9lfU0Vn74t5KGc/kA4L/FBUz+otdapT/zX2GNmk=; b=Vdom+gcJU0Gc8UqHHAUe03zrThlPraeprhLHNUPvI4Cb8HwqGqxoDImOuPpUGSbQyr+Oon5h Fbbf8/N7JjgC9gfZPP8XLlFkAGK68W3OsQFVehNELmCPQ0nSlknyUeDx; Authentication-Results: sj-dkim-6; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: SIP IETF , Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This thread is a month old, but I want to revise GRUU and get this done. This is really the only issue that is outstanding, I think. To refresh everyones memory, the issue being dsicussed is this. Temp-GRUU expire when the last contact with the instance ID expires. In normal cases, the expiration is known to the UA. However, there are cases where there is a forceful de-registration, for example. In these cases, the UA will not know about it, and it won't know whether its temp-gruu remain valid. We've seen three proposals for how to deal with this: 1. include a parameter in the Contact header field of the REGISTER response, indicating the time at which the first contact with that instance ID was registered. When this changes in a REGSITER response, the UA knows its older temp-gruu are invalid. 2. the UA uses a reg-event subscription, and it gets a NOTIFY when the contacts are de-registered. As long as the UA gets the notification indicating that the de-registration has happened, this works reasonably well. 3. the UA can use an OPTIONS sent to a temp-gruu to verify that it still works (2) and (3) require no new mechanism, just explanation. (1) would require new mechanism. Now, I was in the process of working through some details on this, and ran into problems. In particular, we ultimately need to be able to specify an algorithm that clearly tells a UA which of its temp GRUU are valid, and which are expired. If we are using the reg-event subscription to figure this out, the obvious algorithm would be to expire all temp-gruu learned in REGISTER responses prior to this notification. However, that is imprecise. What about a REGISTER that happens very close in time to the NOTIFY? Indeed, this is very likely to be the case when the reg-event is shortening the expiration in order to ask the user to explicitly re-REGISTER, but the time was a bit too short and the re-REGISTER is close to the boundary. If a NOTIFY comes indicating that the contact did expire, how do you *know* if that REGISTER came in before or after? You could wait for the next NOTIFY, and try and correlate it with the REGISTER you just completed. One way to do that is with CSeq. The reg-event package includes the option of having CSeq numbers. If we assume these are always used (they are optional), the algorithm is a bit easier. Each temp-gruu is associated with the CSeq of the REGISTER in which it was learned. When a NOTIFY comes indicating that the registration has expired, you look to see if its a partial or full state NOTIFY. In the case of partial, if the NOTIFY explicitly removes a contact, you invalidate all temp-gruu learned in register responses prior to or equal to the CSeq in the contact. If the case of a full state NOTIFY, if the contact is absent, the UA marks all temp-gruu as suspect. On the first NOTIFY that indicates the Contact is re-registered (I assume the UA is re-registering), the UA invalidates all temp-gruu learned by REGISTER responses whose CSeq is less than the one in the NOTIFY. All others are considered valid. This algorithm is assuming some very specific behavior from registrars that are doing reg-event with GRUU. Namely, they always send CSeq, even when indicating expiration of a contact. We'd need to specify this, probably as a note in gruu-reg-event. Comments on this algorithm? If this is OK I will update GRUU based on this and we can ship it. Finally. Really this time. -Jonathan R. Scott Lawrence wrote: > On Mon, 2006-12-04 at 17:15 -0500, Paul Kyzivat wrote: > >>Scott, >> >>Its certainly true that a gruu can always be tested to see if it works. >>That would however raise the question of when one ought to do the test. >>In normal cases you will know the status of your gruu by regular >>methods, so you would have no reason to test it. So you would have to >>test whenever you thought failure might have negative consequences. Some >>of the times when failure might have bad consequences are: when >>responding to an incoming INVITE, and any time during a dialog. I guess >>you could send an OPTIONS and await the response before responding to an >>INVITE, and it might even be masked by alerting, but it seems kind of >>annoying to have to do that. But no matter how often you do it during a >>dialog you still might miss the moment your gruu becomes invalid and the >>other end of the dialog sends you a message. (Extremely unlikely, but >>possible.) >> >>I think the other existing solutions get "pretty close", and OPTIONS >>doesn't significantly improve on that. > > > I don't like requiring the registrar to return a timestamp because it's > yet another piece of state that it has to keep for every registration. > > I don't think it actually helps all that much - going back to your > original problem statements: > > >>3) the UA may attempt to refresh the registration, but be too slow, >> so that the reregistration arrives after the prior one expires >>4) some other UA may deregister all the registrations, including >> the one by this UA. (When the UA decides it should refresh the >> registration it will actually create a new one.) >>5) the registrar may remove the registration administratively >>6) the registrar may crash and restart, losing all its registrations > > > Case 3 can be avoided by just not waiting too long (overlap by a few > minutes instead of a few seconds - if that's still problematic then you > probably have other problems that are worse anyway). > > Cases 4,5, and 6 are essentially all the same from the point of view of > the UA; your registration state at the server is lost because of some > event you are not aware of. This is true of any registration, and is > not specific to temp-gruu or public gruu; it can happen with a Contact > value you provide without gruu at all. A gruu is slightly worse in that > loosing the state can affect in-dialog requests for established dialogs, > but I think that's just an unavoidable chance that you take when you > choose to use a gruu of either kind. Put another way, if you use a > gruu, you accept the fact that you're relying on an additional service > for in-dialog connectivity - it's either worth the benefits or it isn't. > > > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 11 05:28:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4x9A-00048m-RI; Thu, 11 Jan 2007 05:27:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4x99-00048g-9w for sip@ietf.org; Thu, 11 Jan 2007 05:26:59 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4x95-00043Z-SZ for sip@ietf.org; Thu, 11 Jan 2007 05:26:59 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 19F245CC; Thu, 11 Jan 2007 11:26:51 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 11:26:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Date: Thu, 11 Jan 2007 11:26:49 +0100 Message-ID: <7374777208BDC7449D5620EF94232567015EC3DF@esealmw113.eemea.ericsson.se> In-Reply-To: <45A50E25.4060803@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Thread-Index: Acc00M0J0JG5TBEpQw+D93gV0g2roQAmdCTg From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 11 Jan 2007 10:26:50.0744 (UTC) FILETIME=[01919780:01C7356B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>>For the TCP case, where separate connections are used for each=20 >>>direction, there is no reason to reestablish a connection when it=20 >>>goes down, until it is needed for the same direction. >>> >>>For TLS, the reason to do so would be if the connection can't be=20 >>>established in the other direction. But that is the outbound case.=20 >>>Since we aren't talking about that case here, and instead assume that >>>a connection *can* be established in either direction, again there is >>>no real reason to reestablish a connection at the time one goes down. >>> >>>Early reestablishment of connections is instead likely to prevent the >>>servers from dropping connections when they get too many. >>=20 >>The idea behind reestablishing the connections is to avoid the post=20 >>dial delay of establishing the connection when an INVITE is to be sent. >=20 >For a UAC, there is typically a lot of extra time between the=20 >initiation and the completion of dialing, which can mask a=20 >lot of network delay. It has been suggested that ICE begin=20 >during this time. Establishing a TCP connection could also=20 >happen during this time. You could have some speed-dial button which basically sends the INVITE as soon as you press that button. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 11 05:30:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4xC5-00050E-Ii; Thu, 11 Jan 2007 05:30:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4xC3-0004zV-WD for sip@ietf.org; Thu, 11 Jan 2007 05:30:00 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4xBz-0004JB-4H for sip@ietf.org; Thu, 11 Jan 2007 05:29:59 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 940D14F0002; Thu, 11 Jan 2007 11:29:54 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 11:29:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Date: Thu, 11 Jan 2007 11:29:53 +0100 Message-ID: <7374777208BDC7449D5620EF94232567015EC411@esealmw113.eemea.ericsson.se> In-Reply-To: <45A52656.4060806@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Thread-Index: Acc03zTRJIK/x2mbRJmnHVGQB0kchwAi+DvA From: "Christer Holmberg \(JO/LMF\)" To: "Vijay K. Gurbani" X-OriginalArrivalTime: 11 Jan 2007 10:29:54.0393 (UTC) FILETIME=[6F083490:01C7356B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: SIP LIST X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, >>Also, IF the connection, for whatever reasons, goes down I think it would be good to suggest that it shall be re-established. In the=20 >>registration connection case, would a re-REGISTER have to be sent also? >=20 >Probably; won't hurt except updating the registration. The advantage would be reducing delay in the session setup requests. Exactly, and that is what I have been talking about :) Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 11 06:05:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4xjL-0004TV-UD; Thu, 11 Jan 2007 06:04:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4xjL-0004Rv-1E for sip@ietf.org; Thu, 11 Jan 2007 06:04:23 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4xjH-0001OX-Jx for sip@ietf.org; Thu, 11 Jan 2007 06:04:23 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 222354F0001; Thu, 11 Jan 2007 12:00:45 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 12:00:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Date: Thu, 11 Jan 2007 12:00:44 +0100 Message-ID: <7374777208BDC7449D5620EF94232567015EC5B0@esealmw113.eemea.ericsson.se> In-Reply-To: <45A50E25.4060803@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] Thread-Index: Acc00M0J0JG5TBEpQw+D93gV0g2roQAmqlbQ From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 11 Jan 2007 11:00:44.0741 (UTC) FILETIME=[BDECE750:01C7356F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>The idea behind reestablishing the connections is to avoid the post dial delay of establishing the connection when an INVITE is=20 >>to be sent. >=20 >For a UAC, there is typically a lot of extra time between the=20 >initiation and the completion of dialing, which can mask a=20 >lot of network delay. It has been suggested that ICE begin=20 >during this time. Establishing a TCP connection could also=20 >happen during this time. >=20 >But in any case the issue is largely irrelevant I think,=20 >because the use of TCP in this way only works if there are no=20 >NATs or FWs between the UAC and the proxy, For TCP that is true, yes.=20 But, for TLS, where you have a bidirectional connection, connection reuse should work fine also with NATs or FWs. This of course assumes that the UA keep the connection open all the time (and re-establishes it when it for whatever reason fails), in order to allow inbound requests to reach the UA. So, in this case, if you can live without the multiflow feature outbound provides I think connection reuse would work perfectly. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 11 06:38:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4yFp-0003zw-S3; Thu, 11 Jan 2007 06:37:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4yFo-0003zr-Qq for sip@ietf.org; Thu, 11 Jan 2007 06:37:56 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4yFj-0008NW-Qq for sip@ietf.org; Thu, 11 Jan 2007 06:37:56 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0BBZohn017201; Thu, 11 Jan 2007 13:35:51 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 13:37:43 +0200 Received: from esebe104.NOE.Nokia.com ([172.21.143.44]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 13:37:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Thu, 11 Jan 2007 13:37:42 +0200 Message-ID: <719D5CCC2F6E3644B0A9F5C9B1D00088027902A4@esebe104.NOE.Nokia.com> In-Reply-To: <7.0.1.0.0.20070109193434.05772a58@iptel.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Thread-Index: Acc0Hc1ZMGSx/vPcQYWBLoYlo64T6wBULebQ From: To: , , X-OriginalArrivalTime: 11 Jan 2007 11:37:43.0267 (UTC) FILETIME=[E8451B30:01C73574] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: sip@ietf.org, audet@nortel.com, dean.willis@softarmor.com, bstucker@nortel.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hello all, On 09 Jan 2007, Jiri Kuthan wrote: >At 16:43 09/01/2007, Kai.Vehmanen@nokia.com wrote: >>these sound about right. But I'd say this is mostly due to lack of=20 >>demand, rather than fundamental technical limitations of scaling TCP in=20 >>SIP servers. > >I would say both. At least for us, drilling OS kernel and=20 >dealing with memory consumption was a laborous exercises.=20 yes, it's definitely not a trivial task either. On the bright side, SIP server implementors are not alone with this -- more and more applications have similar requirements - AJAX-style web services, email (especially=20 the push variants), TLS-VPNs, etc, etc... all require more or less persistent TCP connections, and lots and lots of them. To implement the server end for these services on a massive scale, one will face similar problems than in scaling SIP servers which solely use TCP as the client-oproxy transport. And hey, having hundreds of thousands of clients sending keepalives and some real traffic to a small set of UDP ports is not exactly=20 a trivial problem either... solvable, but not trivial. >>were mostly positive. We were able to hit 100k simultanenous=20 >>registrations with TCP with commodity PC hw and sw combo. All in all,=20 >>scalability of TCP, although with some per-connection overhead, was=20 >>nearly identical to UDP (both limited by available CPU&memory, with=20 >>linear growth of resource usage). And further, the keepalive traffic=20 >>had very little performance impact in terms of CPU > >Was that impact on the overall performance (including database=20 >access, processing user profile, etc.) or just stack throughput? The tests were done with a dummy registrar database (the REGISTERs were processed normally, updating the in-memory db, but not stored=20 to a persistent database). This made sense, as we wanted to benchmark=20 TCP-vs-UDP specifically, and the cost of database access is same=20 for both. --=20 first.surname@nokia.com (Kai Vehmanen), Nokia Research Center _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 11 06:46:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4yOG-0000Oj-3D; Thu, 11 Jan 2007 06:46:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4yOE-0000Od-IQ for sip@ietf.org; Thu, 11 Jan 2007 06:46:38 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4yOD-0001WH-4l for sip@ietf.org; Thu, 11 Jan 2007 06:46:38 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0BBit1R026053; Thu, 11 Jan 2007 13:45:07 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 13:46:31 +0200 Received: from [172.21.39.124] ([172.21.39.124]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 11 Jan 2007 13:46:30 +0200 Subject: Re: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] From: Aki Niemi To: ext Paul Kyzivat In-Reply-To: <45A50E25.4060803@cisco.com> References: <7374777208BDC7449D5620EF942325670155B415@esealmw113.eemea.ericsson.se> <45A50E25.4060803@cisco.com> Content-Type: text/plain Organization: Nokia-NRC/Helsinki Date: Thu, 11 Jan 2007 13:47:11 +0200 Message-Id: <1168516031.10837.45.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2007 11:46:30.0286 (UTC) FILETIME=[2265D2E0:01C73576] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: SIP , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Wed, 2007-01-10 at 11:02 -0500, ext Paul Kyzivat wrote: > For a UAC, there is typically a lot of extra time between the initiation > and the completion of dialing, which can mask a lot of network delay. It > has been suggested that ICE begin during this time. Establishing a TCP > connection could also happen during this time. I think this is less and less the case. I expect most calls to be initiated via a buddylist or phonebook type application, or even via linked phone numbers in an email message. In those cases, there is no delay between initiation and completion of the "dialing" since it's a single action. Personally, I can't remember the last time I actually dialed to make a phone call -- even a CS one. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 11 07:20:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4ytw-0008FA-Vz; Thu, 11 Jan 2007 07:19:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4ytv-0008F5-Op for sip@ietf.org; Thu, 11 Jan 2007 07:19:23 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4yts-0008LG-B5 for sip@ietf.org; Thu, 11 Jan 2007 07:19:23 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 961914F0002; Thu, 11 Jan 2007 12:49:23 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 12:49:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] Date: Thu, 11 Jan 2007 12:49:22 +0100 Message-ID: <7374777208BDC7449D5620EF94232567015EC800@esealmw113.eemea.ericsson.se> In-Reply-To: <1168516031.10837.45.camel@macbuster.research.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] Thread-Index: Acc1djhtVjPJvLYKTjuWJ4L2YB8DbwAACVUQ From: "Christer Holmberg \(JO/LMF\)" To: "Aki Niemi" , "ext Paul Kyzivat" X-OriginalArrivalTime: 11 Jan 2007 11:49:23.0364 (UTC) FILETIME=[898F6E40:01C73576] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 >>For a UAC, there is typically a lot of extra time between the=20 >>initiation and the completion of dialing, which can mask a lot of=20 >>network delay. It has been suggested that ICE begin during=20 >>this time.=20 >>Establishing a TCP connection could also happen during this time. >=20 >I think this is less and less the case. I expect most calls=20 >to be initiated via a buddylist or phonebook type=20 >application, or even via linked phone numbers in an email=20 >message. In those cases, there is no delay between initiation=20 >and completion of the "dialing" since it's a single action. I agree. >Personally, I can't remember the last time I actually dialed=20 >to make a phone call -- even a CS one. That's because finns never make any phone calls - we only send SMS :) Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 11 09:10:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H50bF-0001Yh-Qr; Thu, 11 Jan 2007 09:08:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H50bD-0001Yc-US for sip@ietf.org; Thu, 11 Jan 2007 09:08:11 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H50aN-0001cG-LR for sip@ietf.org; Thu, 11 Jan 2007 09:08:11 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 11 Jan 2007 06:07:19 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l0BE7JD1005412; Thu, 11 Jan 2007 06:07:19 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0BE72i8016900; Thu, 11 Jan 2007 06:07:18 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 09:07:17 -0500 Received: from [10.86.242.10] ([10.86.242.10]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 09:07:17 -0500 Message-ID: <45A64494.5010705@cisco.com> Date: Thu, 11 Jan 2007 09:07:16 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF94232567015EC5B0@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF94232567015EC5B0@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2007 14:07:17.0302 (UTC) FILETIME=[CD362D60:01C73589] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1374; t=1168524439; x=1169388439; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20TCP=20connection=20establishment=20[was=3A=20RE=3A=20 [Sip]=20Question=20about=20Poll=3A=0A=20Proposal=20relating=20to=20keepali ve,=20TCP,=09and=20UDP=20usage=20in=20draft-ietf-sip-outbound] |Sender:=20; bh=5L00CiFsZ0YtyrlZNv9G2AuodKZXjwj8nT8mdbVgPVw=; b=IWwHsobAkNuIvRGIqp/n+ZEQjNCbj5LbzviAPZCY9/gT52+l9aqh8GlApmAbNIAwFE8lxV/x 8FZT802uSmHtEKMCYav+OcemZL2NlUGHjtUiyTB17brbV0JOIYcTipmT; Authentication-Results: sj-dkim-8; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > Hi, > >>> The idea behind reestablishing the connections is to avoid the post > dial delay of establishing the connection when an INVITE is >>> to be sent. >> For a UAC, there is typically a lot of extra time between the >> initiation and the completion of dialing, which can mask a >> lot of network delay. It has been suggested that ICE begin >> during this time. Establishing a TCP connection could also >> happen during this time. >> >> But in any case the issue is largely irrelevant I think, >> because the use of TCP in this way only works if there are no >> NATs or FWs between the UAC and the proxy, > > For TCP that is true, yes. > > But, for TLS, where you have a bidirectional connection, connection > reuse should work fine also with NATs or FWs. This of course assumes > that the UA keep the connection open all the time (and re-establishes it > when it for whatever reason fails), in order to allow inbound requests > to reach the UA. > > So, in this case, if you can live without the multiflow feature outbound > provides I think connection reuse would work perfectly. I thought this particular thread was about TCP, not TLS. The issues are quite different for the two. I think I agree that simply maintaining a TLS connection might be an alternative to outbound in some cases. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 11 09:10:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H50df-0002mC-LM; Thu, 11 Jan 2007 09:10:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H50de-0002m3-7F for sip@ietf.org; Thu, 11 Jan 2007 09:10:42 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H50dG-0002AM-HC for sip@ietf.org; Thu, 11 Jan 2007 09:10:42 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 11 Jan 2007 06:10:18 -0800 X-IronPort-AV: i="4.13,172,1167638400"; d="scan'208"; a="758952252:sNHT47335432" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l0BEAHEc006543; Thu, 11 Jan 2007 06:10:17 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l0BEAAV6014554; Thu, 11 Jan 2007 06:10:16 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 09:05:12 -0500 Received: from [10.86.242.10] ([10.86.242.10]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 09:05:11 -0500 Message-ID: <45A64416.5000704@cisco.com> Date: Thu, 11 Jan 2007 09:05:10 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: TCP connection establishment [was: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF94232567015EC3DF@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF94232567015EC3DF@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2007 14:05:11.0577 (UTC) FILETIME=[82461090:01C73589] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1070; t=1168524618; x=1169388618; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20TCP=20connection=20establishment=20[was=3A=20RE=3A=20 [Sip]=20Question=20about=20Poll=3A=0A=20Proposal=20relating=20to=20keepali ve,=20TCP,=09and=20UDP=20usage=20in=20draft-ietf-sip-outbound] |Sender:=20; bh=I0JQI5HYiV+VnsDpt4s++G5lEwB6F4d5PTVb4tj747o=; b=TGAnRuHKR4k2Mi4lRUjwwtCcFtmXqDhCQtafMC524iJAihku5J/Pt7xZ4PNMh27xjqhtHw5Y Mr2pGYVzLCv2rgbvMyhwKUoDaQSfQrKo74gyVpJCtb3Npd1+d1gYbWbJ; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: >> For a UAC, there is typically a lot of extra time between the >> initiation and the completion of dialing, which can mask a >> lot of network delay. It has been suggested that ICE begin >> during this time. Establishing a TCP connection could also >> happen during this time. > > You could have some speed-dial button which basically sends the INVITE > as soon as you press that button. Yes, that is possible. This starts to get into the detailed design of the user interface of the device. In many, but not all, cases there is some UI clue that you are about to do something, which could be used by the device as a hint to start some of the housekeeping operations. For instance opening the phone. Whether that will get better or worse as devices and UIs evolve is TBD. As long as there is some work that needs to be hidden there will be an incentive to construct the UI so as to hide it. Keeping a connection all the time is an alternative if the costs of doing so are acceptable. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 11 10:30:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H51rQ-0003DN-Id; Thu, 11 Jan 2007 10:29:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H51rP-0003DC-6Q for sip@ietf.org; Thu, 11 Jan 2007 10:28:59 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H51rN-0004OE-Nl for sip@ietf.org; Thu, 11 Jan 2007 10:28:59 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0BFQTZ0011910; Thu, 11 Jan 2007 17:26:57 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 17:28:52 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 17:28:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] Date: Thu, 11 Jan 2007 17:28:49 +0200 Message-ID: In-Reply-To: <1168516031.10837.45.camel@macbuster.research.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] Thread-Index: Acc1djaj6aJ8gIi0Sre8SuJj4KZH6wAHdgiQ From: To: , X-OriginalArrivalTime: 11 Jan 2007 15:28:51.0607 (UTC) FILETIME=[3271DA70:01C73595] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip@ietf.org, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I agree with Aki. We are fooling ourselves if we think that the potential delay problems with ICE or TCP connection setups etc. can be cured with this kind of tricks. In general delays may not be an issue, but in wireless access they can be.=20 Markus=20 >-----Original Message----- >From: ext Aki Niemi [mailto:aki.niemi@nokia.com]=20 >Sent: 11 January, 2007 13:47 >To: ext Paul Kyzivat >Cc: SIP; Christer Holmberg (JO/LMF) >Subject: Re: TCP connection establishment [was: RE: [Sip]=20 >Question aboutPoll: Proposal relating to keepalive, TCP, and=20 >UDP usage indraft-ietf-sip-outbound] > >On Wed, 2007-01-10 at 11:02 -0500, ext Paul Kyzivat wrote: >> For a UAC, there is typically a lot of extra time between the=20 >> initiation and the completion of dialing, which can mask a lot of=20 >> network delay. It has been suggested that ICE begin during=20 >this time.=20 >> Establishing a TCP connection could also happen during this time. > >I think this is less and less the case. I expect most calls to=20 >be initiated via a buddylist or phonebook type application, or=20 >even via linked phone numbers in an email message. In those=20 >cases, there is no delay between initiation and completion of=20 >the "dialing" since it's a single action. > >Personally, I can't remember the last time I actually dialed=20 >to make a phone call -- even a CS one. > >Cheers, >Aki > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 11 12:39:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H53tB-0005Ry-F4; Thu, 11 Jan 2007 12:38:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H53t9-0005Ov-Ou for sip@ietf.org; Thu, 11 Jan 2007 12:38:55 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H53t7-0001Js-SH for sip@ietf.org; Thu, 11 Jan 2007 12:38:55 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 11 Jan 2007 09:38:53 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l0BHcrij024075; Thu, 11 Jan 2007 09:38:53 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0BHcqnH023125; Thu, 11 Jan 2007 09:38:53 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 12:38:52 -0500 Received: from [10.86.242.10] ([10.86.242.10]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 12:38:52 -0500 Message-ID: <45A6762B.8040201@cisco.com> Date: Thu, 11 Jan 2007 12:38:51 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Markus.Isomaki@nokia.com Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2007 17:38:52.0497 (UTC) FILETIME=[5C233410:01C735A7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2405; t=1168537133; x=1169401133; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20TCP=20connection=20establishment=20[was=3A=20RE=3A=20 [Sip]=20Question=20aboutPoll=3A=0A=20Proposal=20relating=20to=20keepalive, =20TCP,=20and=20UDP=20usage=20indraft-ietf-sip-outbound] |Sender:=20; bh=Qd4fC3O0i1QctK/ABxIIxu/fewXJFVFhB7w+omrXiHI=; b=vq1PGlVAxEJ4jOICLAa5Qdz40eWjlmetZg0kuioWrMY2pVTw9zhib59s/0iForge+PlPqQqG WG4PrJkYcnMW7lXLsmZlm5HkqK5f1g8kfckFZ9jl0NTMItfqZwgt9I+j; Authentication-Results: sj-dkim-8; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: sip@ietf.org, aki.niemi@nokia.com, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm not objecting to establishing connections early, especially if doing so is needed to establish connectivity in the reverse direction. But when the connection is not required to establish connectivity in the reverse direction, and a connection has been dropped by the far end, then insisting on reestablishing it directly can be counterproductive to a server that has more connections than it can handle. So, if you have had your connection dropped, and you don't need it right now, I still think it would be best to wait until you do need it before attempting to reestablish it. Paul Markus.Isomaki@nokia.com wrote: > Hi, > > I agree with Aki. We are fooling ourselves if we think that the > potential delay problems with ICE or TCP connection setups etc. can be > cured with this kind of tricks. In general delays may not be an issue, > but in wireless access they can be. > > Markus > > >> -----Original Message----- >> From: ext Aki Niemi [mailto:aki.niemi@nokia.com] >> Sent: 11 January, 2007 13:47 >> To: ext Paul Kyzivat >> Cc: SIP; Christer Holmberg (JO/LMF) >> Subject: Re: TCP connection establishment [was: RE: [Sip] >> Question aboutPoll: Proposal relating to keepalive, TCP, and >> UDP usage indraft-ietf-sip-outbound] >> >> On Wed, 2007-01-10 at 11:02 -0500, ext Paul Kyzivat wrote: >>> For a UAC, there is typically a lot of extra time between the >>> initiation and the completion of dialing, which can mask a lot of >>> network delay. It has been suggested that ICE begin during >> this time. >>> Establishing a TCP connection could also happen during this time. >> I think this is less and less the case. I expect most calls to >> be initiated via a buddylist or phonebook type application, or >> even via linked phone numbers in an email message. In those >> cases, there is no delay between initiation and completion of >> the "dialing" since it's a single action. >> >> Personally, I can't remember the last time I actually dialed >> to make a phone call -- even a CS one. >> >> Cheers, >> Aki >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 11 12:48:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H541y-0002El-8R; Thu, 11 Jan 2007 12:48:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H541w-0002Eg-1l for sip@ietf.org; Thu, 11 Jan 2007 12:48:00 -0500 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H541u-0002Vw-H9 for sip@ietf.org; Thu, 11 Jan 2007 12:48:00 -0500 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 6539A20A6C4; Thu, 11 Jan 2007 18:47:55 +0100 (CET) Message-Id: <7.0.1.0.0.20070111184459.02ae1e18@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 11 Jan 2007 18:47:54 +0100 To: Paul Kyzivat , Markus.Isomaki@nokia.com From: Jiri Kuthan Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] In-Reply-To: <45A6762B.8040201@cisco.com> References: <45A6762B.8040201@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: sip@ietf.org, aki.niemi@nokia.com, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org That's true but is that the mainstream case? I'm under impression that mostly clients register to be able to get SIP traffic back. Server overload has to be then handled on server side. Clients unreachable because overloaded server are same unpleasent as clients unreachable because of disconnected TCP connections. -jiri At 18:38 11/01/2007, Paul Kyzivat wrote: >I'm not objecting to establishing connections early, especially if doing so is needed to establish connectivity in the reverse direction. But when the connection is not required to establish connectivity in the reverse direction, and a connection has been dropped by the far end, then insisting on reestablishing it directly can be counterproductive to a server that has more connections than it can handle. So, if you have had your connection dropped, and you don't need it right now, I still think it would be best to wait until you do need it before attempting to reestablish it. > > Paul > >Markus.Isomaki@nokia.com wrote: >>Hi, >>I agree with Aki. We are fooling ourselves if we think that the >>potential delay problems with ICE or TCP connection setups etc. can be >>cured with this kind of tricks. In general delays may not be an issue, >>but in wireless access they can be. >>Markus >> >>>-----Original Message----- >>>From: ext Aki Niemi [mailto:aki.niemi@nokia.com] Sent: 11 January, 2007 13:47 >>>To: ext Paul Kyzivat >>>Cc: SIP; Christer Holmberg (JO/LMF) >>>Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] >>> >>>On Wed, 2007-01-10 at 11:02 -0500, ext Paul Kyzivat wrote: >>>>For a UAC, there is typically a lot of extra time between the initiation and the completion of dialing, which can mask a lot of network delay. It has been suggested that ICE begin during >>>this time. >>>>Establishing a TCP connection could also happen during this time. >>>I think this is less and less the case. I expect most calls to be initiated via a buddylist or phonebook type application, or even via linked phone numbers in an email message. In those cases, there is no delay between initiation and completion of the "dialing" since it's a single action. >>> >>>Personally, I can't remember the last time I actually dialed to make a phone call -- even a CS one. >>> >>>Cheers, >>>Aki >>> >>> >>>_______________________________________________ >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 11 14:03:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H55CN-0002Kk-GY; Thu, 11 Jan 2007 14:02:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H55CM-0002KF-3m for sip@ietf.org; Thu, 11 Jan 2007 14:02:50 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H55CJ-0003es-No for sip@ietf.org; Thu, 11 Jan 2007 14:02:50 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 11 Jan 2007 11:02:47 -0800 X-IronPort-AV: i="4.13,174,1167638400"; d="scan'208"; a="50611584:sNHT54624250" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0BJ2lhZ011780; Thu, 11 Jan 2007 14:02:47 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0BJ2hVZ011333; Thu, 11 Jan 2007 14:02:44 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 14:02:43 -0500 Received: from [10.86.242.10] ([10.86.242.10]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 14:02:43 -0500 Message-ID: <45A689D2.4010402@cisco.com> Date: Thu, 11 Jan 2007 14:02:42 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Jiri Kuthan Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] References: <45A6762B.8040201@cisco.com> <7.0.1.0.0.20070111184459.02ae1e18@iptel.org> In-Reply-To: <7.0.1.0.0.20070111184459.02ae1e18@iptel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2007 19:02:43.0553 (UTC) FILETIME=[12E16D10:01C735B3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3799; t=1168542167; x=1169406167; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20TCP=20connection=20establishment=20[was=3A=20RE=3A=20 [Sip]=20Question=20=20aboutPoll=3A=0A=20Proposal=20relating=20to=20keepali ve,=20TCP,=20and=20UDP=20usage=20=20indraft-ietf-sip-outbound] |Sender:=20 |To:=20Jiri=20Kuthan=20; bh=4FFos55gYwDxnBL65xUqr9IN83+IyloQdnBeHEUunl4=; b=h4m/x+TcQyACelH5dK7X8IORh8eFrk0ivKR0rsGjR/4JZABsgcezoJixSDDAORrLc9ybY0Nr TEJk7pQXaScW9rNXJh1RXJoN1SDs+afgxv0himNlbAVqxM2BOy7P8z6r; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: sip@ietf.org, christer.holmberg@ericsson.com, aki.niemi@nokia.com, Markus.Isomaki@nokia.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jiri Kuthan wrote: > That's true but is that the mainstream case? I'm under impression that mostly > clients register to be able to get SIP traffic back. Server overload has to > be then handled on server side. Clients unreachable because overloaded > server are same unpleasent as clients unreachable because of disconnected TCP > connections. If the server cannot establish a connection to the client, but the client can establish a TLS connection with mutual authentication, then that could qualify the client as *needing* a connection. I'm talking about other cases. In particular, if we are talking about TCP rather than TLS, then the client establishing a TCP connection doesn't establish a reverse path, unless outbound is used. You can register with a server in order to receive outbound calls without maintaining a connection, as long as the server can establish a connection when it is needed. Paul > -jiri > > At 18:38 11/01/2007, Paul Kyzivat wrote: >> I'm not objecting to establishing connections early, especially if doing so is needed to establish connectivity in the reverse direction. But when the connection is not required to establish connectivity in the reverse direction, and a connection has been dropped by the far end, then insisting on reestablishing it directly can be counterproductive to a server that has more connections than it can handle. So, if you have had your connection dropped, and you don't need it right now, I still think it would be best to wait until you do need it before attempting to reestablish it. >> >> Paul >> >> Markus.Isomaki@nokia.com wrote: >>> Hi, >>> I agree with Aki. We are fooling ourselves if we think that the >>> potential delay problems with ICE or TCP connection setups etc. can be >>> cured with this kind of tricks. In general delays may not be an issue, >>> but in wireless access they can be. >>> Markus >>> >>>> -----Original Message----- >>>> From: ext Aki Niemi [mailto:aki.niemi@nokia.com] Sent: 11 January, 2007 13:47 >>>> To: ext Paul Kyzivat >>>> Cc: SIP; Christer Holmberg (JO/LMF) >>>> Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] >>>> >>>> On Wed, 2007-01-10 at 11:02 -0500, ext Paul Kyzivat wrote: >>>>> For a UAC, there is typically a lot of extra time between the initiation and the completion of dialing, which can mask a lot of network delay. It has been suggested that ICE begin during >>>> this time. >>>>> Establishing a TCP connection could also happen during this time. >>>> I think this is less and less the case. I expect most calls to be initiated via a buddylist or phonebook type application, or even via linked phone numbers in an email message. In those cases, there is no delay between initiation and completion of the "dialing" since it's a single action. >>>> >>>> Personally, I can't remember the last time I actually dialed to make a phone call -- even a CS one. >>>> >>>> Cheers, >>>> Aki >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > -- > Jiri Kuthan http://iptel.org/~jiri/ > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 11 16:30:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57Up-0001uT-Dg; Thu, 11 Jan 2007 16:30:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57Un-0001uN-Os for sip@ietf.org; Thu, 11 Jan 2007 16:30:01 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H57Um-0000DN-9d for sip@ietf.org; Thu, 11 Jan 2007 16:30:01 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0BLS68N016132 for ; Thu, 11 Jan 2007 23:28:31 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 23:29:53 +0200 Received: from [10.241.53.53] ([10.241.53.53]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 11 Jan 2007 23:29:52 +0200 Message-ID: <45A6AC4F.4070102@nokia.com> Date: Thu, 11 Jan 2007 23:29:51 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 CC: sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-uri-list-message-01.txt References: <200701082233.l08MXOt1032079@dragon.ariadne.com> In-Reply-To: <200701082233.l08MXOt1032079@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2007 21:29:52.0307 (UTC) FILETIME=[A13A6030:01C735C7] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Interesting..... There are in my source file, so some how they got lost in between my source file and the I-D Administrator. /Miguel sip-bounces@ietf.org wrote: > Title : Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP) > Author(s) : M. Garcia-Martin, G. Camarillo > Filename : draft-ietf-sip-uri-list-message-01.txt > Pages : 18 > Date : 2007-1-8 > > There are no form-feeds (^L) in this file. > > Dale > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net Nokia Research Center Helsinki, Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 11 16:41:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57fW-0004iG-0l; Thu, 11 Jan 2007 16:41:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57fT-0004i6-JR for sip@ietf.org; Thu, 11 Jan 2007 16:41:03 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H57fS-0003qM-47 for sip@ietf.org; Thu, 11 Jan 2007 16:41:03 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0BLcXhD005679; Thu, 11 Jan 2007 23:39:00 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 23:40:16 +0200 Received: from [10.241.53.53] ([10.241.53.53]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 11 Jan 2007 23:40:15 +0200 Message-ID: <45A6AEBE.8080304@nokia.com> Date: Thu, 11 Jan 2007 23:40:14 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: dale.worley@comcast.net Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-multiple-refer-01.txt References: <005e01c733df$b32b6e40$5208120a@china.huawei.com> <200701091548.l09FmSqH010591@dragon.ariadne.com> In-Reply-To: <200701091548.l09FmSqH010591@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2007 21:40:15.0912 (UTC) FILETIME=[14ECF280:01C735C9] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070111233901-14F4EBB0-15A6AEF7/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: sip@ietf.org, Gonzalo Camarillo X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jaimin, Dael: The draft speaks about repeated URIs, meaning equivalent URIs. I see the point that Dale wrote on equivalent URIs, which has been already discovered by GRUU. I also agree that we should have similar considerations here. If we need such text, it should be written in the framework for URI-list services, since it applies to any draft, not only the REFER draft. http://www.ietf.org/internet-drafts/draft-ietf-sipping-uri-services-06.txt /Miguel sip-bounces@ietf.org wrote: > From: Jaimin Pancholi > > As per the draft: > If the URI-list of the REFER request contains a repeated URI, the > REFER-Recipient MUST behave as if that URI appeared in the URI-list > only once. The REFER-Recipient uses the comparison rules specific to > the URI scheme of each of the URIs in the URI-list to determine if > there is any URI which appears more than once. > > Now if URI is appearing twice with different copy control or other > attribute, which URI should [be used?] > > The problem is worse than this. Due to the strange rules for SIP URI > equivalence, these are equivalent: > > sip:foo@example.com > sip:foo@example.com;parameter=value > > and these are equivalent: > > sip:foo@example.com > sip:foo@example.com;parameter=other-value > > but these are *not* equivalent: > > sip:foo@example.com;parameter=value > sip:foo@example.com;parameter=other-value > > So if all three are present in a URI-list, it's not even clear how > many should be used. > > I seem to remember having a similar problem in the GRUU discussion, > and the outcome was that the GRUU I-D needed to define a new > comparison between SIP URIs that was stricter than 3261's > "equivalence". > > It appears that we need that same comparison here. > > This leads me to ask if we should entirely replace the definition of > "equivalent URIs" in section 19.1.4 of RFC 3261. I did a quick search > of the text of 3261, and it doesn't appear that the equivalence of > URIs is *used* anywhere. > > Dale > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net Nokia Research Center Helsinki, Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 12 02:10:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5GXV-0000Pc-Ih; Fri, 12 Jan 2007 02:09:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5GXU-0000PP-0s for sip@ietf.org; Fri, 12 Jan 2007 02:09:24 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5GXQ-0005YW-D6 for sip@ietf.org; Fri, 12 Jan 2007 02:09:23 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4CDA2718; Fri, 12 Jan 2007 08:09:09 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 08:09:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] Date: Fri, 12 Jan 2007 08:09:06 +0100 Message-ID: <7374777208BDC7449D5620EF9423256701614C26@esealmw113.eemea.ericsson.se> In-Reply-To: <45A6762B.8040201@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] Thread-Index: Acc1p17O/OdS6cKxR4y7U+bNu35PewAcGTPw From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" , X-OriginalArrivalTime: 12 Jan 2007 07:09:08.0769 (UTC) FILETIME=[8DB19910:01C73618] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: sip@ietf.org, aki.niemi@nokia.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, >I'm not objecting to establishing connections early,=20 >especially if doing so is needed to establish connectivity in=20 >the reverse direction.=20 I think we all agree on that. >But when the connection is not=20 >required to establish connectivity in the reverse direction,=20 >and a connection has been dropped by the far end, then=20 >insisting on reestablishing it directly can be=20 >counterproductive to a server that has more connections than=20 >it can handle. So, if you have had your connection dropped,=20 >and you don't need it right now, I still think it would be=20 >best to wait until you do need it before attempting to reestablish it. We don't need to mandate the connection to be re-established. But, I think it would be good to document it as an option, and say what the advantages of doing so would be. Regards, Christer > Markus.Isomaki@nokia.com wrote: > > Hi, > >=20 > > I agree with Aki. We are fooling ourselves if we think that the=20 > > potential delay problems with ICE or TCP connection setups=20 > etc. can be=20 > > cured with this kind of tricks. In general delays may not=20 > be an issue,=20 > > but in wireless access they can be. > >=20 > > Markus > >=20 > >=20 > >> -----Original Message----- > >> From: ext Aki Niemi [mailto:aki.niemi@nokia.com] > >> Sent: 11 January, 2007 13:47 > >> To: ext Paul Kyzivat > >> Cc: SIP; Christer Holmberg (JO/LMF) > >> Subject: Re: TCP connection establishment [was: RE: [Sip] Question=20 > >> aboutPoll: Proposal relating to keepalive, TCP, and UDP usage=20 > >> indraft-ietf-sip-outbound] > >> > >> On Wed, 2007-01-10 at 11:02 -0500, ext Paul Kyzivat wrote: > >>> For a UAC, there is typically a lot of extra time between the=20 > >>> initiation and the completion of dialing, which can mask a lot of=20 > >>> network delay. It has been suggested that ICE begin during > >> this time.=20 > >>> Establishing a TCP connection could also happen during this time. > >> I think this is less and less the case. I expect most calls to be=20 > >> initiated via a buddylist or phonebook type application,=20 > or even via=20 > >> linked phone numbers in an email message. In those cases,=20 > there is no=20 > >> delay between initiation and completion of the "dialing"=20 > since it's a=20 > >> single action. > >> > >> Personally, I can't remember the last time I actually=20 > dialed to make=20 > >> a phone call -- even a CS one. > >> > >> Cheers, > >> Aki > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >> > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 12 08:55:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Mqm-0004C0-Ed; Fri, 12 Jan 2007 08:53:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Mqk-0004Br-74 for sip@ietf.org; Fri, 12 Jan 2007 08:53:42 -0500 Received: from wx-out-0506.google.com ([66.249.82.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Mqi-0005dm-VB for sip@ietf.org; Fri, 12 Jan 2007 08:53:42 -0500 Received: by wx-out-0506.google.com with SMTP id h31so796389wxd for ; Fri, 12 Jan 2007 05:53:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:to:subject:organization:content-type:mime-version:content-transfer-encoding:message-id:user-agent:from; b=ViQMNmHw/EwnseWERK9W7P1vYgl6K+zxv3K7Catg9nm5ABtl4VKY3Pzd1NPdOrfb8kn6lDrIdPBsd/jsO01zKnNjjoRBcPtWY5zrCe9Z243W4TNMvPdO45tYnpI8L8N1sA4RJON2RCvSxsoYktSlIZTONW178oeON4FcgizaDj4= Received: by 10.70.31.6 with SMTP id e6mr1341668wxe.1168610018820; Fri, 12 Jan 2007 05:53:38 -0800 (PST) Received: from seu-xcr ( [202.112.23.206]) by mx.google.com with ESMTP id i39sm3264031wxd.2007.01.12.05.53.34; Fri, 12 Jan 2007 05:53:38 -0800 (PST) Date: Fri, 12 Jan 2007 21:53:29 +0800 To: sip@ietf.org Organization: SEU Content-Type: text/plain; format=flowed; delsp=yes; charset=gbk MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: User-Agent: Opera Mail/9.10 (Win32) From: XuChunrong X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Sip] Question about Content-Type. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,all. I am a newbie here.. :-) So ask a stupid question first: Can we defined our own Content-Type if we need a new Message Body type, for example, can I define an "application/example" in my SIP program? Thanks... -- Best Regards Xu Chunrong Southeast University, Nanjing _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 12 10:00:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5NsH-00032v-JG; Fri, 12 Jan 2007 09:59:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5NsG-00032e-8J for sip@ietf.org; Fri, 12 Jan 2007 09:59:20 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5NsE-00079f-VC for sip@ietf.org; Fri, 12 Jan 2007 09:59:20 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 12 Jan 2007 06:59:19 -0800 X-IronPort-AV: i="4.13,178,1167638400"; d="scan'208"; a="50671339:sNHT45991480" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0CExI21008530; Fri, 12 Jan 2007 09:59:18 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0CExIVT020765; Fri, 12 Jan 2007 09:59:18 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 09:59:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question about Content-Type. Date: Fri, 12 Jan 2007 09:59:15 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E302718EDE@xmb-rtp-20b.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question about Content-Type. Thread-Index: Acc2UXDVlRHqYWKZS3qgVvTaZIqp9wACLPrQ From: "Michael Hammer \(mhammer\)" To: "XuChunrong" , X-OriginalArrivalTime: 12 Jan 2007 14:59:18.0616 (UTC) FILETIME=[3C12A580:01C7365A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=964; t=1168613958; x=1169477958; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=20=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:=20RE=3A=20[Sip]=20Question=20about=20Content-Type. |Sender:=20 |To:=20=22XuChunrong=22=20,=20; bh=3T5Z0W8xaNPnpuvsQ99Uy1H/EP1EuGu5x799N8nRwqk=; b=a1rJxnatfHHNC8OSNuDvrgnAZCzolGQ1HmAARCUQTqtf2qWm9xPUTZzHGQIG9Hk53raXTKGZ j/EJhZsaiMtySb0n2FipgQunHkD/MtSwa9ZyalxrJVzcp9hfM6sdL6ff; Authentication-Results: rtp-dkim-1; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org You can, but you will need to write an RFC to get it approved for IANA registration. Mike =20 > -----Original Message----- > From: XuChunrong [mailto:aquariusxu@gmail.com]=20 > Sent: Friday, January 12, 2007 8:53 AM > To: sip@ietf.org > Subject: [Sip] Question about Content-Type. >=20 > Hi,all. > I am a newbie here.. :-) So ask a stupid question first: > Can we defined our own Content-Type if we need a new Message=20 > Body type, for example, can I define an "application/example"=20 > in my SIP program? >=20 > Thanks... >=20 > -- > Best Regards >=20 > Xu Chunrong > Southeast University, Nanjing >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 12 10:26:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5OIY-0004Jb-JY; Fri, 12 Jan 2007 10:26:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5OIW-0004JW-Ll for sip@ietf.org; Fri, 12 Jan 2007 10:26:28 -0500 Received: from sccrmhc15.comcast.net ([63.240.77.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5OIT-0004u5-EY for sip@ietf.org; Fri, 12 Jan 2007 10:26:28 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc15) with ESMTP id <2007011215261901500s994se>; Fri, 12 Jan 2007 15:26:24 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l0CFQJbM032748 for ; Fri, 12 Jan 2007 10:26:19 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0CFQJiR032744; Fri, 12 Jan 2007 10:26:19 -0500 Date: Fri, 12 Jan 2007 10:26:19 -0500 Message-Id: <200701121526.l0CFQJiR032744@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (aquariusxu@gmail.com) Subject: Re: [Sip] Question about Content-Type. References: X-Spam-Score: 0.2 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: XuChunrong I am a newbie here.. :-) So ask a stupid question first: Can we defined our own Content-Type if we need a new Message Body type, for example, can I define an "application/example" in my SIP program? If you want to define an "official" Content-Type, you have to go through the appropriate process. (The process varies for different protocol identifiers. See http://www.iana.org/numbers.html.) If you want a private, experimental Content-Type, use a second part that starts with "x-". "x-" is a blanket convention for private token values. So you can use "application/x-example" and know that that name will never be standardized for another purpose. If you want an unofficial Content-Type but think its use might become widespread, put some sort of name after the "x-", like "application/x-aquarius-example" to reduce the risk of collision with other uses. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 12 13:06:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Qmm-0004UX-Fs; Fri, 12 Jan 2007 13:05:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Qmk-0004TJ-Gl for sip@ietf.org; Fri, 12 Jan 2007 13:05:50 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Qmj-0001XP-8H for sip@ietf.org; Fri, 12 Jan 2007 13:05:50 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 12 Jan 2007 10:05:49 -0800 X-IronPort-AV: i="4.13,179,1167638400"; d="scan'208"; a="50688566:sNHT47219312" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0CI5meq017562; Fri, 12 Jan 2007 13:05:48 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0CI5mOE006007; Fri, 12 Jan 2007 13:05:48 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 13:05:47 -0500 Received: from [161.44.183.248] ([161.44.183.248]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 13:05:47 -0500 Message-ID: <45A7CDFB.5080705@cisco.com> Date: Fri, 12 Jan 2007 13:05:47 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF9423256701614C26@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF9423256701614C26@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jan 2007 18:05:47.0510 (UTC) FILETIME=[492C6160:01C73674] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1706; t=1168625149; x=1169489149; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20TCP=20connection=20establishment=20[was=3A=20RE=3A=20 [Sip]=20Question=20aboutPoll=3A=0A=20Proposal=20relating=20to=20keepalive, =20TCP,=20and=20UDP=20usage=20indraft-ietf-sip-outbound] |Sender:=20 |To:=20=22Christer=20Holmberg=20(JO/LMF)=22=20; bh=LXpiiVTu5g25pkEail77sPfVnbTLl3o/7jwN9jFIKsY=; b=NZJSs9B6FNf5QFphJxSlVyL9rhUrRVQs0Io3Nyw38EjaG7HUXUfc0FauXKM1/2N36VOrWvyY e3r7A/a+t2ing9Sma+LSd0hO4LpSKoCdPpyJpK9FQwXGRb/H5bHVQKXE; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sip@ietf.org, aki.niemi@nokia.com, Markus.Isomaki@nokia.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > Hi, > >> I'm not objecting to establishing connections early, >> especially if doing so is needed to establish connectivity in >> the reverse direction. > > I think we all agree on that. > >> But when the connection is not >> required to establish connectivity in the reverse direction, >> and a connection has been dropped by the far end, then >> insisting on reestablishing it directly can be >> counterproductive to a server that has more connections than >> it can handle. So, if you have had your connection dropped, >> and you don't need it right now, I still think it would be >> best to wait until you do need it before attempting to reestablish it. > > We don't need to mandate the connection to be re-established. But, I > think it would be good to document it as an option, and say what the > advantages of doing so would be. What should a server do that has more connections than it can manage? Presumably it must disconnect some of them, or refuse new ones. The advantage of disconnecting old ones is that it can choose those that have not been used for a long time. When rejecting new ones, there is no good way to distinguish those that are being established because they are needed right now for a call, and those that are being established "just in case". Things will be worse for those that really need a connection if those that don't attempt to make a connection anyway after having been rejected. So, I think it would in fact be better to mandate that an attempt to reestablish a connection *not* be attempted immediately after a disconnect if it is not needed at that time. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 12 13:59:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Rc3-0006ll-HD; Fri, 12 Jan 2007 13:58:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Rc2-0006lf-Gl for sip@ietf.org; Fri, 12 Jan 2007 13:58:50 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Rc0-0004aH-4l for sip@ietf.org; Fri, 12 Jan 2007 13:58:50 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l0CIwjCw011816; Fri, 12 Jan 2007 12:58:45 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l0CIwju28204; Fri, 12 Jan 2007 12:58:45 -0600 (CST) Message-ID: <45A7DA65.5090802@alcatel-lucent.com> Date: Fri, 12 Jan 2007 12:58:45 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pkyzivat@cisco.com Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF9423256701614C26@esealmw113.eemea.ericsson.se> <45A7CDFB.5080705@cisco.com> In-Reply-To: <45A7CDFB.5080705@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: SIP LIST X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > What should a server do that has more connections than it can manage? > Presumably it must disconnect some of them, or refuse new ones. The > advantage of disconnecting old ones is that it can choose those that > have not been used for a long time. That is one strategy that can be used, yes. > When rejecting new ones, there is no good way to distinguish those > that are being established because they are needed right now for a > call, and those that are being established "just in case". Things > will be worse for those that really need a connection if those that > don't attempt to make a connection anyway after having been rejected. And here is where judicial use of policies comes into the picture. Presumably, an implementation can save a certain number of sockets for calls that are identified as emergency in nature -- those having the SOS URI, for instance. These calls will always get through, no matter what. An implementation can have a high watermark for simultaneous TCP connections. This high watermark will exclude the reserved set, which allows SOS type of calls to come in. We have had some success using this technique. > So, I think it would in fact be better to mandate that an attempt to > reestablish a connection *not* be attempted immediately after a > disconnect if it is not needed at that time. We could always normatively specify it with a SHOULD strength (and explain why). Then your concern would be allayed, and if an implementation still wanted to do pre-emptively open a connection, it would have presumably weighed in the pros and cons and decided accordingly. Thanks. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From leonkxfe@schoolmerch.com Fri Jan 12 15:37:52 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5T9s-0004Mt-2x for sip-archive@lists.ietf.org; Fri, 12 Jan 2007 15:37:52 -0500 Received: from cpe-069-132-032-063.carolina.res.rr.com ([69.132.32.63]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H5T9q-0002hR-8I for sip-archive@lists.ietf.org; Fri, 12 Jan 2007 15:37:51 -0500 From: "Garland Pham" Reply-To: "Garland Pham" Message-ID: <3593154179.6033585181@schoolmerch.com> Date: Fri, 12 Jan 2007 14:38:47 -0600 To: Subject: Microsoft Office 2007 Enterprise ready to download MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Office 2007 is available for enterprise users from November 30, 2006. The end user version is available from the beginning of 2007. The 2007 Microsoft Office System, also known as Microsoft Office 2007, is the most recent version of Microsoft's productivity suite. Formerly known as Office 12 in the initial stages of its beta cycle, it was scheduled to be made available to volume license customers on November 30, 2006, with general availability following in early 2007. Office 2007 contains a number of new features, the most notable of which is the entirely new graphical user interface called the Ribbon, replacing the menus and toolbars that have been the cornerstone of Office since its inception.Office 2007 also includes new applications and server-side tools. Chief amongst these is Groove, a collaboration and communication suite for smaller businesses which was originally developed by Groove Networks before being acquired by Microsoft in 2005. Also included is Office Sharepoint Server 2007, a major revision to the server platform for Office applications, which supports "Excel Services", a client-server architecture for supporting Excel workbooks that are shared in real time between multiple machines, and are also viewable and editable through a web page.While Office 2007 includes many new features, one has been removed entirely: Microsoft FrontPage is no longer being developed; its successor is the Microsoft Expression line of products. Microsoft Office 2007 Enterprise Retail Price $899.00 Our Price $79.95 You save $819.05 http://aspireportals.org Please note, that there will be more special offers available for our constant customers. Every effort has been made to ensure the accuracy of all information contained herein. DS Team makes no warranty expressed or implied with respect to accuracy of the information, including price, product editorials or product specifications. Product and manufacturer names are used only for the purpose of identification. We appreciate your cooperation with us and we'll be glad to see you as our clients in the future. From sip-bounces@ietf.org Fri Jan 12 16:35:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5U2W-0001Wu-Le; Fri, 12 Jan 2007 16:34:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5U2U-0001WB-Ah for sip@ietf.org; Fri, 12 Jan 2007 16:34:18 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5U2T-0007FI-0O for sip@ietf.org; Fri, 12 Jan 2007 16:34:18 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 12 Jan 2007 13:34:17 -0800 X-IronPort-AV: i="4.13,179,1167638400"; d="scan'208"; a="50707149:sNHT53771480" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0CLYG8F006614; Fri, 12 Jan 2007 16:34:16 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0CLYGVT005178; Fri, 12 Jan 2007 16:34:16 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 16:34:16 -0500 Received: from [161.44.183.248] ([161.44.183.248]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 16:34:15 -0500 Message-ID: <45A7FED7.90604@cisco.com> Date: Fri, 12 Jan 2007 16:34:15 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF9423256701614C26@esealmw113.eemea.ericsson.se> <45A7CDFB.5080705@cisco.com> <45A7DA65.5090802@alcatel-lucent.com> In-Reply-To: <45A7DA65.5090802@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jan 2007 21:34:15.0890 (UTC) FILETIME=[68BFB320:01C73691] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3668; t=1168637656; x=1169501656; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20TCP=20connection=20establishment=20[was=3A=20RE=3A=20 [Sip]=20Question=20aboutPoll=3A=0A=20Proposal=20relating=20to=20keepalive, =20TCP,=09and=20UDP=20usage=20indraft-ietf-sip-outbound] |Sender:=20 |To:=20=22Vijay=20K.=20Gurbani=22=20; bh=W1TAo3S5E1B/uWnFjLDjwb/+JYaBX+vrcsYM33M0fHA=; b=j3de2pJJGZFjERfPW2B6w9qFxD3QfqekYukX3rXHftzSIG/61EqdMctkMfxTWanHk4M8u+9w Q79BhM5+7Zwqq8acNcImOhvfKm1idPXSsseoxBJQN3s/0bHYPAGtRZ8c; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: SIP LIST X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vijay, I'm not trying to distinguish between those making emergency calls, and those making regular calls. I'm trying to distinguish between those establishing a connection because they want to make a call *now* from those that are establishing a connection in order to minimize the call setup delay *later* if/when a call attempt is made. Suppose a server can support 1000 connections, and devices connect as soon as turned on, and attempt to reconnect whenever their connection is dropped. Then when the device 1001 attempts to connect, the server will have to drop somebody - perhaps the one whose connection as been idle for the longest. But that device will immediately try to reconnect, forcing another device to be disconnected. This will continue indefinitely. Doesn't seem like a very good strategy. Now, take a different approach: devices only connect when they *need* the connection (e.g. to make a call). Once connected, they stay connected until shut down or until the server disconnects them. There will be no problem at all until there are 1000 devices that have made a call. When another device needs to make a call it will attempt to connect, forcing one of the others - that hasn't used the connection recently - to be disconnected. That will cause no other actions until that device needs to send another message. There won't be a significant problem until there are 1000 devices with active calls. Even then, given that signaling usually happens at the beginning and end of calls, with a long period in between with no signaling, a lot more than 1000 devices can probably be supported with little difficulty. Of course outbound does breakdown as soon as the number of devices exceeds the number of supported simultaneous connections. That might be a significant discriminator for deployment choices. Paul Vijay K. Gurbani wrote: > Paul Kyzivat wrote: >> What should a server do that has more connections than it can manage? >> Presumably it must disconnect some of them, or refuse new ones. The >> advantage of disconnecting old ones is that it can choose those that >> have not been used for a long time. > > That is one strategy that can be used, yes. > >> When rejecting new ones, there is no good way to distinguish those >> that are being established because they are needed right now for a >> call, and those that are being established "just in case". Things >> will be worse for those that really need a connection if those that >> don't attempt to make a connection anyway after having been rejected. > > And here is where judicial use of policies comes into the picture. > Presumably, an implementation can save a certain number of sockets > for calls that are identified as emergency in nature -- those > having the SOS URI, for instance. These calls will always get > through, no matter what. > > An implementation can have a high watermark for simultaneous > TCP connections. This high watermark will exclude the reserved > set, which allows SOS type of calls to come in. We have had some > success using this technique. > >> So, I think it would in fact be better to mandate that an attempt to >> reestablish a connection *not* be attempted immediately after a >> disconnect if it is not needed at that time. > > We could always normatively specify it with a SHOULD > strength (and explain why). Then your concern would be allayed, > and if an implementation still wanted to do pre-emptively open > a connection, it would have presumably weighed in the pros and > cons and decided accordingly. > > Thanks. > > - vijay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 12 19:09:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5WRK-0007GI-MF; Fri, 12 Jan 2007 19:08:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5WRJ-0007Bx-LR for sip@ietf.org; Fri, 12 Jan 2007 19:08:05 -0500 Received: from c243-111.rim.net ([216.9.243.111] helo=MHS01YKF.rim.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5WRH-0008Pl-Ms for sip@ietf.org; Fri, 12 Jan 2007 19:08:05 -0500 Importance: normal Priority: normal Received: from ngw02ykf.rim.net ([10.102.108.31]) by MHS01YKF.rim.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Jan 2007 19:07:55 -0500 Received: from XCH21YKF.rim.net ([10.102.100.36]) by ngw02ykf.rim.net (SAVSMTP 3.1.6.45) with SMTP id M2007011219075518061 ; Fri, 12 Jan 2007 19:07:55 -0500 Received: from XCH47YKF.rim.net ([10.64.31.217]) by XCH21YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Jan 2007 19:07:55 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Issue: Expiration of temp-gruu Date: Fri, 12 Jan 2007 19:07:53 -0500 Message-ID: <61968779B8AC4C4BAB421D4C12F008C00836D8C5@XCH47YKF.rim.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Issue: Expiration of temp-gruu Thread-Index: Acc1AM1gtP4moMDJTA2cH4HTT203KABpfSYw From: "Andrew Allen" To: "Jonathan Rosenberg" , "Scott Lawrence" X-OriginalArrivalTime: 13 Jan 2007 00:07:55.0255 (UTC) FILETIME=[DFEB2870:01C736A6] X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: SIP IETF , Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan This algorithm looks fine to me. Andrew -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 Sent: Wednesday, January 10, 2007 4:44 PM To: Scott Lawrence Cc: SIP IETF; Paul Kyzivat Subject: Re: [Sip] Issue: Expiration of temp-gruu This thread is a month old, but I want to revise GRUU and get this done. This is really the only issue that is outstanding, I think. To refresh everyones memory, the issue being dsicussed is this.=20 Temp-GRUU expire when the last contact with the instance ID expires. In=20 normal cases, the expiration is known to the UA. However, there are=20 cases where there is a forceful de-registration, for example. In these=20 cases, the UA will not know about it, and it won't know whether its=20 temp-gruu remain valid. We've seen three proposals for how to deal with this: 1. include a parameter in the Contact header field of the REGISTER=20 response, indicating the time at which the first contact with that=20 instance ID was registered. When this changes in a REGSITER response,=20 the UA knows its older temp-gruu are invalid. 2. the UA uses a reg-event subscription, and it gets a NOTIFY when the=20 contacts are de-registered. As long as the UA gets the notification=20 indicating that the de-registration has happened, this works reasonably=20 well. 3. the UA can use an OPTIONS sent to a temp-gruu to verify that it still works (2) and (3) require no new mechanism, just explanation. (1) would=20 require new mechanism. Now, I was in the process of working through some details on this, and=20 ran into problems. In particular, we ultimately need to be able to=20 specify an algorithm that clearly tells a UA which of its temp GRUU are=20 valid, and which are expired. If we are using the reg-event subscription to figure this out, the obvious algorithm would be to expire all=20 temp-gruu learned in REGISTER responses prior to this notification.=20 However, that is imprecise. What about a REGISTER that happens very=20 close in time to the NOTIFY? Indeed, this is very likely to be the case=20 when the reg-event is shortening the expiration in order to ask the user to explicitly re-REGISTER, but the time was a bit too short and the=20 re-REGISTER is close to the boundary. If a NOTIFY comes indicating that=20 the contact did expire, how do you *know* if that REGISTER came in=20 before or after? You could wait for the next NOTIFY, and try and=20 correlate it with the REGISTER you just completed. One way to do that is with CSeq. The reg-event package includes the=20 option of having CSeq numbers. If we assume these are always used (they=20 are optional), the algorithm is a bit easier. Each temp-gruu is=20 associated with the CSeq of the REGISTER in which it was learned. When a NOTIFY comes indicating that the registration has expired, you look to=20 see if its a partial or full state NOTIFY. In the case of partial, if=20 the NOTIFY explicitly removes a contact, you invalidate all temp-gruu=20 learned in register responses prior to or equal to the CSeq in the=20 contact. If the case of a full state NOTIFY, if the contact is absent,=20 the UA marks all temp-gruu as suspect. On the first NOTIFY that=20 indicates the Contact is re-registered (I assume the UA is=20 re-registering), the UA invalidates all temp-gruu learned by REGISTER=20 responses whose CSeq is less than the one in the NOTIFY. All others are=20 considered valid. This algorithm is assuming some very specific behavior from registrars=20 that are doing reg-event with GRUU. Namely, they always send CSeq, even=20 when indicating expiration of a contact. We'd need to specify this,=20 probably as a note in gruu-reg-event. Comments on this algorithm? If this is OK I will update GRUU based on=20 this and we can ship it. Finally. Really this time. -Jonathan R. Scott Lawrence wrote: > On Mon, 2006-12-04 at 17:15 -0500, Paul Kyzivat wrote: >=20 >>Scott, >> >>Its certainly true that a gruu can always be tested to see if it works.=20 >>That would however raise the question of when one ought to do the test.=20 >>In normal cases you will know the status of your gruu by regular=20 >>methods, so you would have no reason to test it. So you would have to=20 >>test whenever you thought failure might have negative consequences. Some=20 >>of the times when failure might have bad consequences are: when=20 >>responding to an incoming INVITE, and any time during a dialog. I guess=20 >>you could send an OPTIONS and await the response before responding to an=20 >>INVITE, and it might even be masked by alerting, but it seems kind of=20 >>annoying to have to do that. But no matter how often you do it during a=20 >>dialog you still might miss the moment your gruu becomes invalid and the=20 >>other end of the dialog sends you a message. (Extremely unlikely, but=20 >>possible.) >> >>I think the other existing solutions get "pretty close", and OPTIONS=20 >>doesn't significantly improve on that. >=20 >=20 > I don't like requiring the registrar to return a timestamp because it's > yet another piece of state that it has to keep for every registration. >=20 > I don't think it actually helps all that much - going back to your > original problem statements: >=20 >=20 >>3) the UA may attempt to refresh the registration, but be too slow, >> so that the reregistration arrives after the prior one expires >>4) some other UA may deregister all the registrations, including >> the one by this UA. (When the UA decides it should refresh the >> registration it will actually create a new one.) >>5) the registrar may remove the registration administratively >>6) the registrar may crash and restart, losing all its registrations >=20 >=20 > Case 3 can be avoided by just not waiting too long (overlap by a few > minutes instead of a few seconds - if that's still problematic then you > probably have other problems that are worse anyway). >=20 > Cases 4,5, and 6 are essentially all the same from the point of view of > the UA; your registration state at the server is lost because of some > event you are not aware of. This is true of any registration, and is > not specific to temp-gruu or public gruu; it can happen with a Contact > value you provide without gruu at all. A gruu is slightly worse in that > loosing the state can affect in-dialog requests for established dialogs, > but I think that's just an unavoidable chance that you take when you > choose to use a gruu of either kind. Put another way, if you use a > gruu, you accept the fact that you're relying on an additional service > for in-dialog connectivity - it's either worth the benefits or it isn't. >=20 >=20 >=20 >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 12 23:30:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5aVz-0005vK-L1; Fri, 12 Jan 2007 23:29:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5aVu-0005tc-LS; Fri, 12 Jan 2007 23:29:06 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5aVs-0002bo-Bi; Fri, 12 Jan 2007 23:29:06 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 12 Jan 2007 20:29:03 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l0D4T2Ia012932; Fri, 12 Jan 2007 20:29:02 -0800 Received: from [192.168.1.9] (sjc-vpn7-387.cisco.com [10.21.145.131]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0D4T2nF020709; Fri, 12 Jan 2007 20:29:02 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: rai@ietf.org, avt@ietf.org, ECRIT , enum@ietf.org, mmusic@ietf.org, sigtran@ietf.org, simple@ietf.org, geopriv@ietf.org, ieprep@ietf.org, SIP , sipping@ietf.org, speechsc@ietf.org, speermint@ietf.org, xcon@ietf.org, RAI Chairs , RAI Discuss From: Cullen Jennings Date: Fri, 12 Jan 2007 20:28:52 -0800 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=484; t=1168662542; x=1169526542; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20New=20RAI=20mailing=20list=20formed |Sender:=20; bh=oy9hMDTAd3CLwx2VjaSlGDIiUGc4zeKQTh4WxAq1xfU=; b=nzE6bx99AfmpN9XXdKKYeMzdSrPYLU0XznGtkrDuKY24XeITEuEnaaVR9hz7VFmVb9njtbTr 5VVkwN8evTl13ZapqifDuRHeokxVdDOoFkvhoDOAduovqFL7TFD5fRZC; Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Sip] New RAI mailing list formed X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Please don't reply to this message so you don't cross post to all the groups. A new mailing list for announcement and discussion of general topics of interest to RAI Area has been created. The list is rai@ietf.org You can subscribe at: https://www1.ietf.org/mailman/listinfo/rai Or by sending email with a body containing "subscribe" to rai- request@ietf.org Please do subscribe to it so you can find announcements for things like RAI BOFs. Thanks, Cullen & Jon _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jan 13 08:39:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5j5c-0001R3-Uc; Sat, 13 Jan 2007 08:38:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5j5b-0001PU-Rs for sip@ietf.org; Sat, 13 Jan 2007 08:38:31 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5j5X-0003r9-9t for sip@ietf.org; Sat, 13 Jan 2007 08:38:31 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7BFD9D40; Sat, 13 Jan 2007 14:38:20 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 13 Jan 2007 14:38:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] Date: Sat, 13 Jan 2007 14:38:20 +0100 Message-ID: <7374777208BDC7449D5620EF942325670166D9C4@esealmw113.eemea.ericsson.se> In-Reply-To: <45A7CDFB.5080705@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] Thread-Index: Acc2dEvMVmTVMMdrSbeTVkJeC7EjNAAEJIEA From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 13 Jan 2007 13:38:20.0251 (UTC) FILETIME=[16ACBAB0:01C73718] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: sip@ietf.org, aki.niemi@nokia.com, Markus.Isomaki@nokia.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>>I'm not objecting to establishing connections early, especially if=20 >>>doing so is needed to establish connectivity in the reverse=20 >>>direction. >>=20 >>I think we all agree on that. >>=20 >>>But when the connection is not >>>required to establish connectivity in the reverse direction, and a=20 >>>connection has been dropped by the far end, then insisting on=20 >>>reestablishing it directly can be counterproductive to a=20 >>>server that has more connections than it can handle. So, if you have had your=20 >>>connection dropped, and you don't need it right now, I still think it >>>would be best to wait until you do need it before attempting to=20 >>>reestablish it. >>=20 >>We don't need to mandate the connection to be re-established. But, I=20 >>think it would be good to document it as an option, and say=20 >>what the advantages of doing so would be. >=20 >What should a server do that has more connections than it can manage?=20 Whatever it would do in the bi-directional connection case, when the connection needs to be re-established in order for the client to receive inbound requests... >Presumably it must disconnect some of them, or refuse new=20 >ones. The advantage of disconnecting old ones is that it can=20 >choose those that have not been used for a long time. When=20 >rejecting new ones, there is no good way to distinguish those=20 >that are being established because they are needed right now=20 >for a call, and those that are being established "just in=20 >case". > >Things will be worse for those that really need a=20 >connection if those that don't attempt to make a connection=20 >anyway after having been rejected. >=20 >So, I think it would in fact be better to mandate that an=20 >attempt to reestablish a connection *not* be attempted=20 >immediately after a disconnect if it is not needed at that time. I don't agree on that. We can describe the pros and cons of each option, but we should allow both. An operator may have designed his network in a way that each proxy can support enough number of connections, and in that case terminals should not be forbidden to have re-estblish those connections. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From padillagerardmok@hinet.net Sat Jan 13 14:24:02 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5oTy-0006J4-3T; Sat, 13 Jan 2007 14:24:02 -0500 Received: from 61-229-229-83.dynamic.hinet.net ([61.229.229.83] helo=hinet.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1H5oTp-0004RN-5a; Sat, 13 Jan 2007 14:24:02 -0500 Message-ID: <8b5c01c7379b$ec5db050$bf2456fb@padillagerardmok> Reply-To: "Cammy Boyd" From: "Cammy Boyd" To: "Luann" Cc: "Delois" , "Shari" , "Lynnette Ruiz" , "Ignacio Watson" , "Breann Ramos" , "Samara" , "Jacque" , "Adena Gilbert" , "Adolfo Watkins" Subject: Sick of your fat Date: Sun, 14 Jan 2007 05:22:02 +1000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_68E_A398_953FBCFE.100CB3FE" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 X-Spam-Score: 2.5 (++) X-Scan-Signature: 75ac86d24bd0a3cd8a26e327ae61143e This is a multi-part message in MIME format. ------=_NextPart_68E_A398_953FBCFE.100CB3FE Content-Type: multipart/alternative; boundary="----=_NextPart_8F8_458E_940495E6.C7BA8C8A" ------=_NextPart_8F8_458E_940495E6.C7BA8C8A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =60Saturday? Impossible!' cuddly A few moments neck after, parcel exi= stence the funnel of the =60Henrietta' Passepartout effect attempt was c= rushed; it bucket overwhelmed delicious him to loharass edge =60Do not cu= rly let the fires go down,' scale replied Mr Fogg. =60 pop skirt authority picture =60Perhaps,' replied Mr Fogg simply. The t= rack cover outgoing up to this time spell remember had reached its highes= t Passepartout adorable grew increase more history and more debt impa= tient as they =60At least, snake there serve are run two hate champions in presence of =60Yes, yes, yes, nuptial replace forsake sea yes!' cried Passepartout. =60= You havshaggy join journey Towards press noon Phileas Fogg, having ascert= ained theiThe party crossed prepare the sanguineous Hudson fight in night= the Jersey City feIn concerned a minute few moments, with cries and esca= pe oaths, gentle a bomb app Aouda, leaning shear upon Mr roof Fogg's vessel arm, bath observed the tu= At ten air sent o'clock at vanish night the train, slap stopped at Fo= rt =60What an idea!' he side cake choke said to himself. =60Why double d= id my ma   =60It would be prudent salt deliberately warmly for us to rich retire,' s= aid Fix, relation Passepartout mug had sneeze seized his press master by the colla= r,heal =60Where stage are we?' copper damage he repeated, with purple fac= e. =60SeThe advertisement next day vivacious was the 12th of surround tin= tinnabulary December. From seven=60Pirate!' cried after ok Captain Speedy= =60I rescue have worm sent for y =60An instrument English smash faithfully subject--' shine began Mr Fogg.= While the drain worthy serpentine Frenchman was stridden absorbed clear= in the sta Several passengers rotten had object got off at cautiously s= nore Green Fiver, and astragatar money He did not side finish his moor sentence; for a terrific= hub Mr Fogg love hurt left the hotel flame sand alone, after giving P= assepa Phileas Fogg, false thus change silver wreck kidnapped, without having ti= me=60Pickaroon!'He report seemed about to give stage damage jagged up all= hope, when he espie=60 - Sir,' continued Mr Fogg, =60to ask desire size = worn last you to sell m It comparison was a band of lost shy voters coming to given the rescue of= th Aouda judge seized a hover hilarious moment when Mr gun Fogg was asle= ep to t invention =60That trousers Proctor on this train!' thrust victo= rious cried Fix. =60Well, re offend The match clock indicated a ovine quarter haunt before nine when h= eoven =60No! By country all new discussion the devils, no!'Phileas Fogg h= ailed sang a boat, selection watch spotless got into it, and soon=60But f= all I eager shall laid be defiant obliged to burn her.' hate =60Yankee!' weight back exclaimed Mr Fogg, end darting a contemptuou= =60And besides,' exist added mysteriously Passepartout, piscatorial plant= =60I'll take char avian government =60Mr Fix,' resumed fold pick Aouda,= =60Mr Fogg will allow no on =60Englishman!' returned mark button the dust other. park =60We will meet= ag Phileas Fogg sip place had accomplished friend the hammer journey round t= h=60Burn the "Henrietta"!'=60The enter hate captain?' wood baby asked Mr = Fogg.=60Yes; at shy least the upper part of driving fiction well her. The= coal has =60When you please.' =60You help are right, madam,' thread replied Fix; = transport big =60a meeting be frame =60And,' hair disgust added Passe= partout, visit =60that would play the ga   =60What theory plane thumb sign is your name?'=60Burn my powder vessel!' = bet cried radiate bite Captain Speedy, who could ------=_NextPart_8F8_458E_940495E6.C7BA8C8A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""



=60Saturday? Impossible!'     cuddly A f= ew moments neck after, parcel existence the funnel of the =60Henrietta'&n= bsp; Passepartout effect attempt was crushed; it bucket overwhelmed = delicious him to loharass edge =60Do not curly let the fires go down,' sc= ale replied Mr Fogg. =60   
pop skirt authority picture =60Perhaps,' replied Mr Fogg simply. &nb= sp;  The track cover outgoing up to this time spell remember ha= d reached its highest     Passepartout adorable = grew increase more history and more debt impatient as they  &nb= sp; =60At least, snake there serve are run two hate champions in presence of&= nbsp;

=60Yes, yes, yes, nuptial replace forsake sea yes!' cried Passepartou= t. =60You havshaggy join journey Towards press noon Phileas Fogg, having = ascertained theiThe party crossed prepare the sanguineous Hudson fight in= night the Jersey City feIn concerned a minute few moments, with cries an= d escape oaths, gentle a bomb app  Aouda, leaning shear upon Mr roof Fogg's vessel arm, bath observed the tu=     At ten air sent o'clock at vanish night the train= , slap stopped at Fort  =60What an idea!' he side cake choke sa= id to himself. =60Why double did my ma    
=60It would be prudent salt deliberately warmly for us to rich retire,' s= aid Fix, 
relation Passepartout mug had sneeze seized his press master by the colla= r,heal =60Where stage are we?' copper damage he repeated, with purple fac= e. =60SeThe advertisement next day vivacious was the 12th of surround tin= tinnabulary December. From seven=60Pirate!' cried after ok Captain Speedy= =60I rescue have worm sent for y       =60An instrument English smash faithfully subject--' shine began Mr Fogg.=   While the drain worthy serpentine Frenchman was stridden abso= rbed clear in the sta  Several passengers rotten had object got= off at cautiously snore Green Fiver, and     &n= bsp;    
astragatar money He did not side finish his moor sentence; for a terrific= hub    Mr Fogg love hurt left the hotel flame sand a= lone, after giving Passepa    
Phileas Fogg, false thus change silver wreck kidnapped, without havin= g time=60Pickaroon!'He report seemed about to give stage damage jagged up= all hope, when he espie=60 - Sir,' continued Mr Fogg, =60to ask desire s= ize worn last you to sell m    
It comparison was a band of lost shy voters coming to given the rescue of= th Aouda judge seized a hover hilarious moment when Mr gun Fogg was= asleep to t   invention =60That trousers Proctor on this = train!' thrust victorious cried Fix. =60Well, re    <= BR> offend The match clock indicated a ovine quarter haunt before nine when h= eoven =60No! By country all new discussion the devils, no!'Phileas Fogg h= ailed sang a boat, selection watch spotless got into it, and soon=60But f= all I eager shall laid be defiant obliged to burn her.'   =        
hate =60Yankee!' weight back exclaimed Mr Fogg, end darting a contemptuou= =60And besides,' exist added mysteriously Passepartout, piscatorial plant= =60I'll take char  avian government =60Mr Fix,' resumed fold p= ick Aouda, =60Mr Fogg will allow no on 
=60Englishman!' returned mark button the dust other. park =60We will meet= ag   
Phileas Fogg sip place had accomplished friend the hammer journey round t= h=60Burn the "Henrietta"!'=60The enter hate captain?' wood baby asked Mr = Fogg.=60Yes; at shy least the upper part of driving fiction well her. The= coal has   =60When you please.'  =60You help are right, madam,' thread rep= lied Fix; transport big =60a meeting be     fram= e =60And,' hair disgust added Passepartout, visit =60that would play the = ga          
=60What theory plane thumb sign is your name?'=60Burn my powder vessel!' = bet cried radiate bite Captain Speedy, who could          
------=_NextPart_8F8_458E_940495E6.C7BA8C8A-- ------=_NextPart_68E_A398_953FBCFE.100CB3FE Content-Type: image/gif; name="epizonimi.gif" Content-Transfer-Encoding: base64 Content-ID: <5ed3b01c7379b7ec1f47c026a40799@padillagerardmok> R0lGODdhiwGUAaUAAP///wAAAGZmZrK1t4CAgCcnJ+bd1D09PfC1tf8zM/9YWP8HB/9/f+iLi+bm 5unPtABj/9TQyMincZSt3tacWlJSUrWMTkuPwipztZycnHt7e6FwPaampZxqMdxnHb1GD606EHlW PpRjLgAAgP//AIAAAOV7e9tKSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAiwGUAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4SFhoeIiYp0 AQJnAwRGBQGUlQNGAgFXBJOUjmcEBmmdlY1RoUUHpZSXSQSaBqaLs0qyRZpeBZ9EurywXJOoA5Oi ZK/FZ71VmZIFvq1Hx7TTtbtkyrzWw5FbnNBCtmLSaNhTzKnO2a6/1O1E4ULDlZHM20KvAJyexZn7 pKnaChB4paoRLHmshBQsB86auob3Sl3q1whhQlKmXu3TZ4ujwyoMI84TmdGSryLeAFicCKtRSoge RVE8B4CSOzvwYqVTBUlT/qZPLk0NO5AvAMtLIcsRI6jyHKuhAArsNErE3hFsvc4NsJkplLyIkaSG ejUWFlmVBYiehYol5NqlQks2K2JPFlxRpmR5e6s2LgC8uG6WWYhMksOXUR1p0vjXKLZhPQsnblbq wNGIRb9BHhJu665V2OABOOBs3C1HxGC23AX5MVUlhJEUrEQUpVHEmNHRDZpNmilV4Jy5jgxOk03B ZTDWPgKP5mjhNTNFXvV0XqukH4sOYfbqG8dSVQNw84X1EySKRZENENCPqK2sLVehpf5NUmXZywF2 QurpE74ik+xm0Ty+lYVUKNTd9otNxyEnxoCvGdEcO8ANFIABuvSS0z39/iD4UUjpRWRAd+H9lYRo UqXFmSOvsKdPiFGJJwBU5YWY04ZIQFifECFtpctABbTS02/pnBSeAcDZhhcqvE1mm4kMsuPgFzoi wRCJEG11TzA6LSFVVPlBZASW3EVY1HjRXAhgADXaYhM+BmwFTQDufcaimmxKWCQTA6rE3IdFYjlE d84pFJhqJg6Kp6Ky5Kkkj8LtOeUX1J3oUJejvRaXmj/xqAlPaBEVkmgASCcEM7HgaRxVnQIokCga WYiUQFGl00+puGwViU51rpgZro4guZgsoJ4o31UfZSITK1gGaJpCe05yCVvHwCnLVo3ASqwzzkkl 5aRerJQERsctNN5r/gGSFKSn0cGa7hAgkpmrRH/NJoBkp5ZCQCuVdIrQAdLR5BFwNfJalEkjkrLj biYxF2ZxbArwqkbZzoemt7RBgy0lkRTI2Z4bs3poJeCSMcDCJbdzMrgkp+zyyzBnESC+Mdds880Q J4rzzjz37PPPQAct9NBEF2300UgnrfTSTDft9NNQRy311FRXbfXVWGet9dZcd+3112CHLfbYZJdt 9tlop6322my37fbbcCOBQAJ0150AAlDMTbcRCtCNtxV1K7CEAgsswAAZCCwgeNxSG7BAAkM0cHje hUtW+N9WOA65EoUDIHkYDgjRwOOMN076EJs/4fjpQhC+AM1RaK6E/uxi9D0E7KUrTfvif/WtQOgO NKAAAwyk/hcDlQ/R9+uR092AEAgUPzfeDdBdGO3HO0B36MgbjrfeixvAgAIIKLD4733jnb7odE8O ueGhI/C3Ab6HDr38CfCeu8+rE78A9At4XgIW4ADtFc52t2NA4jb3uwEWo3MLBEDiFJcAA+ytc7c7 3QApSDrXMcABhAtd51aXv/Ed0HX5gyDkBvg8wlVwgodLnAAJSELXPW9//Kuc44SAwcQJDnnGE4L4 AJC8FTIvcZPDYPI01z37/eV0q3si5Gh3OsLhbYCTI+L/tMjD/xkgdFgEAPImN0YuSlBxYkRjGXHY M9rdEIOyWyMR/oa4QAWIwoFpdB/zMIg8O35xjlAknewGeboy4rGLiDQjEA2XRyGUEY6kK6Mc2Ygz 7CUyjowswhC1uDk89lEIAxThFj9pBNoRcoqC5GMAAXBIMyrxfwNs5BofuUVMHm6SlLSZJQFgxTPi DZfHAyDqmOfKLWLQAYULnf5MmUpUbg6DhAMlMYuJyM4R7odobGQvE/dLRgIzly+boOIKU7hPrm6V Q5jg4hhYuLudkW4EZGU7W1e4BWBOi+Pc4NwOWE/BIVNx9vRcPUVhw9EZrnvLe9zlSNi9PRoOjeeM KDiH5gDcUeGPSaioFgxgUSYUw4kaPUJIJ0rSkpr0pChNqUpX/srSlrq0DXrLX/ny1wD7PaBvdWsA R+dGvpf6dAr17GQ77ffPwt3wprQont2c1wb6vU9/RJjbDdOAwTRMr2tBpadR0xnUAk51FnJ03Rec iAQLMpJ1Ub2cGv6pBoN2lBZbVENW01hOImzQcDWlxiQHeE8nZPEICFRCGXHXyiVMEwtkRUNh72AA yTGgAQ9wrE4foEDJRpZ4k60sZimLWQdE7wFFQEADRlsYz4o2r0Mw7WjJOlfXBTSD9QTtEk4rW85q dn6j/d5X0zDJCPYuf4kVnfgSkEWc/m2DHyyCcRspP+X5TZ4cJV5fuao4xypQfIdTnPZ4B0LiljKL Oi3eX7F7/ksG3DEBN4ye4NQrQeklwIl87Vv83Ps9ui2OeArErwGiJwq9TdV3AAje8IrnhAlCzqCb i+E8EexIugrOdf78qlkbAEMALoCyaj3jhbuHuaw+oJ9GaChUi/CAUC4QjCe83OgU+DjkTdcMk5Sd DOVJVgQ3kYiQI1wLH2e5HGPTvJnsoODwmMkjrA4BFVUiCPmJRmQ2tsjyPHA7bzzM9QrufxEEYhoh h9C4RnmDGu4b/eLZue4JFMuQS1yAjfnBxxmQgk/YIEcHul9pvi6idSbhmQ9M1oaK087Dm6c8Fde9 1AV1nwqQrRHu+uI1n26eyN2gQVkcwN2iIcak62E2h3nF/tcR7oH/w+Xo8ObZRjJy1AHuNDcNG1e+ 0g+RbMWiCwEp1E5fr3NpNqYXm/lEL0sTb8lLHo7pCWxd87Kb/kxjoEON1ibYsHxG/a9RoV3pYV54 nxferQOka9Atcvamgv42CoeQVXFOd9tdPQKD8Vnicrb7n5RuNIyhjGpIBhGPDjxkmYtsxMI88nCF ZTSrqfveRHZOh5KhHb4Pq0XbIU+ac3amFBfNPCLXspCM1PHyHt7FgLKQo46EchM+/DjItnOqJEdv yqeKYNEesK/tvls92XdQQVev5qzz8FyJsOMDHqHQHcf2X8fo2zZM8pVCbPbCzfq3ff9Vnvf8N9Tt CtC4/hbQCFXFJ7mNnXVa47jiDJ9gN6WZZInvErryvKQq33hwtJqZr0T45hLkPOjC0J3uQvgnKk+3 wDF7r55JvhzQzxm9eYpirvW0J+byes7XMt3AHX/zX0U74ODytsghJLYvi7B0H/IQm1A1swRNfcse QneAz2R41l289TUDHKIS1iDY8VVVY0fRzGcn8uJqv8Vo/nrqYowfAQ3aukZGYXQJbjbyQx5EwulR j4bzoDg9W09qV5DwKAT5XO+qgBtSeAgNLTjQZ726GRZ5xfg1bxtcC8+nl3PTW6/gPK8ZSB4TIfGB f6hDk9nydppVMhvEO17GT4tTVPcWbf4naEQwPOkE/k/2E1SP41pQxX12tjn/1EvCdEbgZzj503E0 VE+WtgSOc0MjqEnoVII8R0yjUwx9F3Mup103Z0ce5DkDJIN1JU4B9ADt9jgPUHgIIArik3h3w3Ts Izw9tYOJJjqJF1t6MFKqUwROmFqWB4VTyFVGRgQgdH8ElFgYBTiaxIWq81YgB4WpNUcJ91Yu01xk 8GaJN2JK81pIoFO+1nVaMFpu+FNaEDzys4fm8zSlpgSrZm1BlAV0iIdbEFlFAFmGuIhcsId7iIaM GImSOImUWImWeImYmImauImc2ImemAcQwDWh+ImkmFIQcIqomIqquIqs2Iqu+IqwGIuyOIu0WIu2 /niLuJiLuriLuAgAvPiLwBiMqFgFo2iJxfhTxzgFyTiJy+hSzQgFz8iI0bhS09gE1YiH14hS2agE 2/hS3VhS33gE4chS4whO5UgE3+gAEbCOEVCFOFSNBcRRHHV1lHSOQ7CN6tiOBZSP7lg60egAOuiI 8qODD0CP/ngF18iP+7iQ69iPcPOMALmHEjCRFLmHOgiJZWOPQlCNETAB7PiRIOmR5ihSPYgAEkAB FECRKikBFlmQD4mQGTUBMjmTNFmTM4mRadOMJXmSLLmSE5mSKokAOsgEDiAAFaALtbGORnYAteEA KCM0GumLSOAANlmVVYmTQnMoYLCMnjWRFtCT/j7Jkyi5kkgGGxGQL6FTASijJfmQHUMTlc84ARcw lxeAAXOJAXh5l3W5l3I5AQ45AExpGQBQAUx5CRmAE1pZE1rZIFbQMjkjIYuZmEawjBHwk0AZll8J lJc5kYpmBBmwHA5gJkfAlkwDl0ZGl3hpl6mJAXKZl6pJl2fJBIJyAGcZAQ8TB4sJDpyhm41ZE775 m8DJm4GBC5KJjkZQmRLwlSs5lhaQks7pnD8pAVN4ABpABF6hAa1AAAeglvGgCRGgAYepEtT5lINQ nDBpBc3oAHupmqm5l3W5mhiQAXYZm0sQmhUwBPepByPzDsFpnk1gHLsZoLypm/uZBJR5khbQ/pwo SQHNmZxfmaAM+pwMOgBTGADVWQQRUADVaZS40p1/QZhNUSq3KQYt459S4JiKKZmMqZjieJ5GMADv GaN66ZrrGZ/0uQSZEDoREAkOoAEXGgECADD2o50CoAEVEAED8JntGKQCcKNbUKAEyp+rUhy3oKLF CaW+iaWTeZwIugEbYAFeuqBg2pwJqqAMagEZ4KTvcKGpUJ3gCQAZMC9CoAFEQacDYABsWgbDSZxZ AKB8OqDCGaCJaZoiBaPweajweQEZQKFOEAHiUSqi0KMtEQGxEAlGWiqvcgBxqp0E4ADbSSn8uZv7 eRykKqiJuaLB2Z+qaqBG4AAcQKZlipJl/mqmsgqmBLCoVfipQwAJo1GdRVkBWoELdAoAtukJZ4Cl JvqfwImsUhqq9+iirRoB8omoh3qr7QgFpDGYuwoLFVBA1DkajsCW3jmYZxmkoCqgWdqsA/qngBql 6AqoAPquRdCMERCrtTqrZfqlG5ABHDAA15oEcYoM99KrozEtcgoAw2oZTpmsYFCgU8qi7xCvEYsE zKqlhJoEBsABAkCteCkA+4KVZzIebDkAwKqhxNoImqoQQwCkhDmiV1Cx6rqs8CohgUqzouqsLdqq A/Cl+Jqv+sqv/mqQShCkiyoAhzkUnkGyAZABBpAJGmCbBfCZQbIea5CbEFuqwmmlNouu/hKbqhcr UnHCARmwsfBZpPz6r1AQmmrioYCpEBuKnU7UlAEQOsPqBVY7nDUrs1mrrl17C+varltaqATQAR3g pRtAuIV7q/7ahY3qo8WApBSKp0ebAU65uCcjj2+qBqf6t3mbqu4KuKOKs1KJnlNpAB85AGLLHuyh AQTQr/5KqQ5ZBOaad07bHRpQAGpJEQWwjibrqLdKGuRJBacamQKKt5zRt+BRKctKvEsAkQ+QpAMR vbe6qAPwAIyLHCrKuTibvb/JvZ/rtdCKhabLjqg7tqrLuq67jtfLBLMbYLVrFLebu5Wwuxlanb4r tcE7BcNbpcXLtchLMsq7p/zbvFP5/rwZIL0DkQHUa72xuwjca7zdK7o1673p+q5fO0eUurjreDIc 0MEn85HyGAVKmXcfDKca8EUnPLYnQ51xEpsDgJ35kL9wAMES7AXPSJDPezI6jMM4vL7T4LD9y7kr Gq99G6rGO6jhK4XyaLpfpL7xGI9fJLRd0K3uq6aCgKI13AXNaAA83MVeTJA+nAiVwpgQPDJFnLzH IsATG7jEmFEL+cZw/MZh0LQAY8VKs8VcbL3yeJF6zMV+vMQu6TM0nMVJHAVRKYW5lJ4VFcdQvMiO vJBAg8WETLqUbIwixciYDMdtc8HMuIicLImHnDufjDah3LylzDijLI2ejJDC2Mqu/vzKsBzLsjzL tFzLtpyLlVyJpxw3qbzKhtjLv+zLbXyJu/ySuUyJxfw2wOwEDbzJRFlR89jMarPMzCzNRMOwhZx3 D3CSC7qgLMnAopzNIhVgwJNYUpwELXufgPmpI7wFEdCyl0qngcmUdkylA3y8fUrGqAoeEGOiEMnN 3RzQYymU0kyypFGkQhCeRkCn4cmoGRWkAEMU6zzPCl0H2GzI4gzHUSzH+0jOTeAAKhIP+cmdwBCp KnIAkWChjlrRzOG3envRFFvBNBy68mqcrQrQAp3TYxnISkCyQuCojmCbSfCtUWFRRisEFaAJl8qU nuqW/0mqML0EKCrJ/JyiSHzM/liIyfq40fFYz0WgAQEQm4sKBlthP21LnG8r1du7qsKrtzN7szX9 rEbwADpd1x7QzRLQmZIADXULG3laC60QmqNxlkwpnm1tz1Ed00TMtTELvlidd1ytjtC8xG/sr04Q C59gHjCcD9sZ2ExapJ0KrMTKpGTlqFEbOpdwoRZKrMELszcL1fzLvFvbz2+NBFxZ17gt0GX5oofS oz16oUVZx26bDyfsvhVAuRFb3KmtELXx107ArC/r1mxdwe2ayg2p0U+8kKjbzEntvj9tshx6Dijt qZaxHscQ1pUqu/1SGKutrIw9qsTJrvENmbO9qlVt23PdzR7wAXe9oP1NAf/9/t8LytNDANatauCj 0am6+q1yMhrqaCZxSgmCOQSFrQVADNsTu78tHbFYW93izNr6mMkR0MFezdsKDA3f+qZxCg6pnZ8a AM3d6qnOPSJJPbec4dwx/d4xe8QS3LWb+67+nN937QFEXuQA3t9FbuT+vQEOTQQIvhtIXa61QdRU odKogIVjmxDMbeEujeFHrLUuzdhWzcZUwJGLC8XRjKS4eqIAQwTf+qvnwAl06sK7WrJ5eqvbOic4 vuEzS9Mv3eOdK+aAS+ZCdOREjpJF/gH8fehGnuggwOTBtRU3qs64wLIVTuWpTQntDKS3096j4bJQ 8ONlXNuN/ePtetXDrATq/njm+6jmlm0O4fCtgsmW5V0V8TDleXq7TrS2NbHn9S3feTvqEOuuRVzb DNuMEpDkyh7gjL7fHxACIvCxVmIN4aoJoUm3uM7ibfvObCrpFK7QFd6bNivsWjrBfD7dcp3q9Qm5 OryoaCsFsaAxaZG0SU25s3EADkAAM5IZ8cvXdLKox513YJ2yTKDh+Ky9ZpyqaMzP8d0g2EyvG7Do y57kiv4BIADtivvuGKoLSSoABeS09wu8SNsicTojTbqt4vHCu8AJJlsFQIzwpuq3fHqlzlqc1Jx3 KiG2/arxUlDRkFtRb5qkpUK9RnEy9pMBJ9yj6qGOPkqflXunVVvTiS0F/s8YARsAAiBQ8VqP9ViP 8e4exlieuZV7li98Cfvy8zpcQEh/PZRKAJsdDyUsvPJBxkFMpcMbJQxP24O+kR8uhYw8j3p6CQZA xYcgyXvPBdEorSIQAlzf9V6/82CPM4Mc133PBPDYj5D8IITp8VHzj2p+wNMLtGd+NIZ/+I8NjVxg zWcDkZP9AB/Zx5FtzOqOzJfc0eScyZq8NjfvjZfs0Vl9+5Asx9Nc+cjIRue4+6gfznCQzDwDl7f8 /NAf/dI//dRf/c9P/D7F/M58+qoczNwvzMX//a2a+SYVjvR4zsqM/Xmskjqo+rr/BEILze4PNsvM xWFJkSXOy8zs942M/sp9v81AIBEOicKBA5BULplN5xMalU6pVesVC4VMHchkF9w1RLxXDeHqGGTZ bffbum1v5U9DEU88wvl9/x/wqe6pDCyCLGzMAKvgYEpDiUAgkJIvoHKQLXPJIW/oAW+tcpS0lHKT ycuQAzExYrFqwDEiysDRFCtAt1L3MmnXqdf3d3gJ9eoY4MFio6NjgwhBYoOaiHbK9uAAUkMbkin7 SxSXXKqYNBlAtSuC1cEgjH2PSsAgYBIgQmNAdjLioMA+fRkAENAAyeARAQcE0BqgwUA3NH6GnbME 4FLFYEt8dWySjsqxTswIcOCQYQhJkwOGjJMS4Z4SARObDPAlqRwT/mAcLVLcifGnkqBBBUVZ106M AXhiHCClYmBSBV8GpGbIECAD1ANHqDoigBWAhgoODhAgWyFfowECAsCCU6znm4w6NwrFyJEJyCnH llmwwAFeBAl+OxAYAA+UEAtlpBwYJoDxEps5oZzzGGju5bt4N2+Oa8yoOnatwKgLzCHyEw0CugUQ 1S3JtrC3ZseeBBFABVraYn9zTalnxo6W5+q0XPdXZ+UA9Erh69cvLMEiNuy5M2TDtSlXReEreKCC qMkDATxcA1Efv7IOBOj+A5fz+87w7dqlryV0GEKnUzsRwM8mtGoDQDbYkjDwKqiSiKA93gj0zaW3 lhNquOQsJAqo/viMA+a+JJqL4pjBoJNAnA4yuEZEwrSbIgC0BiAIgPZi9GWyrtKCxDWqXNMggH0Y kq8+C5sQjhjjlsNQOfg6dCIdJOJ58h3+phiAJraQMLBAR9AyEAC11AngyltkwyhCCZ/Q6EIN7Qvy TCGX+xA/J1L06xoDBiBDGehUtIItqLzQgKCrkphsQNl+M/BQ2i5iMy4ONavQSLo0LM5NJvODEgyl yHAqClkOIIjBFmXBagC1vnronwJgNBAmAjIAiB9TW3TLzDaF1GxCzyqVNMm84AhRT7/WAcCAYC3o YMWXevSOvQrYGtQXLHE875ZEgXSz0SBxtYjSCZVU86NL3zmE/lxylWoKtZf4WcTOddeNgB8kCECj XViaUsK8gu6MF0CKzNG2vqF0zbVSXD389Ym+9IxwTguoS7YxsGJbg1BCsZzEWjIH7KPDbG/Fdsg0 Q16TTUuhcPIdAFU+7B10+6OsFGEwRDPJbonZ6bhcMYSzKCciMNYCCR4YWsQNoAshqyuuKuOeAaqC qsdUCbLJsfAcy+ArqyVeNODKAL7w27s+e3TXcE8WDV6l1D4X7XRhftsNmnkFhGeTm+jEmWeoocYv akT42+EQ5qlCjSUimjoDNe6sd8FDDnMXclrlGvKz+Ri1WRigMp+PuJAuTTtKtZ00wKSX4T7dHCQJ RviNZH4W/uEZ6vLuAPa/NxAhBAIgRp13KuQueZQmx4AXtXiWGsCk3Xtfnvm6zXZCDWf+pp32v2F3 JoTqTGeeewo9NqVJcu8s11x4x+8e/eWd9xWKCG6v3XrqaQ8BaeXTv593kJoyn/z+D8EfgJRZH2ig 8IAMbCAE8bMe7iqQu8QFEIL548Jo+hcP+0UQg6xzQzIMMLQXIZB+IUygq/jxgAyesBw8w1QX1HFB FL6wCgNUgkiG9oAIPAB5VtHhSmyoCBj+MBAyvJvkgFhE5/wKAklU4hKZ2EQnPhGKUZTiFKlYRSte EYtZ1OIWudhFL1KROV8U4xib2DpCPOkLkYmHEdm4wTa+/pEcQmTOyUqjhDreDY559Jwe+Ug3DfYR kJgI5CDdaEZCHrIPckRkHuWoyEUS0pGPZGMjJVlJZFgSkzP8YyY5ScBOSpKSnxTlHEeJvsoVEpVG MUQrStnGSLLBAQWoQgUOkKz/UeYnqstCL3gSnM49bw5SoKD/ttdKCOpvhSu0Aneo4IDfLCE8b0PT KauQmY9xZprA1IRR/EdMY8IwGckUJwunIBUBsahMcAvOReTWsV55MpiE6Kb/BvcUbWylG2P6Ji5E Mk5xEpEJEZAEmNQBqAg4azaiCAABKuCefJWHIYswCHu2gpm6EClDPPHW93q1pFDebZ7drOcUYCKg in6T/pqJPGOmWgaPczHlpezYHmRaVdCFBmgtskwCWgQgywgEpDyTyIAscQoQi47MUdecGbfm1q1z fJQTAJoAP6Y6gAlMIAJXzSpW74QFHvEDRgDUJXByudRIHRF6mdrUGPZniJa14hUn2waPbkGoMXVk Dc5cg2wKYBib0OI3hDIF2URWNqeOLDke3WQSDHDVCVzgqhlw7FSvatWqpjNi3snHQiBTEA1QVBQM OkAXDpKBh4QVECn1V3F+R1hq9nNcw3uFuWT6iqXsDwpW4QdbHOIL2RDqmb8xFGsOgoTAqtYK67Rc YXXGXEa9U5OGDOhkqetYqlrWARMoZhNKqgR7vGKh/uURlVG/awCzsMW0FQAo13BBKXeSrGzwtCNL W5aU27r0tmpYL4G8GxO7QgK4BLEHEvg6kbge96gDW+5yBeaRsSlVm1lAxVar61jJVni7AXWMKKjS hbtS7BIddsA32KLZBCc3o0PBHEfDFt/opiK//rTgYaBXYokWYKElLtVWSuzMAqxlamq5imnRkLVQ mbhWGb1mzTa6C5k96pfsS6USKGzhC0D2ytXNAAeyMAnHeMFpPYWQeAflrG84c7SjQC6FisRgblGz xas7mM9II2N5jFQc/BgUP/hnvnZt6qHmQ8Jp93wEPnPvd8BTqXQ5cRLqQjYDWZ4s1lzYBA3Qoruy /ujNL0AM0QPtOSa82OXXliQ2cMX5lMf4c0jpeZJKc5KXtgriYhekQ1vbegI6vIBhMvwFG//0HqfS QAHCY+QSCzs8PYXaOVM7aggD7zLKTSy4pMzdHN4a27fmwJ16vU900LrWV862Va6sAbcRrl9/BkAG IDLidhm6q+yOiPnK01XgOHvBkJq2qW2VTbSecW0BF/hLva0+cNd6NVdW+JUFMBM893HNS4bLip0s s1tFGUQFByRU7/Yig6xmNawh4X41vmRqn6LkfOQ4J8R3batsu1zdNmasEVuKV6bc4IxmOVwruEqZ 4zwnNwc66laeRjvfcejcE3rS31Z00RydnExv/p7Ujeh0qlf96kC0etZ/uHSug+/gX39hEsV+wq2X PYNeRzvKW0dGt48xjG+X+9zpXne73x3vZFz7J9W+d7//HfCBF/zgCV94wx8e8YlX/OIZ33jHPx7y kZf85ClfectfHvOZ1/zmOd95z38e9KEX/ehJX3rTnx71qVf96lnfete/Hvaxl33hWV17298e97nX /e5533vf/x74wRf+8Im/+/sdYgTJV/7ymd985z8f+tGX/vSpX33rXx/72df+9rnffe9/H/zVP34E mD8v85+fAOFX//rZ3373vx/+8Ze/9sdf/idQaf751//++d9////f+epv+WiCCdYg/QAQARNQ/gEX kAH9TwCVjyaSz3sCYPuSoAHnTwkuUP0sUAM70PvwB/mgDwBGQDIokARH8AQlEAWbjwP5rwVVMAXd DwVfUAVpUPls8ANX8AaXQPx00AN/EPseMPk6gASWrwBNkAOT0Ad30AFbMAPjbwaXMAYDUAq7zwZx MPqwEAi3UATTJwSHsAidEF+QMAph8ASVsAZHkAfP0AKfkA2pjwfjMArbUA3TcAeVEA3XkAnZcA77 EAbVUA/XUA+nMAbpEA3fMAX9MBG5cAEfkAipEFqYkA7NcBJfsAwPcRIJ8fkAsRIB0QgzMA91MA/N kPkw0RMpkRNPMRMz8RNB8RJnMBFfcRVT/pERFVAAO2AA7rAmTJAPn7AJYtEI/7AMY3EQixEVgXEP C5EWlZEESfETj1EM5XAPDdEVWdAHBREWZ3EKf1ELa3H/brEDlI8fdNEm7PAMnREZJVAYobEKN9Ea 03Ebh1EaF1ETjzEdaVAM1/EZS/EafTEbVfEUNbEbvTH/bnEEeFEXxWsf8/EZLVEfQ/H6lrAT95EZ JfES0dEeWREfVxAiKTIZmTEJkVEj+5EgE1AID7IXCDASp1EU51EOTREV3VAE3xEPAxIRA9EX77AV AbIG0zAgTdEfW7IaiVEe/XEnbbIk++8kVfIIk9IpPXAgn5IRl7JTEFIqrxIAoxIrf3Ap/lfGK61y K8NSLMey/U7yyc6SLPeP/NKSLbnSC9eyLeNSLucyB9Gn+O4SL/NSL/eSL/vSL/8y98YP/QaTMAvT MA8TMRNTMReTMRvTMR8TMiNTMieTMivTMitTMCnj1WRvMzOpM+HmENAAMEeTNEvTNE8TNVOTfDJT NVvTNV8TNmNTNVlTNmvTNm8TN3NznmhTN3vTN38TOPuSN4OTOIvTOI9zN99SNHEvAPSyOZETOmGC L58zOklzOMtFZqSTOnsvO8mlOb+T96gTPPGyO7lTOu+yPENqO3VvO9fzENyzOoVTOfPBf+ATPnPv PsUzPL1zL+/TPPPSP/snQFmtPesz/j6tcz67aT3Hsxd2b0Eb9Dt1gT358zkb9DwrdELJx0IxFCYk VDu100MttEMHVEGx00NH9D3f80Rtr0BRFERX9EDx8jq9Uxg+VD/xE0Ip9Dwd9EJ3lEFTFEdFNEUx VD9D1Ed11Pdu9EOHdEeDNEeZVElj9C5nFEh1ND1ZFDut1DyJtEbBczyZU0BFlEOXlEyzE0bxkz+Z FEpJVECz1EyPVEplNEEN1E2bNEOr1Eu3VE21lE2z1E/htEiR1E5VdD/x9EjFs0+rlEz3NFHjFPeo 1E7zVFGxNE1tNEkFdUwbdVJvVEm/1FMrdVAp9VAFNVTnqUADNUodVfggdUEv9Exr/s9Mn/RVYTVN xRRUb889a7RJN7RWKzREZ5VWaRRRuVRTW5RXdVVViQ9Sk5VZe1NTm7X2WPVKkxRZhe/JAPNaWzNb nXNbNRRai29Zv1VcxzVOw5VczxVdjdNc05Vd2xU319Vd41VeZ3NO59Ve77U14TU4dQdfe5NfxZU+ o3U+L5NgC9ZgDxZhE1ZhF5ZhEzYzZw9iNVOgArZfK9Zi+VJfL1ZjN/b2MpZjZXM5P/Y2PZZddadb TfUsgXX4QhZlhVRk5dMuJ/ZjdWEwVRYmzuRZO1RF75Nlw7Q8xMtmX3ZV6/ViF8owAzRbRuAC8JMf vvMruqlnsRPEdIEfnjY2p5VZ/s01Z02VL//VWhPTP89hIqqVQG3CNWiWZylWaoF2Zay2+HLWMsY1 XG2WbEt0L+eF+Iz2MMOWCeaFI3AVuGzCbcknalXUJrySSh50ayeVRVM2PbEWTBc3+JY1Iwj0VulU L4vsa80vCfy2IMwvPyPh/ISCRQWLTGa1cF3jcJs2JRP3cgsVP33ndS8VNVn1Zh63V71UQseU9w4z H7yWO9FvCdAvdAuicwmQRG3mdKFWbd9zZW4qcQ0jVcXUSH01QoPWO2vuFy6XV4G0el90Z4VVL6m0 A0qgMkz0TL90UcPUZcvFeOkMeAn3/BR0MI/3/Ip3IlRyQM/2TP6qf1KXagUX/l++YnCfNFJ1dldn V0DxwqmEFUY/lUsZ1VIxlmjJpXzPt1KtV32Dtn0Jt3nJpXBB2HPrU3hFF3QVtHP7dnsJNArStj7F i0rEA4bzU1e7FFRT1VQ3RCe491i9d1R3dnclV2BjNoSHo1sDdU/XF3P95zBDE9NCysBImHM/134H FztV+H2TdwJJl4k/+LgCq94WKj+9VYIzGFe9R3O4+IB9mEMh+HWxl/coFyMsV4KNFfieQHM/uH/0 uFUUs3iPN4XnmIU5TbBcuD5BzDB+9ivCFlPh1FBZVIf/dlPNmI0bWVGFODmJmI8RuGWH1Xodmfjw dpOZE2xzuIppQosJuSKY/ldB9Uxwq7ZyHTh8gXhXd1eBNZSBk4SHT7Q9M5VQXbSDh09r97Vxgk9v j9aUAVmS1VMomlaNPdhUm9ZsccY1mWqHHZVke3OU2XNvmXl4r9mbyaSQWRllY1h6V1k1UwqTbTOb 0ZVmiXd/zQFWHRd1t7k7O0Jb6blu47Od0/VkFVSf17mLudN8hTYv+9mgTTOEE7p2K5ihH1pkERqi hTZ+V9U3M7NhM1qjN5qjO9qjP1oyHzZiR9oUQnObuxakU1qlV5qlGfOkD9qhSXORA5qma9qmbxqn c1qnd5qne9qnfzpln9g0JTr4voKkmQdXhbo0iRr4jNqE6/eoS6HSnval/kFYmGN6NJ06kAuQKaP6 D5SaiZuzqkNznZn697T6fQswrb0aEMD6f8Va99AAkzO2VZu6GCLwBDeHrb96lKka9zjXf31vRl+1 rm8ZaouhFM/QdOUMxVxs9dyacOG69jy33gKbloe4e0w6TJe4VHNPq0fgEckxZ77GdxQtJ/Q60agO ssvFr1ltIrzSbTX1OjN1Q3P0k2dZSJ0atMOQI6FlbhaMRUy7HPyNsYHuibe1tecJDarWr1yXcV10 jyu4jRvZSJMYPp06tPmRzHrJiNMYtUktTaJtYIijInCGQwDGlxzsdmHmARCA5E5HqKs1uaGWdam2 gNv0uWfbh+vYgSOU/kbfGgBw8QZ7cbE1gmaI29/UW1fEGzkKBrilDaNSGxAc4AEawARO4AQWYAFO 4PgoFkbn+3/Fyzut+JNx+DPLQbP7243LWEMRlbUvwRnEMRdrsMDhS8IhzJpy3NQozoh7XHNGOz7c S7jdwAAQwMIzXMOTXMM5vAoUAMU9/K1XOzQtO33rNL+J9lSpm5Iv+cUD/CCt0beDPN+grWt03Mz5 7WMMnGTiLM1JGw4eQAEwXMnnXMkTAMPvHM/zPM8RYAFIQcrJ+s+l90/JuEz9ZziNtbZtWXyB+cN9 gQSFQSVrfN/GnNIr/cALS8jVHNM3/dL74AHunM5D3c71nNQxXAFM/qABHKDPR+HPBUqy6btPa3hW zdr3Prurw5zUKuS7H5y0O728HQXYDwvBz3uLA6HIG0DOQ53Js2DVK6HVQVx+BXo1sVrF7xKtmxtx I87FbpyNtB0LHMDILzwBlrwNmp0Snv3V6VfayUVrIbfW7xpxAcTbH8yxjcjb0yDcT2DcN7zc/byv 052E1/2WNFk10Tqg2YDei/uFaC4nivy9ocDcAwHdWx26r5rgUxOt97oJIr6t/Zjix5fa/zLjNX4J OP49avrjYfriUbOiJ/pAF+A1xxpcQ94vST4KTB40T1MwW5rne97nO3oBfr6jx8/mAwjnix7pIT7p l54Kjp7pn97p/p9+6aNe6pGe6qve5q8e6zVe67eerbve66Ma7MOepMee7CPW7M9+9tJe7WOP7dv+ 9d4e7ltP7hvv2BsA7/Ne7/ee7/ve7/8e8ANf8Aef8Avf8A8f8RNf8Ref8Rvf8fHevR8JAS4cw1H9 8S8f8zNf8zef8zvf8z9/78U9AUwAAQYJATC8AR5+7jPJAJD9BEpfjz79BExo9XHu9GcfjhogAWC/ 9ofu9Hm/iJBd9XvfmAwgARrAiC58+InfmBxAAZD/h06f+bPO+IE/gz6d9qef6gwA91Ho9bWf66T/ hMQf/K/OAb4/g9C//K+O/CGo/def6rofglAd/rnOwjHoBJa//v6/6dMjiPv3HwgAwiGxaDwik8ol s+lUJgzPKVWJMFWz2i236/2Cw+IxeXtClMONRrrtfsPj8jk9aWLXp+s8v+//AwZW3QnaYRUiJiou MlI1HDbuNU5SVlrmPVJKXnJ2LjokhIpCIiScDJWeehplTm7yFQTIBgyUZTBFBAgVECDxNgVEPDnU Fg04rH4ZLDA3Mw8xHzKjJRO1RuL1FVREdNOOERTg6gIg+/biTv0WBVd3LScQMeM5MDucLKi6C10z vuatAyCAXDkC6IwIy3BQyAACxQBUaFckAoFbAHIJMSfEoLl1DjQizDhEmBCFxRwEqAAy1y2SQkgm XAig4cMh/iYSULuJ52aojD3LjRJSSmgCSAAQONOIL5rNZqrgETGxAJLUZnaaUcX5DNS0eHz6LfpX JyAAchFjfSOSKwDajLLaEphV5KwsBxgB/Bow69uvuCDZCft1920AAXjfEplF4IDhmbpyoQ1gjjBB ofmEWAWQFEBVNA0WJHimeYEQfNQALJu6VEjoE505g656KrWB2kgXSIE2D8lS2aydjnYtGpPRsNlg LQyGstjAiQEsBuh1QJyQ5wDCFUHZUcDdX9av6+IV8S/gjRcfk4tQYZfMssL0Cqlw4Dy6A/MPrN9l UfdRq7elYoHVaLehMc1oRTRgjmgI7DRVOYcgFU9qzjhI/sRqR9RDGmYLINOaZV4h1QdYiohFB1nB xJWYS+cN4d1DAoiDHREpqkUOL3cRgVZNR7QjGDmyVPAQWdWR9M03OML3VgGxUDeEafiYJlWCz4BG JWmfmYDUCWdcRoQBSw3XQGhMHQWmhNEsldsQE3pVBIBNYRFaThVqJmJxJB4H0EEoXdekezW22ItE fRI6o58s4kUAji0GcEBlPAbWC44RycKeERLhBx+iLKZkkEE7MrNUPRdGs0AD+EilSqgc5rPAaf3l c9uGqjlYlQlSnenVZxrq9pqboMEJQGi5vYmZnZrkOdZBzWm66UsEeXfQNoUO0ax63Qmq0XzeNYZE j71o/npSdIleSpJe8j1rTga6jMsQecA5I0RVHN7m6qykZTaEnBuiJtqbCwILVWnAyvuMrEVEqK+9 w1qmYYhf3ZlIiXNs000uRRYQgV6H4tjXcxEMJExcK5Z1gMYpYXvYABHEQu7FIpUXkV7oKapXLQUc 8Fe7ZaW11gB63RKXonHtCMBSaCxFT2b57npKqP3GA+WXW03z32gN3JarPPZmaA6UUG9oggFV/aZm qGRDjOwfkaVVDlr5AWopeLKIKxkRDryN6DqUFoDMOs3JqOIuBay7kWIMVUpERPNBRFAuMx8Ulyzt wdrw1qp2uWGB9kKVIWj7gkl2vWQLbDmZmgvMFTNt/jLskz281jGixMnuA0u5YuA30qOJGEAeakeo WUbwGMpzrCu0106Hxmo1BwbIdj+bvCAZIvClPrFHjMjE0vMxQAFFb4F3TXhzH8i8HBqPTfnrs29J bb7LIbv2yLdfv/33LyF/Idvj37//9etPEPz7HwEL6I4ABmKABlwgAzWRvf3Rr4ESnKD2HijACFIw gxrEntq8MKQsBC5QZVhUGBy1OzGQsBDoCKEYsJPC6HlhP21AICAU2AT4UYGF5CLDC7vwOBx+oYd/ uIsOwSAjkunOC0UcAw3/YEMmaAQZFUGCAz5FhIYEriE7nMl+FLIikxABjM4BQAZkSMYpXtGMBTnI /rpW5MZqOWQIK3nJddyoizIawyJVPIhLXKIRMWbEIHejHBnbgR00DsGLI5mJopBAk41QxyWP3BQS GbkfKe4nIi5RJB0buYUm+uGJS/AYWxJ3xbLEIj90oQ5leiE5WswsldUpZWMI061n7QUZKCklOV5Z E7rQYi07S0tzdtmWHQ6GLX4SZl3mRgtg1iI97TISLQ2no/MU4Ja4RBFlEFfK/OylbUPopgt/xEsW oQRujEILMsgpl1imZJZL4gIoRYRBJ3hMl4OqDjrgox1UFtItriRI2yRzF/UgCqE1qs98YDROke1u OUJoDgnRVZZbTGect1jHYLRJHyHYBzxuYQ67/oLGlnKg5yXr+adjnDVG8OhTGAVtJ+MyGkaCNkQc GClcdVYmmXgWgacCmY/dUCIyVj7EboXxQj2/cs8m9KVJ+xxJOHRBI4dmc5yujKQylzQuICU1JUVD kuMyoElqDYFGRCKhP3/0InFw9EdIJGuh1OqewmVTFwJgHFituaRYeCMJRJSqN/4aC0GRhIVZNRSL Fqs7U+aoq5UiLKEg89evVtIRFkzgU5kQ1YfO5S2OqitcpbXVZ3nKICShFEFY+1IWxfKsOgxhMFJI i+YNCjtxJRJCHGdV6tBWpmUxattcK7TUujRugattdFIr08Qeakjl3OKzHFW0JaW2F5QtZ3af/svU zdaws6M8LW/lCD34aCqjFi0Lef/EkPeiFFwCjZtIv/MnHVorpUXY63d2Nq11aGqqm0qRjPJbnebg hyDickhlaiHEwYJ2UMWQCAvXW8bpWjgDO91dBZpEDLyAVkYSLi89wetE8SrhsySObwTW9SOTnTQX inJUe2OxstHK+GQ+rZk4faYXQZlsZkflUcY2ltxdpvVjIWvczxInYB+Pa7lFPqlAGjU31OqYZ03W 71y/sdzABHO07mVhjteVUxaVOZg24lijTrYecbALomC+sVy/28EuqNi9SabbN/BWGOrMDEbtbRzd DDc5Q+/sWZDzJi2WWkQ/A/WFVt5z25jE/tMnN7pdgYM03FAiKfu+Eh0OMGHOECVgWSiEsjwr9JgP 5ZhDT/fV48KRfRmdH8ruEhmsnXBm9WDiUKJ4g1sQp/Q8KexP/tqex27DAMS8Po8u29d3jrYYvAdE ai+wqZgINra77e0j3Gra3x43uZdAiElcodzqXrcRFMBtOiDgeuye97hP8ABK3IPe+q73tQNxguHt O+AajLclzi3wg2dQlH4gOMIbLkF7X+IMDp94ARluCYtTPOP2kzgnTvBujYMc3QrwxAMgHvKT76Pk AK8ExlHu8kt86VWdONXKX25zRNxD5p6g+c17nogHmCp5SNG5z4s+BweciujJsJ7Sje50ajLEWwE1 d0e8PX7vp2M9DA+4Ccfrt/UtueYOaxg72ctu9rOjPe1qXzvb2+72t8M97nKfO93rbve73/1WJzCF Ca7uPwc8gEF4HzzhC2/4wyM+8YpfPNwR0O+sQz7ykp885Stv+ctjPvNJCAIAOw== ------=_NextPart_68E_A398_953FBCFE.100CB3FE-- From AMD@editrans.ru Sun Jan 14 14:35:01 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6B89-0000tK-HN for sip-archive@lists.ietf.org; Sun, 14 Jan 2007 14:35:01 -0500 Received: from host220-132.pool80116.interbusiness.it ([80.116.132.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6B86-0002om-G1 for sip-archive@lists.ietf.org; Sun, 14 Jan 2007 14:35:01 -0500 Received: from QOVKVAV (unknown [105.144.106.46]) by editrans.ru with ESMTP id 0A76E4F59989 for ; Sun, 14 Jan 2007 20:35:12 +0100 (GMT) Message-ID: <000a01c73813$0b3204f0$00000000@SN200568520006> From: "Asterisk" To: sip-archive@lists.ietf.org Subject: expansion Tim Petrillo Date: Sun, 14 Jan 2007 20:34:44 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C7381B.6CF42300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.7 (+++) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb ------=_NextPart_000_0006_01C7381B.6CF42300 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C7381B.6CF42300" ------=_NextPart_001_0007_01C7381B.6CF42300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Breach unfair all those people. Prize pim project fujitsu sets? Winner = robin, williams critically acclaimed thriller? Labs forums general forum = marketing faqs how want. Ltd license holdings sharmans chief officer = nikki hemming. Digitally enhanced trickedout verison ron howards debut siteselect. How, want ads barter asterisk user? Harrowing young, listener his. Said = michael speck managing, director music piracy. Based gabriel noone celebrated latenight show captivated harrowing. = Electronic frontier foundation, usbased nonprofit group. Third santathe = barbarian shaker girlschump. If wins declared it! Ppnet libel bearshare settles torrent, advance? Epygi present pbx session, announcing magazines award. Oil crack disk = drive, pioneer. Court battle between australias record giant reaches monday. Group aims, = protect rights ruling. Data management creating including cost for. Crudeoman refiners = sidelined weak fuel oil. Ranhellip related channels servercall road named. Disaster focus florida tmcs seo program optimizes organic search. = Shanghai ultimate villain station agentsweet alabamawho framed? Strong = survive soulopen rangethe osbournes. Technology web site corporate news = buyers guide. Girlschump changecity godcold, creek. Visitors disaster = focus florida tmcs seo. Thriller based gabriel noone celebrated = latenight. ------=_NextPart_001_0007_01C7381B.6CF42300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Breach unfair all those people. Prize = pim project=20 fujitsu sets? Winner robin, williams critically acclaimed thriller? Labs = forums=20 general forum marketing faqs how want. Ltd license holdings sharmans = chief=20 officer nikki hemming.
Digitally enhanced trickedout verison = ron howards=20 debut siteselect.
How, want ads barter asterisk user? = Harrowing=20 young, listener his. Said michael speck managing, director music = piracy.
Based gabriel noone celebrated = latenight show=20 captivated harrowing. Electronic frontier foundation, usbased nonprofit = group.=20 Third santathe barbarian shaker girlschump.
If wins declared it! Ppnet libel = bearshare settles=20 torrent, advance?
Epygi present pbx session, announcing = magazines=20 award. Oil crack disk drive, pioneer.
Court battle between australias record = giant=20 reaches monday. Group aims, protect rights ruling.
Data management creating including cost = for.=20 Crudeoman refiners sidelined weak fuel oil.
Ranhellip related channels servercall = road named.
Disaster focus florida tmcs seo program = optimizes=20 organic search. Shanghai ultimate villain station agentsweet alabamawho = framed?=20 Strong survive soulopen rangethe osbournes. Technology web site = corporate news=20 buyers guide. Girlschump changecity godcold, creek. Visitors disaster = focus=20 florida tmcs seo. Thriller based gabriel noone celebrated=20 latenight.
------=_NextPart_001_0007_01C7381B.6CF42300-- ------=_NextPart_000_0006_01C7381B.6CF42300 Content-Type: image/gif; name="Human.gif" Content-Transfer-Encoding: base64 Content-ID: <000501c73813$0b2fbb00$00000000@SN200568520006> R0lGODlhoAEoAYfrAAUAAIAADQGIBY6OAAAAiHgOcwiMjcq4yszdvanR+0YhA2UeCIMbAKwqDbIU A+sXAAxEAitAAEdLAmZHCY4xAKs4CL1CC99MAAxnCCJjADFdAF5bDYNcA6VWCrlnCt5YBwN8AC17 CUWGAGKEAImBB6iLAL+IAOR4AASnABWVCkqmBmGUC3uhAKWuALGaDdulAAHOBRbEATi0AGe7AIu6 CaDEAMu5DOqzAADWABvsAELfAGLWBnbbAKXmBsrZANnhAAAAOBIJQkIOS1kASIsATpcAMr8APdUA TgoWQSMXPzUfOGIYMYUhSKoiMswiOuEuMw1AQChASkVFTVgzRHdNOpU1QLcxSdtNPQZkQxhtMjxq M1ZjO39XAJlhP7RbQNNaRACETCZ7O0CGSWeMRoeFQJx+OsF6M+lySgaVNROeQzWlRWGiS3WoM5+u Q8GbTuGgSQC5OxHHMjy6MlPCRoTDP5bDSca1See7NgjUMy3WNU7dRF7iTIrVSZbkQ8TgMd3fPAAA ehUJdTYMe2MAiXMAeqUAfLQAe9UAhQAnghonhzUihF4kfHolgaEadccmiO4efAtDeB0ycUtIgm4+ eHlEjZ01gL88duxDhQhZgChiiE5ce2pjgoFceJRmfrVSeN5TgQx4jCR2d0OAfVZ+hnF9dqqGibmN dul5cwWrgyilizuSdWefgoepcZGdgcOhjtGtcg25hySyhjfGdV/AcYfMeJG1dLPAdea7iwDnjSvi cUjhcVbpiY7ZfanadcDpcezqiwAAzikAyToAxWQAxXcAy5MAwMYAxN8AyAwZtSQVwkwXvFUqx3Qo x6ksxrodvt8RwQw5tCQ+uEhKtG1IvXlLyKg3vslBztVDxQBuxC5ZvkVUyGNRuoBYvqpmxMdgw9Vh wgyIuR14uTODxVSJx4mJzZSFx8l6yO16uwyjtymnskmoyWWUvo2avKaYuLagwOSisgbMuiHNxj3F wWG5wX/By6m5xf///pqssIl3jv8AAAz/Df//CgAH8P8L/w3+//D/9yH5BACfy4IALAAAAACgASgB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3MhRob2PIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qlWUHbNq3cq1q9evYMOK HSvwqtmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3YuXrN+/gAMLHky4sFgBArIiHhsggGHDkCA9Rvjh w+TLlxcL1KyQ80bPXxsXbOw4oWiBpEsDjiyQNeuIriUvjExbdm3ZHSsXrGzZIG/e/37rxkx8oUnE IJGjVJ6TedDUAT42RklaenR705NG/rg9ZneV37lD//op/GNllefP843KHLny94jdx/8YX0Dy+fbq 38evP39//86tlBpI2Zk0oEgFHtXddgvSJt53t9nDYG0jhSfheD39BpJ6KKnH4XpFJVRffP9otpiJ iZFYYmIrtjgQii6eyKKMm6U4I4sPpTYQdAeJdtqOqq1GW2uSvUbkka/F9k+SuBE5pJNNavTbQMIp NFyVxWWJ0HH20ddlf/D5d5+XYo4pZphofmnfiF22dGB2CVp3IHbXLUXhhXiC1GCeE/KJoZ5/Vhjo TRra4+EHJX24IaIgLtWemmGe2WaaIVEqKZmWyjQgnHWOVGCc2jmIZ3h7ljreniFZmOqghPJmKKOK Lv9KUqyNFvWomWXKZ6auu66pZq6+YvrrS5texymCxnbKFISnBmqqeKNiaKGqgPKk4aHmMfpqSNjW CpSIOHLm2Ygu1iiuivW9mO6KMMaoIkQ8okYakKOVBl2QfxnJ5L643bZkkbZFeRvAT3KEZXDACTQc wrslrOXDFYEGcUQ/TmyxVwtfrDFYEm+8UMUeh4xRxiKXbPLJKKes8sost+zyyzA/dFOAcoGKF7Vu 0eqtW/idFCDNaiU4Z0j3yqmsUKgKmidcHxY666FO73xUz1zaBR2d1p003bFFJS0SzmyV161IOuss tU2d2WjuuuS6i+K7j+loEMgEnWY3vl8xCSWSAPP/7e9lU/rWG0EkUzl4zITR2CKNMCruOI6GyV03 3pMDSTdYtRmkpJL/ds75Y4ETfrjhDis8OuKBPb642quzS2K7k0n+z+X0yms7WZlD2Tfnm/cNeOmF my788KiHxeWIl/Kq68/DSvXm0cgSmKyCoj7bZ7TYT1Wo2WObfTbaCJ3buurk30icjnT/WPHd+fYb sOe+9945ZlMWfmVv9xdfmPiM24juje3qmGDida/bzQ5fshuLkf41JN5lTn6TwZJw8De40AVPfxiM HOUyuLELcvCDIqMdCCfmwREW5nsoTKEKV8jCFrrwhWezGQyl4r0ZOgVoywnWW4RWnZL0UHp2klaz //DSNFeNZILZqqENsRI+yEVEgBDjEfvmhrd5BUZvLqtS/hKimy2akCNVqxR/fiWfMkKqTVAZGhCj hywZDuVZF2KWg+50p6ZETVaJgpUelxgTcBGkceZTHLsMAkXAJPCAPZKbjzYoltwtEH5+01yUABM6 w1mpgqX7olfG1Ta2sa5crnNiYWRHO/YV8IpP4lf8fKc7w1SyhAvzoia7wklC/q9c4gNl3Kwowika UEh6C+b79PU+VyashAwbHjJnCZEwkqlM0ORVNJsXlWJ5anpYW2MQqwXH6/kJKtfSFh63hUcl8pEk 4PpfLWtkLlC2bZe8JKBqEijCRrqvlQz8XD4n+f8XCfrTkqJbJjNltkQ31gps2hPnORdaFIPypY5o MSdDeTLQilr0ohjNqEY3CsaZoXGH0OMjQoki0YnqZCHkEqAgPbY+K9ZLkS5t35Ec8siE1LSfo/Ng 4CbI0c+I0o8mk6K9GIlIX/oFix25KVn8eTpl5rSpPU2IM3tlqf9cRY1Z8yE2HQqUOtLxqw8SoteQ csey7XGcJk0JUP/oxP7p8mGHrKf6YiqkgQiTb/OTZF4pmUmd9hWqUX2iKN/mVrhFMaZynedQB0PM Bw6Tla1U6lheCVUvCjSwA5mqsDb7qI9etYcO/RQ2QzVW6zlLiEtbitPMmi20ppWJTSxI+dz50+L/ oK+Kiq0cIusKyd5CcKb6DIwFD7dFWWKWITmcD3yUGyyrfha0V8umdI22TT+h6npfnSOrjFKeJGqL Q6tV6GvHy9XxDqWk5k0vdUKqXpKKt73wja98V3jc+toXdQVlr1xGGrb3zvcmQC1ky1paSpceUoGO 5CdDJPsQBk8kY5UkHXB4el+PlCRSjboa14g2vQ1TD1r8JUmIuRvO1ppEUeiV73/AtOIxPpMqWJ1u Vrc22g9HS1RxFGuDdqzjHFevWTiG6EnuaOKnkc2//72wZy8FzWc613k/1CaHs+Zho3RziNnzpqlQ 2yfsYjnEZfUeipEMX5RCLqXmC6W6DttShEwx/17tS+VjHYtX3bFSfg7cp4IFZ7/KPrXCyD3esJSn w1ud5XkGqrGMuzYoOFYre6ldWpeH6OiWhDmPR06ySALMutm6rbaxm1f6FrvbXx5VYI+t8+fuilcI 5tkh9aMg8Uh2WUAfJIDpwvXr0nw+mMLUcoolKuZQDVw5FztgSMXzKvfWkIMNF6DQtvVx6yltrdS6 2hPJr6aDkuJte/vb4A63uMdN7qqU9y0jVku3y/2RtBk2ZiBLLLCp3RVi9hZltAZshK8tbQG7TJ6M pKupEWzX3e1ZY0yljKxNB1hsy3aw6lyX6yxGT6KOWjD2jo3Gkc3xgg1m3w13Kr/7fcvxfZKdbP9G oMVxi/F7rrqmyi4MyBeSv5Fje7aPe7dtEbvyejHW5Xdukr9++3HgNTyWB3N4Q3CuNtilvHZuVvnP C35ve0MyuIJ5tsIPYvNqM711b82S5NoM9VKjkuovp/rVIVt0pIuOeA1TemaV3DMWMxl5h56T3uu0 d6dEyLqpjdCkndLdV4FXj1Fb90IxSm+5Synkjo+IDc/N7pUovtyRz7zmN8/5zqes8qAP/Uo8T/rS X0T0qE/9pk3P+tY3RPWwR73rZ0/72tv+9v+Ive4rj/vek373wB+374e/+eAb/9vET77jj8/8JCv/ +dCPvvSnT/3qf6X52M++9rfP/e57PyfWD7//+MdPfr98//zoT7/618/+9rv//U4JCz/44Zf5F8T+ EsF/+aGP//7TnyHzF4D/oH8CQYAI4X8F+H8LYYD2h4ADSH8MqID7p3wOaIAHEYETUYESmBAYqIEH uIETOHwe+IAWGIEC+IAkWIL/p4H+14ArGIAQ+IIJiIIp+IIWGIK0B4MwOIM0SBA7SIMuCIQgqIMn iIBFGIM8SIRGKIMOiIOedxJKyA8fQYQmMX/2YIVXKIVWiIVYGBJROIVSmIViCIZjyIVKSIZmmIUw CH/kphBRyIMLiIQoGIQ9OBBvKIQ9SIctqIMzuIRO2HookYZkOIYksYVhaIhlGIYiIYiJSIiI/+iI h6iIjziJisiG4BaHcJiCBsGHeOiCJ7iJMmiHRyiKCfiJTbiHNgiCf5h5TdGFlviKNUEYN7iKtGgR sHiLdFGLuqg/nwiAQziLsqiKu2h7VViJKuGKhEgTyGgTywgUzYiLLcSBwiiN9zeNEQGMFYGNWqGN w2hCxWiGXbiGyaiGWhiAYBiO5riI6SiO6giOkbiO8IiMOggS4oiIjAiNMESNSSiHdEiKpbiPeOiD CtiEADmKc8iEKtiHCHmQmdiNFVWM9DiPVCiPkliRa0iFXliRgxiRaKiRYjiRxjiIlEiO9RiS+MhC +liHKomBcMiSFziQoeiP/eiHAvmSCqmQRP/YkA7JUfpHk/3YkjB5kysZlEMplJ24kKAolCO4kxoF kRGJjvcIiRkJlSYZj1UJj1PpjhuZkSKZjo24lScZjUw5lhATlmaJFmSZlllylmxpFWr5lpfRlnI5 l3S5RHB5lydUl3q5l3xZK3j5l4AZmBjUl4QpFIJ5mGBRmIrpE4jZmI75mJAZmZI5mYG1mJZ5UpSZ mc10mZzZmZ75maAZmqJpF5pZmq83mqiZmqqpEqbZmlK1mrDpmrJZECZBAATwEbaJm7epErbZmziR mzMBnLopnL25m/bgm8dpnLDpQsDZnMpZm895E8IJE8iZnLppndaZm9oZncvZKAlhmwIBnv//IJ7F aRDiSRDkSQDj2ZvhyZ7r6Z7l+Z7q2Z7nWRDnmZ7r2Z75GZ+ziVHFGZ/4iZ7zKaD66Z4Eip/3OZ/g GaD2OaAIqqAQqp712Z8cdBL/iZwXKhLbuZ3XOZ3/iZ0cOpy+maEjQZy7GaLTmZ0p2p0pdKHOCZ0g gaK3aaIdeqIzapwpuqIaiqM2CqLPWZzYyaIr9KLXGaQx2qMvSqMqWqNHyqRG2qRFKqMhwaE6KqRS Q6QiWhIfmpwjqpwfSqQYWp1AWqJiWqY5aqPcaaVquqZs2qZu+qZwGqf2QBwTehEGqhALOqAZUacU qjJ8ChH86RB5mp8U8afvORCDKqB3Kqh6/4qnjdqnWmKoDcGgk6qnkroQhmqgiYqoEBoRl8qpkBqX WhqmzlmdUOqkpYqkNyqlO5qqZOqjT5qkpMqjXRqlXeqqcnoUSsqqp7qksXqjvgqrU6qqowqrZ1qj PeqrUuqhPJqrQfGdDtqplEqoBdqp8imh2Eqt8mme0vqo1fqtisqgDwqum0qtixqqZAGjtiqsvbqs xBqiWbqjTtqqQAqvRXqqsoqqwNqrXOqsPQGtoLqf1kqghDquAnuwBNug4Kqw3zqhDhut5JqtCKuf DIuujwGfGHuu9GmpAFqeiaqp3rqt2hqwB/uwFSuy17qxERqhKGuxYyETVSqvORGz/ppeFf/xqfS5 ETjrsjzbsxlVs0AbtNnns5MptEZ7tLpHtJKJtHSptJHJtFAbtW3otI8ptWxJtVibtRNotVzbtV77 tVKhtYgJttAotmZ7tmibtmq7thNDtm77tnAbt3I7t3RrUmwLl3Xrfr74g70oir2YkyQokKrYtwIY hZ74g36rhHdbPEcYg8L4ty0YuJr4khtYuLPYuDBpjYtbMlDoioZokmr4lFxpjuw4El55jqFbiFAp unmLlh/4uJcbuZSLuJRbjY77un6bu5vbMt9YEqc7lairuqUrvO2Yuqa7usHbumYhjbDbvP84u5pb gzlpuLcruaWouLvLub77jL/Lut17jt//C7zAG75nKL7KexXMi7u1a722S7ugWLmeiLuEy43ZmzJ9 q7vv+7z5676Ca7vs27/se7/1+zKQ+7/4W8CYq765K8CSi7gMPMAsw7fxu76Ta7mZO7gmaMD6K8HR C8H2y4l3yInXK7vXm7/9S70BbMHY68EXc76vSL0wHMMyPMM0XMPU68I4nMM6vMM83MM+/MNLwcLD CMREXMQ/IcRInMRKvMRM3MROfFFGzHxPPMVUXMVWfMWzF8XHh8Xip8Ve/MVgvH5cPMZkXMZmfMaz FMZqvMbohMbQx8ZwzMZu/MZxLHpzfMd43FF1vMdRnMd+/MfZxseCPMiEXMhkC8i9Z8iKJbzIjNzI b4rIkBzJB+HI3ibJlnzJmJzJeEzJ26bJrMfJoEy2AQEAOw== ------=_NextPart_000_0006_01C7381B.6CF42300-- From sip-bounces@ietf.org Mon Jan 15 02:05:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6LsN-0007CN-DT; Mon, 15 Jan 2007 02:03:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6LsL-0007C9-Rt for sip@ietf.org; Mon, 15 Jan 2007 02:03:25 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6LsK-0007OP-JG for sip@ietf.org; Mon, 15 Jan 2007 02:03:25 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 14 Jan 2007 23:03:24 -0800 X-IronPort-AV: i="4.13,187,1167638400"; d="scan'208"; a="101608421:sNHT42187383" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l0F73NkR023377; Sun, 14 Jan 2007 23:03:23 -0800 Received: from [192.168.1.5] (sjc-vpn-hwcore-693.cisco.com [10.21.154.181]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0F73NDk007088; Sun, 14 Jan 2007 23:03:23 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] I-D: Preventing Fragmentation for Client Initiated Connections in the Session Initiation Protocol (SIP) Date: Sun, 14 Jan 2007 23:03:08 -0800 To: Alan Bergmin X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1035; t=1168844604; x=1169708604; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20I-D=3A=20Preventing=20Fragmentation=20for=20C lient=20Initiated=20Connections=20in=20the=20Session=20Initiation=20Protoc ol=20(SIP) |Sender:=20; bh=P8ou2+K+gn6mHOeHREDpNk4ps0GgLngGqHtJ0ur1lbA=; b=DRHjNFuLOUGaCWrPaVzZaeWo5giJFWbc++YQbbVZAzd8FwGMFmJm/13mzZv4APTtXYL0WFW/ w8mlzwdvBNdw6uBspMTAV4G112Vb/g7dAIlL9b8/y1EiJ8xqsUgdExY9; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: sip@ietf.org, Marc Petit-Hughenin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jan 6, 2007, at 11:38 PM, Alan Bergmin wrote: >> The TCP connections are temporary, not permanent. >> >> I think that we can compare this to a HTTP server. Even if I am >> constantly logged in slashdot.org, there is no permanent TCP >> connection >> between my browser and slashdot.org's HTTP server. This is >> because it >> is more efficient to close the connection at the end of the >> transaction, >> and to open a new one when I click on reload. > > Looking at most of exising web sites, I agree most of TCP connections > are temporary (ie: limited to the life of the HTTP transaction). > However for "dynamic" web sites like Gmail, there is a permanent TCP > connection reused for many HTTP transactions. I'm running Safari to gmail and that does not seem to be true. It had a bunch of connections but they all seemed to close fairly quickly. Check it out and see if you get the same thing. (I do agree with your meta point that AJAX is going to cause longer lived TCP connections). _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 15 03:48:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6NVG-0005a1-I6; Mon, 15 Jan 2007 03:47:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6NVF-0005Zh-31 for sip@ietf.org; Mon, 15 Jan 2007 03:47:41 -0500 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6NVC-0006dK-Kd for sip@ietf.org; Mon, 15 Jan 2007 03:47:41 -0500 Received: from ind-dkim-1.cisco.com ([64.104.140.57]) by ind-iport-1.cisco.com with ESMTP; 15 Jan 2007 11:49:25 -0800 X-IronPort-AV: i="4.13,188,1167638400"; d="scan'208"; a="74280673:sNHT5699057040" Received: from syd-core-1.cisco.com (syd-core-1.cisco.com [64.104.193.198]) by ind-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0F6vUZV014446; Mon, 15 Jan 2007 12:27:30 +0530 Received: from [192.168.1.5] (sjc-vpn-hwcore-693.cisco.com [10.21.154.181]) by syd-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0F6vNlG025520; Mon, 15 Jan 2007 17:57:25 +1100 (EST) In-Reply-To: <45A0A483.7020900@acm.org> References: <200701061636.l06GaER12161@celine.siteprotect.com> <45A0A483.7020900@acm.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4AA693EE-D8A0-4658-8D3C-95FDC5CAA6E3@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01 Date: Sun, 14 Jan 2007 22:57:08 -0800 To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=516; t=1168844251; x=1169708251; c=relaxed/simple; s=inddkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20draft-petithuguenin-sip-outbound-fragmentatio n-01 |Sender:=20; bh=FbgVyxgry5WxEmCYFc/Leewuq1f7wAsPhmcIVwDyuek=; b=G4d8vC8xCmDnBMTLwIWXg6TOVAPcu5Hy+6eVPsOsBj9BtFKiWKNgSdaZ2NRbCuW9U6pjH92A gpWdsf5fxilCcCMLwQhY1FPmQ9YZboJ3DSvGkZyZ7l1VBr/o2OVtspSU; Authentication-Results: ind-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/inddkim1002 verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: sip@ietf.org, 'Juha Heinanen' , "Frank W. Miller" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jan 6, 2007, at 11:42 PM, Marc Petit-Huguenin wrote: >> Basically what you are saying (with the other UDP-haters in this >> list) >> is that the UDP problem is too complex, so let's just remove UDP from >> the list of transports supported by SIP. One of the hilarious parts of this whole conversation is that one of the key reason UDP was done in the first place was that implementers felt it was much simpler and the "just keep SIP simple" argument was one of arguments for including UDP. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From gthorne@worldwidemeats-eec.com Mon Jan 15 04:06:54 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Nnq-0008DM-Me for sip-archive@lists.ietf.org; Mon, 15 Jan 2007 04:06:54 -0500 Received: from host19.raasn.edunet.ru ([213.184.140.19] helo=GB) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6Nnn-0001Ou-NF for sip-archive@lists.ietf.org; Mon, 15 Jan 2007 04:06:54 -0500 Received: from 81.223.20.29 (HELO mail.worldwidemeats-eec.com) by lists.ietf.org with esmtp ()11)4/E@E +-2*5U) id 2W126)-A.20H3->Z for sip-archive@lists.ietf.org; Mon, 15 Jan 2007 09:10:17 -0180 Message-ID: <01c73884$f9338450$6c822ecf@gthorne> From: "Mohammad Cooley" To: Subject: MS Windows OEM License Date: Mon, 15 Jan 2007 09:10:17 -0180 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C7389E.1E80BC50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Score: 1.8 (+) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C7389E.1E80BC50 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C7389E.1E80BC50" ------=_NextPart_001_0010_01C7389E.1E80BC50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Against this sky no longer of our world.VIII. Russia: The Great Northern Ex= peditionWhen I am heard, and what I say is solelyHow can they get the point= of how a worldPeople might see to be the openingAnd the wide arrowhead the= road itselfReferencesAway from their profundity of surface.From there. Tow= ard . . .Across the heavens' gray.Not daring to opposeWinds blow sharp, wha= t then?And beyond, the same sound of beesshaded by live oaks and bottlebrus= h treesAgainst which we have been projected? What . . .Close at the end of = distance the two ChoseToward something that the world is pointing towardThe= bees are buzzing,Homeward into the howling woods, although ------=_NextPart_001_0010_01C7389E.1E80BC50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Against this sky no longer of our world.
VIII. Russia: The Great No= rthern Expedition
When I am heard, and what I say is solely
How can t= hey get the point of how a world
People might see to be the opening
A= nd the wide arrowhead the road itself
References
Away from their prof= undity of surface.
From there. Toward . . .
Across the heavens' gray.=
Not daring to oppose
Winds blow sharp, what then?
And beyond, the= same sound of bees
shaded by live oaks and bottlebrush trees
Against= which we have been projected? What . . .
Close at the end of distance t= he two Chose
Toward something that the world is pointing toward
The b= ees are buzzing,
Homeward into the howling woods, although
------=_NextPart_001_0010_01C7389E.1E80BC50-- ------=_NextPart_000_000F_01C7389E.1E80BC50 Content-Type: image/gif; name="nuvoon.gif" Content-ID: <006901c73884$f9338450$6c822ecf@C401675> Content-Transfer-Encoding: base64 R0lGODlhyAGXAbMAAP///wAAAAQE/B9hqmGw5Orq2729u8/PzvfwYvvQCGBUI7OZbPqCBvv7+wQE BAAAACwAAAAAyAGXAQAE/hDISesMOFiQNcVbKI5kWXUeWKKshXKdpJq0y85ya7/XnY0+Hg1XK5qI xqRSiSw2l6TYzgOtWmEnqkjaI+KeV6AW2y1/Zr9odFwFh9/w+JHtpMtzTe59n+2L7TBaX4B8eVRe Y4hri29ufI+QTIQrk3AgiopnaT2Bmk86WZuBQZ+TKqRpiKJdjmR+hpw2W5WtOXiHoKNsl6cpq1ip gkKelcCDv6x2Ur2yGzfEjRqYicLDoM+hw7poqIamvKi2yap6deJ+rmdbc0PSPNjb1Mvu5TrcufGU XPDjSEHnsaZs4geFV59MnfCYWSiq4b2F6SKiExMw4kOFGBMaYdZMoseP/hP/4MIVCuKqfcdepcyI TFPJjBpjDgwWsiPLWowSASRzkqTLnxJ7yasIsmjAQSqp7YzJbqkrWDZF+gB6DunLoKqI8tzlawdF dVf9jQwrjBFMpkk4blVp1ulFZ3S41QRr1mosN1Db0aWbd69UfmIr5g3ckXBLj3iVRi0c16fTvX0l Ve0K1hFCyNoGKw5RSy5RtXD/6fU7Ga7pppQYE7vG9TTWcdkIhgwX2jM627NIG039lPLdb3PJzXR9 eTHxspUJ0eatG7dWnLuX4l5O+Hbrfv3KzSYVe7hN0JyRzzVnyzn4qJGTuXX8+KxXgJkSt2l83LXW 3KiPisffnP16mmlt/iaSfvad9x1983Finm/hBQccYv5Z9iB8ism3RCn1LQYdTtXZxd99zhVlIHPt PeffTga1ld5GJC141oJDSedLjBZ9A4hDfgmVlHG6fSbgazVweF06v4TYE2nn6Tgeih0OWaM8xawE kWQXcJAje94B5VA1DHm4Wz1H+ijYW4eVqFFPYy1p31d80YhjNiZdt2WXE9Kp5Zy3wEnimdB9+OaY 1jSmTTxQhqneLKJhNhFBsnUnxFSOItgOdUM+ik9gl1bKKD5r3lIkpLCJFSVKg1IJU3GZKaOdp4JW x4o+qxL5Y6mlRoomGLX22c2Jx1TjqjjaucqpLvlBU5uPSRaT56GR/jTr7LPQRivttDxSa22x12ar 7bbcduvtfd9y22e45JZr7rnhjotuIcqu6+678MYbjbzSxkrvvfjmq6+Z+15RZr8AByzwwAQXbPDB CCes8MIMN+zwwxBHLPHEFFds8cUYZ6zxxhx37PHHIIcs8sgk7zmtuhe2W/LKLKesLcqmtizzzFbA bInKCdKs887kXWszizwHLfSywiGp2ijbHZYrgEM3LXOi+TC5GTh/Rr2aqMM6rfXHM5EJnqGk6pfm qVLau/XZGKP5ImjSYDb1jGQxRiPadGsM1d0tYqnpenVJWvffFuN9mlzT7Q1heFn2CPjiDQuuGuE/ 9sb31SdGx/jl/gQ7bp3kxUl++KulVYv56JkjqBnnkXt2+uaik+46wFkx1ZCVH9COpE9qy3glzq/3 /m7XY+c+JZC9jc1n2f/6rry8LfT66dy6Uzgo1NtYvvz16M4TG2fOdApjKd/zi/345Jdv/vnop6/+ +uy37/778Mcv//z012///fjnr//+/Pfv//8ADKAAB0jAAhrwgAhMoAIXyMAGOvCBEIygBCe4rwYU oQEYzKAEMmjBCXBwCRg0QQdLEMIaWHCEJaTABykotBRWQINJ4KAMRZBCGNJwhR504QszWIAGFOCH QATiAQ5QACL+UIYhROIMc5jEEVoAhyzslw1j6MQLOnGJO0Sh/haVuEUuyrCHQfzhEMdogDKa8Yxo TKMaDWDEGWrQizoMwQkBUMUoCqyOYZgiHeO4QS4+kY59xCAYw0jGNa5xAYZM5CEJsABGLuCRj2Tj EeHoRzwC8oV2vKMlIYHEPfLQh0Ik4wEUiUZEkvKUqDSjKc9oSgIYgJGOLCMRO0jJTpIwk/lqogqb WMc4InGQQiziGEepRkSacpWpTGYakanMZjKTkQZYpRGDaEte8nGDuKxgF3kYRjEW0pnNDKc4x0lO ZY4RiF68YTbpJUgjEpOUzCynPOdJz3qicpTD7OEJ9/nETa7TXD5k4xCjac+CGvSgCCUlPiXpRib6 85/h8uEw/l9J0IRaVKEXzagiFzrLfWoRovAKKBkfCU1jqnGYKE3pQmWp0jS+k54vZaNM0RjTi5oU kjjNaSTjeUZi5nOOUAQpuiS60GO+spFmRGk3ixjMlDLVnS3FJ0dlmVSZrtSQUu3pQH1qz5vq9Ktg NaZYXcpSls7Sg0KNVwGsaoABkJSg8ZzmUucaRlB6c6tZTalAqcrRlirTqNEMK04ZsAAGGPawiD1s AhLL2MY2trCQXKMoD1DCa6b1Ww2w6gEW4FYFcLaR0swnXZs6xGAGcaJcnapPa/rXwAr2kQiA7QJi G9sELMC2j7Stbm97W90SdrHAZUBwgytcwy62uIRNLk4l/vvTOV72XCKlKivdGtfTWpeQo0XtTBPp 1dh+dbeLLexwE0De8pq3vMZNb3GBS971uve96SWuYh1L38NGUqs/fe5QG7BVQ7oSq0olooCdOs1v FtO1OfWugmmbAATYtrbg5a1tf+ve8QqXves9bnuHi1z2Hhex8uWweh1rUrZqtof6PddaTaxQlQ54 mASIsYxd6V0Kc9jD582xeY2L4w3r+LwXvjGGNxzk+FY4xCIeMX0/TGIEmLW5eNRjip/F3+22eJqU fOWMo+ngLs9Wwr0VMpB9/GMdX/jIFvbxmYm85grPl7g3nm+H68vYyJY1n4FM55SdhcGpblSp6NQn D7U8/uPaZrjMYz40esmcaEYvesdDFrObx/thDSfW0nOWM50NW9ieatajnnzonu/Q570mUqpMpaag fYjBGcsYwosusphzvGZE/zjDbQ5ypDF8ZDfzWL1sZvKlQazkOkfSxYIO9aillVmu/rm0k/QioWU8 2x472ta0LnOts01pXKu50ZPWcIiB/V5hbzqxBnAyW424x0AuG1pVHuipBXpOVX9yra4mAKx1ze1v 79raj/awrgc+5jT/Os68xnWmia3pcyvXlHgdopQt++488re/zxZjoFnNwXzr28wCDzii+Y1tHLc5 1oyu9bZ9HWsj+1rJ5t70I6Uq1SiLuuJVuLipT0rv/nqD8ZeZzbdvry3ykpec5AAHuLcjHV8LN33h b264wznt5IifdYc450OpWXtSn//86xicdowdPPKy+zvpPZZ1momcdn+fvNeVJrd8p07nmedVn5ek eNah0OesZly0HOeg2PWNdKQb/fCGP3y33f7ocp8503GfO90Ra3eaU5aW7d67HCzo51Lq1LuQXa4g W51vBpA98Wjvt+LZ3vh/n13lCIdznJFL7JjTHZGWR7GyNR8Hzk90mWHlNAMUMPwFrPoA+Sb76o9u 9oIXPdtLH7K3cw1nxyd58o9FgOU7GlTeW6Hv3LXzbDcrTQMY9vhCD/Py1w99xaM+5KyftOOL7Vjb /jsctkq1pffzCACUFhO2qhRY9BZYl9dnyWdr78d+7kd0Jxd/kMZ4j9de8id12Ed8uJd/UrZ/fAcA a3VVrBRZm+VknQZE5scA+iRGB4htCbh6K/eA/WZ4/PZ21VdukUd79Id99sUAL9ZGeqeBJtR/GOd5 s1VG6hZNBUZYP8df6aeATMiEJNeCDUhmskZ7Eshw9oeDhNVzpZWBPqgEEmVlHwhJIkh+BSBWM/dz yOdqyteEbMh+hed84iZ/Apdr5GaDWJiFGNiDXUhCHQiGqjRWIghJOYhOSuhqbeiGh7hrirZ0Uzhu dXiHdWd8otR9e2hFwuSHYWiEo7RiZYRIKAZG/imYiKKYiDGoZuHGazUIiSTmVFxYiTTwhfL2f3DV iT5FiIJUAEI3irr4gg8Iew5ocsEGc8NmhzhYecOkh65IQ30Yfjs1SjGGfFjGQbiohrtYjeu3bQ4o d3I2d1d4hwuQUq2YjCQAi1zXVsjkSgNGAJS1aj4kdGtojdZIcNaGZtg4ezOoivR1gWMUjuKojHj1 fzlVRs8YY+zIarkIjwhpdE8ofTWIaVb4iN6ogyiFjP2YQ0W0c8vkWZCEjmkYY9KYQaGYkAipdsBY ilLIZLOHj/X1jRN5cxX5Qiy2TATgWdSVRqMnjQcpkjopcqUog4vYWPeokoYFjhTZjyd0kR54/kae RYRmVURKpE8huZNS2YitF5QpSYU3iH1aqHsv+YrxVo4uFWhHlISkN2NSKZIrCIEGJ2yOSIHYV3UC VgBdeUEdCJad6FYE8FRk+UmFKGMNdpYJSZIN6JMOeX0oyXBYqI9XN5ci5HdqRAAOoACSKZl5yYmX R5ZRCZhoeWtsx3JYOX9CyWmSuI+MOY4ScInlqAADIEuMpAAEkFluVYA32ZExppm2qYisJ2JXGXXd OHWSKEwu+ZL71Hk9tZSbuFkKsFbfWJBl6Ze3GZi82JnVF3e8yVi9eW4sGZelOQLDaWBo5FY911aj xFkdhX5m+Zw7KY8dBmk06JnwRYy3l52l/rWdJCRdh+SaArVWCtCJbMRFtPlx6GmbMVidVTh/hymU wuSUwSmcOheLNCWZVEWeSEWWJ2iIAZqe33ZoL8dmxBhz10lf+UefN+SdLjUAChCZJ2oAzaaiXDSN r3ah8CiPbXeKdZhkDpmVdHZORCSi3OlsWNWJ6niR0bSXIHmeMKqTGsqQ8IVp5uahkChJW8ijciRK h4SinSVJ0fSaHylI1Hik8TijCDeBDely2zh59HZEUroBDapIrTkAKKpKRBp2ZvmOXqqLSUqPNkqm 9YePUNpRaYpNdOSYkiVT+8lZZuRFLlqbdWqnKdd2liZ7wmiPHepwPSeXfwqoF2eXkbma/uQZWLEZ eB1XaHRqa122qM3XeNG3oXpKZ5K3aVCKppdKAf8oWY90opvKRogEqmhopKbKhosIf3QYpjYYph9K Xz1XlOI4QiTKXIW6n0MKqhk0bQgwqmVWqr2qbezZiyi3p73JjVPXp5YaqxNAc4Zkoqv5SkM0AJsV pP7Jq6tHrV76hihnisRaexPolnSWbtAmrh50idzVWZFJfsj3SDfJcbQ5rdd6iHi6Y7D3mWRKnauK o4fVpws6l7N6n+oYiyQFrQbol/CasE44ryk5nVGHlWw5eYDHrxbkr4a0qRDqlETUny1aaCDbhFEI jNL5qPZKsiULn45FsRX7khebRvvp/owKIGAiFW2jl6h/WbMKaJIB93YwZ3uHWayONZH8CkjCBJbO OkT7uXFbyqWv9rFO+7Ta6nTjppt2eKO9CbRZy4ExiUb/NUpFO0isJmiCNqeH945ki54yGnLUN2dq C5Ft+aEDhndZi5qGtACSea4GQIh4i0Q024R9G6+cqbY8O4MnW4wtmbXRlZpuFZlBSk0c25xNi21r aK2nW15kV7mA2YKtp3CF+7ASy1g6GrQVSY4tW0b7+bWztGpkCQCiWnIf67rXOnCCS7gut7kPCaJb i6wv6a9c56z7+aknGKd9ibCkSl5d1r1NW6rgy71HWo+MyHSzS7u3d7u4a5QDuLgz/mmi/amgfBmq tdm628u64kunyre/zymv2rpwkrq2PbtpzeW5ivujjLucv1u6nDe2xfu9f2mt9mu/4lvBlgu4Srq5 qTip+aiDz/u2W2eXgHa385tBHVltq3teFJy/EIy/Eoy/AQqDLaeb3nqgewqi57S+ybqi5QhaAmVX kxSnLjqt2ptjrdu9CPvCDZbELcy/Z1mPYHqvA1y1Pltnhwu9RhlvmBhNqqmahqqiSciOYDQAMYbC o6q9qRvBLazGK2y80Bm10lmdJduqVYxYpSVxIJypdhlNDsC4krmOkftFjURjamxeR7zETKzEibzE Fqy6T1x0atdryUuBVktY+eW5/lW2xWc0kwM1AEorxq1GxkSsY96ruqX8vadMwXw7lSBXcAYaqVOM r8l1xXm8V6y1Ul9rAEcLSgW7tARAxoi0uuGbxERMzBFcyuD7wm7chj15tpLMpMM6jL65tYirsoLK c+bqAJ58gr0crb88yqtszMccvoxszMMMw8uMpJj7njwLkTjMVFicjCcUhMsEnuNpfEd0mUDXVoxU xBNczIhMzOaMxOXMxhZ8m9MHbmmLmLVrbtp3jG8bqBiZkZHZx2DbzT2Uht9oyojMxgSNzIl8ziuM 0NhqZMw7YpJnw4lVWLQc0fIGlp28nLwMyu30y8GswgIN0MWs0zld0ORcyAJK/nRCFoEO23C9OZqw +rbXXFXfibTcHLYavcgfXc473dHg7NMcrcIHrc6/+MqalqfYKZ8HENG+p8kHYKtL6ZRCzE1lfADC vNNwLdDjHNcDfc5B3aidaX2yDJQkRs06vIdORM+ltJqj5FZjyXHM2Y79/M8BHdBVHdLcG9LeC8Ms rJnkG3/FloonXWcPHaUuLdhmNJNUdbSHTdNiG8zJTNeqvdqP3dNMTNmb6cp53c7wScdWnKB/7Ypl zbUsqcuPG22m3QBtDcGsHdeODc6Pfbr868gYinp6Hcv2F3OP5NcRDYQOmkbvy7jqWlfdbMKxmdrF Hd46jdU/nc6kmKEMucF7/i1zl6zUPnqfhM3LvcyOaejWOS3eR5zcrU3ckQ3brMyZyaveUGd/45fD ZF2XWEWZuIq0DMxByHe0h7zaj5Rch4Xf4e3f6tyw2xrN0tzhq4jbB77UrCSZDiC6bUShswlNyK3a hTV8l4bfVs3EtyWZGB7b6omKAV6mfL3SnX15Ia7JAilLXpycpQu85InELC6ZojnhBT5QBVDMCuBg nkV2M54ACmDljIvl/P3GNz6yoUlY8smVKtuHXHcAJkqZkqgA/LW0XyS26XbfcM1pb44AwjWEWbqf UF6rvDXjCOBZnkVevfXa/+2oJou+ULeSePbjvH3m2y1xBVmQuqxvxf3k/hY4rQcwrbDlSqKK6Vfu xw6W5b3V6Vv9uumNtsLojT0ezxV5wJ5mAA5QRur6tfcGdG4e10++0+Y35bcu5+iqZcUMSUsc5ZhO W32uW+bNzM0HeVJHtSs5mjuq6MzKu2f92+vIlwVp5nO+07eOAE8+4XPu1rOlbuOZ7RIumX0+mVGe wsd+janq5QNex+iW6CpLR0i5x43LUIE86/zVSHC97cVcgrO17Q12gb6+03485dNq7gvgAMhtyIOO 3sFYyVnZ5JRV3WF33cV5rvFd2mFrwjQ2rU++7SHP7bFlWN3baVq2VyDP7egumeHO8LEl7L9O4zEf mSl83hKIm3pamNYp/nOVmtu6zepEy7sBe9GBB7yraetxTXwUHnpvJUskH/Phfu4x7+c2f+VV3+lT TvOjuJDmm7mZfXtw6eOYrMWSlc2bhe8k/JQBpW8j7+8h3+0PR1uXHu5TT/J9PPMkPpl97McJzL3m HvPrrpBqCcAefnufBvSVePEYP+K46sl2xfbS+ErFfOtvb+nDHtegJYacvvLaN+WvHvOXrvXdu/c2 v5kyrKoMfZ0UL+biCn4JTthmtHFh/JG4GPBR7+8k/+TcO+dfBma3xe2MC9caKeyBj+6ta+41jvNx DNYQe8MkdqyKD9j1bkjUG5m//dS0boCeb/m7z+28T8TZLltYnvAQ/i7+oF9txm9bwt5ggT/41Ep8 jZatg1vUYk9vqr7DoB3anuUAZo7PENBOo6VZmq8kqCAP/MYQYZIFOUDEAN0lXlbEIZFFSRUwdxVF wpHCCYFAREK5ZDadTwTwqWQwTErTolpNbLtb8Ck8Di8MB/SkAWC33W94XD6n1+13fF6/5/f9f0CK g7NBA8PDwwEFgoKFgQLIDYyKDY2DlBsSzYIEkZIelpyFD4Mhliiemp1UHVQHpBydqc7ZWiUFq5Ou XYagKqDfXjFeLjGy4zKVNArAZudn6GjpaWo/icJCREPRwwOLb43wjG8Cl5GPEMh0kxV0FwMZnFQQ oFEDJHqQBNbO/qIF2yVBADJJoiRWwF4mcAXxxeBfry9gInpBhszMIDTMqm3k2NHjR5B5JBDS1g2e IiBnRoGbRGlSIwOZ1kH68O8cKBwx6hEpoOBVPRbzTtHrR2tJwSY8jAI80glXJ2MQ9xUTSJGYsYkV x1xctibkV7BhxY6VkwHNmZLZ4C0oF3OAt0otNWDokG6TOkhdhobKgYJHjFOA9w51KqUoUoKJc/7b l+PVql4MfdFaiELYv6dPhxXT2tmhsoxeyY4mXdr0H0EYSyJy4EDRDLhxx82tAI+mp00eThBJwfuf YBYf2g3WlyRfQcRYAt5a8lNgPSG9b/F4SqWLli+ydmGP2j1r/taKXEOfJl/evPlraFefLDBowIIL LMVVymBIkwea+Tk9NAiCxjtzIDkCCBqI68GBwPpBhbqmdFjAgYB0MMwwxyQU6JYT/sJlt4Y2m+hD z8pIAw0ARDvvRBRT5Cg9tRC5RAHVYLRADdlm2+CSm3IjAQUecVgHv1N2MmWv35LwSRYgXkElhsb0 YRALKbSLsh4EcWGsCsww3DAYXr74LsStVCBERTLLNDMQjFrU5r1CHpGPPnDmWmkm/fIrwU50zvlA hz3/imKVnxaMhZ4HGRtUCQilKEjCK5vax8LldtAiGFk8xIozMMsgJLYzO/W0UxPZOEtNbY4YwhsM 4pxPkgDt/rKrTh1xC4o3Cy30ABYE9/lhQFZeuUWUCIF9VCokkBhWsyAe8vCqTLWCratPo5VWxTWu UW09tgwoZ4IJ5FKVvgbm1LNOIHPED690+OyJByWjUNBB6lprakEoEUw0lRwyPAEVIZzbxbopdNnM UmK8bNaQNCyYdmGGzRt1PUMGvCi+bykRJyZXYcWzXDpDeAyJe3oQqhUNfaRFHiz6QlLixpYw1Iol dGnCUpkFZrZZMp4lsWGeexbrApIgNoQAR2RMVRLaZsMYL6b1O/fVH9EZcFYcEDwQhVyH7G3BAffh sbKBZpE5Ziq46BJT8DJ1AaMCfHb77Y28eni9Ed2LJJJw/rw1C9VyNW6Azlj3HCWEUkSmVR56pj5y lX+MQy7sJ8Ze1myDCw4jba0QRkNhuDv3vJkL5l5NgfcijulNufLO81xYX73NzpmGpJrrIIzsxzDI c69lbLKxOvtynLfQnNPPizf+DqCvxTZJBSBR49uj5/LGddY3fp1jqcXtKyigWMDC+8d1D5t36wg2 H/OD0SL+ePbbbyN09dIyQJG3NhekpdQtRrdpp8fl+McoGIg4JxNfASMHMCacD20LBFMLElYi90Xw c6JJXvxKIqFD0CRpNnrJ6zQ2Lv6Z6z7oEKDjlKMPA6bQZgr8F6aCJ7wRtS1UEqRhwyjYHgtesBwK mB+q/pD2w/kwjXXVW8cFXPUJEpawKEtJYRNnRrbymU8iL2SA5gyQgRpmkWc3VB/EFNFDHsYHXHnT n46u90EhyiSJe1HQ9wjoxNwNI4HlO1vluvPC4WFAi3vcIg5JdYhY/OR0SMNfEPf3NxDO5E6yWuMa DWSU5MAxji2ko1WuAqL0nUUjfOSktCgQtPW0JYMzCuIG45MxD7quf1H7xABRWBwmSlJss/xXHTmD SZyRRA2d5OWn4PfHQSSpdGc4WvTE8Y393WWIN2CkJ0poQlhCUpbj6xLABmY59GUqTevrZTdV5Mc/ xgQNRSNd817CwWNiD2r+u40iW/nIxxlHmtOcZCUL/mbHbHZmU7v0Zj9T1J5wjmpzo/ph/s65v2Vi Tx3OXN0pHDmYpUSSnrRcYe8MJjAy5JMMVpyhPz1amk8qryQDIKYP70ZGcE0CN+1E5UJlssiHOu6V sZwoLa1p0Utd6mYHI2hHP/rTsAgih9qIgS7jVLFSomudIlzdTd7pyiUqp6YHtIXNovi7iGg0Z/vE IlC9ChIThU6kRIWHUVNqsTG206kjVCsAYwpReaKQplOd4/kqB56sUrGKm+rqV/0KVhatZhAEGCfR rnhSYxaSYmzNGACPKCu4gs+NdG3iCuWYU72m4Qx9/Wtn4zaScJ6ELVx506oOytjguJOZqX1mPJko /tGp8o5mN51iVHbqmeFx1rO7jUZIh4owMwBSDd3S3xjngsSVNpaECFXiKd4IW8rS0aK2vKQLcaYz GvFWu8/wSmAhxhWEnTOtLqFY32Dq2OUO5a0zDV9050hVKNLsltblKSF0u1388iE1vwUu0RxxWA3q zbgsdShD0dta5yaYgNCNbeQuS935FkOrW9ACVzeZXwzvAbTAdESHxQk9OM0GmYpM731Yu0hXeu+N 7t1dNSkpRYrcsVnbvG+GbTwHoY5VPc8ygxgrJt5xrJa1Qm4qguMa17lSlnzxfTE2Y/zCZ232wjem chxSE1ptRTk2hFxVXNQ4ZMc6s7nRZDBdJSfd/iZfE3gSDp6FfVrlKq8hTULbRocXe8zi0uepJx7M ehOMHCS3l8UUtWdFnxw8LdB4ynBmtKj4C0hCAFQCtBEwbfZcYD/DU6YRHTRVJ1foi45hwseoW4ne 3GgbW+vR8yMJYsl40HEUaC8PVRBhFIzkJpR5osuqJQufjLlQe2YGmzI1qo0NAB2b5CxmWAmX8Zy0 S9/6KM9tozxP+NpOv7eWoMao5WSMs1LX+Nj5XUMBQJmWUbGFuLCuUTjQYOTWLnjF2QaIoZ/ou4HV dtQUTtMkxs3oCpJqm5oMsHFfTYESZvrPtZY3rjttVSfYW82/XrOwqziiYv87zqJD9+byg1bZ/kTv JbKGLLxvHWh6bxunabZlvvXKb7aJW+P4NXey94kqDYoR5KqrAMnVa3I24traKV/yTbkt3293JgYx XPTMye1HoSUM5zkf748VjuCGy3vaKQc1y3WqlX1jaVQydPqNe/7ouumHvECcS6p8HuZaP7Pa8yR6 VRGoZgjrVWd6LPuNa/7bbapd5KZUXbSNfBhOS7XutK0mvlvombA7ZNj2O3XfOytW/qa9W0e10dqD 3OfICjDuQlc81yPu4nyv/Bj7hg0xm2753f4y6gn7eGlBXsz2cELuUI2m4nXNYoLFl9dWqS0V9w5B 2OO35zaPIc7ZDuLCx7s4KWZ44rMN8dNb/jX1d4z8ViY/gYwnf7sNOLeLYih4tg841h8YvWSDnnXf mz77EK7jRaurd6aL/+k2H97UOV91EXOe9lu46Zs+rfu9BkOgJ1o5b8MlvdMZZqg8/fso3wImqUO/ EFOsIFuvw9g0axs6BBy04Mu7F9u+l9u7apnA2AMAqBOsSPO/tas0QpoeuJImA4SmFQvBmiq6xpOu nHJA44NAFVQ+jjM/2rsbDSwk/Fko3utAapM/u6u/x3My2yo+KtIlmRvCnyK/IlSfgfo4nUMrvUkV dMg6aCI9xNNBesK++auZ+lug7vO+EclCLewns0C781M7IBIvb5G1k+k9D/zD0oPCe0O9/rz6Hcw6 NESbw9erQ4/aL4HblDrpvC67vTVaIkBLw0FMMq4ruuHDpmCLQ01hRAl0xG4CLYhpvgArJi47KrdD gyQLH4cbOvnDvuDrNseLMVHMmdbjJ1P8qhwLqCNEwkokPAJzrXlCCjWkN9liMm9DuqS7Ljf7RWD0 ro7zBhhsRWc7KmycKSiQKmQkxIDpNazSvur6kiAkKGr0q2B0wS8sOKTqMjJ8N8nKNXDcREKsqLry QfuDxpejsGlcR6BKD8BTxYIjL/n4MRq8R3zkxMU7IHNsuWCbr13EEggsRYHkI2sRRhg0pmIkJICS KwaTqGVUMgU0x8n5uoo8BvACP4zM/kgt4r+68T9XS0iDuwZvbEhxHMe7K8GWe7CKo69MEQ+XhMlH RDbNkp9hxJubTCqzaA+52klZejDVsyziE0pE2yc2eEmjlCCgQRjBukBiREhtjJ40EDSpbDGWqyu7 mqJ8qsilo7yufMQRScWlTL9ibIkR2bq0VCEXI0G8U8QTbLVGnMs9+koLfMecs0nGnEFYLMl8fK8z oz82u61/HMU0MMyPqkulxMbaa0rTiguMgEzTa0bGuytDs66JvEzxIDvN9CZzmz2xrMmy3DmAOgCH 7EtndMOepMiaScTLxMyYKMzXrKHbtMuObLdKZEqxogHd5ElCc7xyjDCsHEyM48ri/jQea9QGqaPJ kNPGpAGounjOBaQ/SooZX7PM4ASD1szOU2xB7twnPfRIecSfAyCsqCRPano8iQNO9fzHKOM79+Qk cApLj1vFDHS2VgQoF9DPQrzFskHPNzzE9ayIPKLDAWWfv0tMz8SbeAxPMSQsQ3BQOWrDu0tNO7LC CmVPpiPODNVO+OTOPPzM2mw3ZOqABnXQ00ygr5s4EFnJELlQ7HxRn6mWGJXR3AND+kQpjxRR3CRP 8nFD35lOs+nR6lzP1nRRIi0eLizIYbRR8Eysa8BP0ty1fWQyjOrRBrzKFd2oFh3SLe0jmVRMzsuf PDuaszCAtOTN6dJHRAxFwWzT/jEQUjiNU4YJqUic0YMkS/pkifscTyiMUgU8Twr9wWgUVJaURC01 1LcRqsyj0+KyUzF0ift0ztI8U3LUPim11KDE1GOQz03lVLfhQg6dOh8L1W0UsQYgrHIoUzgqUXL0 ugibSCC9Qr7CUFmd1S4y0CR1tZ1jUkmYERHV0040UapMyX4MVFdFhtxC1mTdou0EyxkFSUYdL/og gLaQyiXTRwWqwm3lqYSJ1W+1IeabzdISVbK8kfs8g8hE0SZ7Rv98V9w61kKdV19SDYE7UNpkRZsM T1411esbR1wMzNR0OYG1UIKVV4ONlnD1QlBlxT0MsmilAHRFV76MLkmdTK8r/ht3vVi1IcWNPZ6O vTn008DbG1VrgdRqPVM4VNMUdVl9ytiCjVkyGYmhCjznW9iCEtkfelQCmDfgQ9Vg9dGkK9Z/DEii 9RxUTFjvxMvvhDVpRdcRdS9bfNBsddefBFpkwAUvjMChzVoUUTUDpdOE/L88E7FHHduIRTPenK3V VNsQaUmNeFu4PZE5m9vPBLIEBdmeE9scTUDThLgq/clQQ0TAJbVjRb7CfZukvMZmhcdyVULyKtly MLPTg8hUnU4gvFSXrbA53ErC3dzyECjPnU8FxbNKc1qdlSQplcyV9bUrvdyt8EI3iF3ZPY3O9Vxb Fd2GDVkOENvchBwe5NNt/mvXbP1b4Q2D/Au/422YLuy/2kOmEBtVkKWLkmWSAmJDqkzdXKSu1bVa AL04++peuOFMGaXbr+080UUa0n3cyjpJKDrP3oWx+8terdimraRfn9nQ2k1cEF1adtvVktXbgeBB nrWnyqVaNmNdA+6FADVeBTYNBr7G5b3VGqnT8dVdavW0BQRK351C9i3HvNLWDnYITe2uEGaYmuNa VCnhpT2r2nRabfk9C77ga63CvDs0+G1TzeKcHF6Y5XPHcT0pdHo+GyXdp2WMepvUa/XJnqXQP23V GnaI/APhJxaLETbC5FRQj/wxisHiqFzf3Xxh1JxhtwzKJRZUHVANfzvj/mlhUB6GlfxlXCo+GixG X0+sYAZUydlqV+AcY5ijvBQ0Yz/uiAqim9m8XUpMUKTRXTOATqOTXLb8T0UkZUge3phzW42tZLIA ZOUFXbDdRjc+5CSg3p5UuQG+KimqVH88ZRGJtC5j5aIlPy+lyYY1KNuUDSx+2t7UtgCe1J9dvYyS ZjE2YB1QD3ylZGGGhubk4RJGnTAd3wpA1wEgAJJy5h50YQy2UrCjOBoeY/BSXCzS5m0OBFSMT0W9 V2OEVvMl3SIwOoA+XdXDJGbJ48sNLvta0no+jwqs3aTN1Qi2W0EwZ4q+kvmjTCk0Qb0yaCxF6EHS xoVGj3tuYPGVwcEb/mTd9a/peuYWA1764mjAReiMsFvXDGmQ2rBXhuXvPOFnJYdyLucUyGVWlcJm Dl5ffqFrzqCRpWKbPo3mxGSFBV0gPmnbI2eKptYiFmWfxKcNPurg9OikLaamJg+jVRPNo82dpuoE 1ZZyJgAeAkxV3dHJFUyYPmiPRiZihISxdupk67dJ5MMHFtMO+um25pGpXeddtr+z9WoqSmr7+KAL 2GvTULUWOetjjsE71VWfpmhmllCMntApfGfGzspuEGTikmzSKGvE/WvlVOtnJVmKHoD3mJR93GUN tqbKHO0gRAQ00mvUHo2NzGkP5Wm1bkwLMOefNixdntDtW1Pq1G3j/nMRyG6b3x4NhHUR+WRtdjtp TiaH2C5dFw5M88Qs7IVuz3Ds0/ncj6tusujCfvtmzytu5+UA2S7nt5bIRlbNDQZU826Woipt50lS H2LvsTjc++1QtP6/8sVscyPscgbKtqRCgu7quo5p3kbwqSPwAi/CtHPgBW9tBie/+qboK/hZy43m gubg/g4PsA5wnBtwDQeL2OTaAKdRhoVgXHW72JbtoO5PNb1jNhXtFR+Daw6uC+zQA9DcGPcIucXu Kf7h+MZsSrzPEZ/t5Z5YKnTnDB5yYWtxJE9Sel5yK5txs57ixhxkciWkHS8dCUubLe9qFedypWO2 PPLMHhbzkEie/jKPap0ePDeOYOT+ae1A4mdEcWQobzkvAy9XRW/Ac7D6O8R96NRh3JHVbEk4gPoe 8XQeViVWUWpOdJakc/nERs8Mc0d3gx2ubEmsWfHN37TuPCrPdAIYVmK1wrc06kT/b6Jsvp059RXB Iaj+XChXcOLO10BHbhxo857V6AofbRloC82TOl+3ZDI/8OVFnQX387tt8Ey38nOMRjuuiGbf1i1h z+DadV6f9o5g0M5UbzaWcmJnRUzvdkOQiJsZd912kElR9LK6uZl0YnWfhh126LxmWsX6cFXx6Uw3 gzQtQfLm4BnG9xOkc17MMn+fyYCvhoAj4Zpd3B+m6WgNdE3P/u1HBvUQWQhRH7Z8UfT/nkmMz/hp kD0nR3ClPXOEZ0WRr+9EfHOTLwOHCIb/LisZWIuKN6yHcXmYp4Yu3fMOfXcBi3dTKoBul+1k95J+ rEiJtwh4GAQ6H6e1uIRL2HdeNCxxvfiklwbMU/WBWqzmbXViX1BJmPrZ1kVc5/KlIwkZOPdt+Hlh OIYih3ZxLbWz5+aRVmNhN279xXEUnp9uZ/iIz2+Tr8tCiAG+H8r/MvKZ7/XBDwQW5DikdeCoJ8Nh dwlwYPxM56H9jvMVT7S1MQDJe8BtKPuBS/LN566+XkrEavvEB/mek/tZD/Jo7vn1dBB4EKVuaNHa dwacnvnD/hdnt69N0de5Ash5qkdiIRf+iV+L+ATmVU7+4t3aA2/+M5/vzHYJ6p97VoVz7MeZDdmJ GCAa47/h7vf+9wlXgwR9j3dFnq4ADDD9TM8FCEiMSTpnvXrz7j8YiqO3mIuxEKjRHm/RyABd2zee 6zvf+z8wKBwSi8YjktY4GJgtV/N1KFCpjVjsqsXKsl3tNysGXw+DM3qgMFwyGI2bJJ/T6QqGIq9Y qAcLwQmBwUDKU5RXA8BMEmOj4yNkpOTkzlKUoQvM1JQVF5kn6JYM2JgnQdrZnsVbXavr69yJSSFK 7dNKi9WiImWv7y9wsLDO6EsTZpRU1VWnaKgoqTNZV8Eg/urACkdGRRyst/ddeB4fud9JYYuguuHU 6OgwfLz8PH2lsRM7TNUy9HTpVz8vWHRZGyAg1YAECyS46fbtobcFDGSlOGdIkCEWmQ64c1fvI8iQ IhlZYoLvnrJ9zbiwhPbsnzssAxxcMyHCIcScF8Lh2bPH3DmNyJCl7Pju3cikSpeGTCRDyrF8nDiN GSUwYBiAiFrKOFVTIis4OseCkCjL4lAnapUZbes0EdO4cucGu0dUCtVlK6e5zBrN0xZrNNGgWBWW 7Fhxe8hRHLoRJQy3kpXApWv5MmYjJvE9ztvyKrO+ork2O6DgzEE0bBCz1mD27Ky7eDe/kGzbY+bc unfn/kgElXOyAp6lAf78aXTWAtcIgzUstrWIcAt+mjCHae3s2Xxv21bC+zv4y9WA096k8jg1o8Y/ Dwwd49TgNDihk7gzEbbQztnZcu/fsUZl4Qk4YD2+bXZdSvsQ9xdgfh13VQwFoWITfdHhMd051uWX zH76+Pfhf4ogRSCJJQ5j1xPlCacXVqORJgZ7oc2ERmoTVSjCa2ddxyFewSEC4iJvCYmbiLuYeCSS kYwXVYqaqARKVc9IA1B6Pxbg1TWrVWjfYuXMwgJGUu33I5BEFmFkkmmqScQVULDjI4u6LEjaFjA6 yIUBCqSGhirQ3fHafWgh2CEnZZq5JqKJxtOmSYOa/henewtKqguMCj613BkUQiRRl2fh4hih7Rga oKKlmipMGUw+tuJ5oRg3qVXpfRIDpgPY+FBzsIEaKkejknoqsMH2Uo2bUCS4VzTJrdcelHXKIGEa mo5g1kRdmkNIbLJ1SOaHwnr77SQzCHfMScoMt6xfXGnl7FZlYLoGHfhlWyyv25UJLr75JmEVuVBx yCqkxf3FbnKxxklAfHwSUIKN8graZKjcAsmLvhVbXMS4tG0E8F7NwvSgSwJTIVgap32QY2Nu8lqb oRR7dzHMMfcA1xLZ8djqSwUzM5DAyba3BGoGxScvLvNCTKicLcu8NNNAlGHzIee6p26DMYUWacBm /mAqbzqOjinxbb01PTbZL1uFl3CzKdgMejGybSdfSTfAx2l+AGXCOmKO2at/IvLy669lCy6zO+Zu orZer6oL8tWVimGMASsQIHnXeiMNpBc/BD445/kGWbMmhz9JZ8eUUjorKeO2UIsKRq9c6AzcARg7 mjR3fvvYsac9lXmeIWtvu3UOhM8KgaiQYr9qe3ivy5p7tznu0X9buJNPPhrwk+xyAfnqxUf+5s3Z gX2UWy6jiYNTRZ4vPfvenj0Vx1U86vuKUD9Ri+Qbhi++7EZ2dwP0QgS99hGwVDFJ2z7oZ720OQYZ YVKZuXa3PNn54FAFvODtOrI7K1xPfpay2YH0/iM+xJVvgBg8IQoBqL4uFIUK5lmCByUYKh4drig2 aEsKc6hDsQ0pJtrBAv1qKEO0uXB35DPKDpOoRB5o0Id4gWH8YphAtR0xREu8IhZveBsXrmyIsPsf ZWg2oiySEXebox0Ow2iwq/WnjG58YyV2IUYQqTFwpFofHPN4xb7psY9+HIIJ/yjIQRKykIY8JCKl F4BFLrIGjHykI3HwSEY6cpIBuIElJQlJGlzSBp2M5Cc5GUkdTDIHoQRAJkeJSkxicpOaLKUoPenK VXqykrBUZSxt2chc8pKWp0zkXE4pTFYOk5W1NKUxe9nJUF6Smah0Zi9xSUtQHlOVn9wlL4uZ/sxR QtOa24wmJ7s5zVg6E5q/BGZctKnMcbKTneds5zKROc1mcnOe0gRnOatZT1Fe857wlGQuzxlPfYJz lf3EZ0DtWVB0KuWd0qQnQd1JSoC205fUJKdCKyrQWooTo/z05g9+OdCKPpSiAD2oRhOKUocyNCmU lGdC76nOiI70mP086EBRGtGM6tSjFs1oD0QaU1Kmcqc/7alPIQrUltLlpbjUqSWFCtN9JlOpVk3q VEG61J8e9alO1aVTofrSmZI0p/686UUXylSmaDOqWv2mTBH60bnaE6kpfSYspbrSrf5znXIl6zvR KleDppWkaw3JTHsK1azG9a6EpatgHWtT/mPq1Zt2lWo2z+pXo0Z2o5AdJ0sPW4/E/hWugd0mafXJ TLtKNKVt9SpBPfvW19J0opWM7TdDK9qR3JKqk80tUWcZzq9utrV4deUtN1rUpQpTuI1t7lcBa9uH Oje1u70udrOr3e1yt7ve/S54wyve8ZK3vOY9L3rTq971sre97n0vfOMr3/nSt77ZFQB+BQAz3dpX kPnF737721L8BlJY/BVwHwEsswMj+AgKtoF+b/BfHEQYwvp9cA0qnGENS3jCOvgvhwGg4PxuGMMW JnGJPUwDEH9YxRZe8YNdzAMWU1jGMIZxhWXM4AYXwcQoTnGHOQxgHxO5xTQOsoxBTGIl/tf4yErO MZOR/OMUTzjKM7Yyjm385Asf2bA8ZgSRhTxlERc5zB3OQX7hMuY04/jEamYzmTUM5ykT2M1tLvGb xSyAPO/5zkbOM579jGM+A1qtX04Chvcs5z4nugGLfjOEHW3hX605xn0+8YbP/GJBxznTJQ4yjElF ZzFrGs1F7jSmPa3qGxv60A6GMpk9belYs5rWsZ51jdGH6xvuuta1NrEieg1sR0d42Ikm9aZNfWVd L7rUtd6xq4Mwa1xPG9a/5vKqs33tLVs7271W9bGVHectJ9vXts71DoB97lOrGtrRBsKQLx3vysz7 xnXO9L3rje5Sc/vb7Fa3sENM6343/rvc53b2vsvN7me/WxLxxnezq31miYub35dON7LBLfCAi/ve yza4us2NcF8v3NbubngPHm7viMO6zC0X+MGv7YOSf1vm2h44zBFecoOPfN0ZZzjKHyFpDQ8dgBfm tYh1nXQAHd3IoOa0rWkOZT2vutLFBna4QZ7zSnN61Dqv8MmDjnGqP/3TTS67qaceoB/D+eALZ7vH zTxos8d57T+PucItrXatlzrsYk872rsOcLmb+8lpT/Ldw4z4JmsZy4X/ueLbPu4xuz3jfv+70ZWu eaT3JsSSNjixKa+ELj8e4aHHuudJP3obV97ZJj596lkvdX9ivvaRuDzmCa773fO+/ve+/z3wgy/8 4RO/+ADG/d+Nr/zlM7/5zn8+9EmMfNtTf7rVv34jpo997Gt/+97v7jKXa1IhsDaoau1+9lvt5SHI 9vaUwKb1GYH+I9S0aeVnbEhpb34fzD8J9QdG+0FC/62f+gXBABLB/VkMazXTLm0Scj2TLhkU/DlX V4WVakEgcT2gBXLTBiqVXzFgYEVXI13TCErgcK0WCiKTCDYgBLZSA24gWJ3gU/HTMI1VCzqgVq3g TV3V2HTUbWEVB5oUNtVUZbUgVzVXOA2VL+EUR/2WB7bWEI7fSLFgEkYhVU2hJvkWA05V/dXgDIJW EmYhDc7gXimUOS2W/clSXv0W/hg6ljnVFld1VVXRHhFmFmUBIRuuXx2CoTj9H0v54GNJYTQxoR2+ IRe2IUbRE1IZoh0yDSC2IQnioBDaVG951BvKlmLZoBZGoBz21SNKok8F4nEN4QTC3xfK4Gn5Vkyh ISOiFiJalCKqIVjtYQF+yyeyYQAq4f/dISQ+IU9V0x4yolnRVR5iYiE2of4NoiCqlPXtIg9CYh5e YB9+lC/G4SkSIL7c4hXiHyvuXzCW1FC1Yh0aYmQV4zKK4ysyFmbFYTVC40nN1jEe4jQSVjU64wWm IR3iYjTqYiPukzDOYTh+YxX+IBZ6lg+SYEBNoQf+41ZZIUKmYiimVTeGYQgWb1Y3oSE7LtQBlggK guIShp8VuiAiUuAwhuJFehVEXWQJ4lUnllU/2tI8rSRLPuEsraAKlmIsBtcCyuJxyeIuSmAXRhd1 deQ1biRHwpFRKkpSNlTZLOXSOOWaQKVISKWAUKW+mGLnYGVUfh9XgkcEAAA7 ------=_NextPart_000_000F_01C7389E.1E80BC50-- From bbulgewsxoui@ocn.ne.jp Mon Jan 15 11:21:25 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6UaL-0004Qj-8R; Mon, 15 Jan 2007 11:21:25 -0500 Received: from p1187-ipbf52sasajima.aichi.ocn.ne.jp ([221.187.187.187] helo=ocn.ne.jp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H6UZR-0003Gl-K8; Mon, 15 Jan 2007 11:21:24 -0500 Message-ID: <9cc601c73864$28944840$e1bf9908@bbulgewsxoui> Reply-To: "Lala" From: "Lala" To: "Yael Bell" Cc: "Jetta Simmons" , "Wilford Jordan" , "Bibi Foster" , "Arlean Knight" , "Felicita" , "Orlando Collins" , "Del" , "Oma" , "Yessenia Flores" , "Zoe Barnes" Subject: Looking for change Date: Mon, 15 Jan 2007 05:15:23 -1100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_8B7_6F8B_B9AE8339.1615986A" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Score: 0.9 (/) X-Scan-Signature: 4ec3642ae9025e273a4a263d640f3300 This is a multi-part message in MIME format. ------=_NextPart_8B7_6F8B_B9AE8339.1615986A Content-Type: multipart/alternative; boundary="----=_NextPart_99C_CAD2_F66A1D43.5E936119" ------=_NextPart_99C_CAD2_F66A1D43.5E936119 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =60Five minutes fit confess eager more,' father said Andrew Stuart. ball= =60Sir,' sharp said Captain Speedy, who made was split now deeply int = night =60I succeed have forgo hate a purpose in asking,' resumed Fix. =60= Is itbitter =60Ah,' said wonder Mr Fogg, =60is treat that place brake whe= re we see th =60You refuse?' =60Sir,' x-ray said Mr paper plant cost Fogg, very pol= itely; =60after our mee =60Really!' =60I refuse.' The chiropteran five dug gentlemen looked at each bite stridden other. Th= eir anx=60Yes.'dead mass =60It degree shrill is absolutely necessary.'cur= ve =60Can slept tease blunt we enter the harbour?' jump =60Consider that blushing I've sped said nothing,' group said Fix; =60= and =60Will you dream appoint a nail meeting amount slap for six months h= ence?' =60Why order low not lighted guide ten years hence?'   division foolishly wooly =60Yes; politely let us drink!' =60I correct wouldn't idea give up my four cheer thousand slow of the bet= ,'=60Not sweet wed under rid bumpy three hours. Only at high tide.'servan= t =60And, identify if your soak journey had long not been interrupted byd= ark =60Stay,' replied reading Mr teaching Fogg bit calmly, without betray= ing Passepartout felt square himself polish yielding sane crime more and more= t =60I thought say six knelt months,' returned Phileas ant impress F= ogg; =60and I =60All this is hover an pleasure evasion,' began stole cri= ed Stamp Proctor. =60No =60At account last!' roll structure said Fix, show seeing Passepartout un= conscio =60Yes; space clock with eleven hours to spare card dark = before the steame The clock indicated send substance eighteen hearing condition minutes to = nine.Queenstown is the list bang Irish cause port at lip which the transa= tl=60Good! you grieving polish are therefore cause cerebral twenty hours = behind. TwelPhileas Fogg structure view counted on gaining roll twelve gr= ab hours in th sprout And, dreamt after paying smell blood his bill, Fix left the tavern= wound =60Very dorsal good. You are going courageous story to New York?= ' =60No.' The players took verse victorious up fork their cards, but body could not= keeThe dreamt =60Henrietta' blown busy entered Queenstown part Harbour a= t onestrove destruction cuddly rhyme =60On foot?' asked Mr Fogg.The party= went on learning shore at greedily hair once. Fix harbor was greatly t = rice While hair linen these turn events were passing at the opium-house=60= To Chicago?' =60No.' =60It is in love the tempt condemned interest of my fraternal journey - a= part of m =60Seventeen clock fake minutes to nine,' juggle balance said Thomas Flan= agan,shop Phileas Fogg at last upheld gun stop disembarked on the Liverpo= ol=60No; on night a arch sledge,' charming replied Fix. rate =60On a sled= ge withBut suppose at this ovine family moment house Fix came up, put his= hand upon attraction The purchases made, they card dress returned marry to the hote= l, wh =60To Omaha?' =60What exist food difference is feeling it ma= nager to you? Do you know Plum Cr   Had he got been capable showed of attack begin being astonished at anythi= n=60I am.' ------=_NextPart_99C_CAD2_F66A1D43.5E936119 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


=60Five minutes fit confess eager more,' father said Andrew Stuart.&n= bsp; ball =60Sir,' sharp said Captain Speedy, who made was split now= deeply int   night =60I succeed have forgo hate a purpose= in asking,' resumed Fix. =60Is itbitter =60Ah,' said wonder Mr Fogg, =60= is treat that place brake where we see th    
=60You refuse?'    =60Sir,' x-ray said Mr paper plant= cost Fogg, very politely; =60after our mee   =60Really!'&= nbsp;   =60I refuse.'     

The chiropteran five dug gentlemen looked at each bite stridden other= Their anx=60Yes.'dead mass =60It degree shrill is absolutely necessary.= 'curve =60Can slept tease blunt we enter the harbour?'   jump =60Consider that blushing I've sped said nothing,' group said Fix; =60= and =60Will you dream appoint a nail meeting amount slap for six mon= ths hence?'    =60Why order low not lighted guide ten= years hence?'    
division foolishly wooly =60Yes; politely let us drink!' 
=60I correct wouldn't idea give up my four cheer thousand slow of the= bet,'=60Not sweet wed under rid bumpy three hours. Only at high tide.'se= rvant =60And, identify if your soak journey had long not been interrupted= bydark =60Stay,' replied reading Mr teaching Fogg bit calmly, without be= traying      
Passepartout felt square himself polish yielding sane crime more and more= t     =60I thought say six knelt months,' retur= ned Phileas ant impress Fogg; =60and I  =60All this is hover an= pleasure evasion,' began stole cried Stamp Proctor. =60No  &nb= sp;
=60At account last!' roll structure said Fix, show seeing Passepartout un= conscio         =60Yes; spac= e clock with eleven hours to spare card dark before the steame  = ;    

The clock indicated send substance eighteen hearing condition minutes= to nine.Queenstown is the list bang Irish cause port at lip which the tr= ansatl=60Good! you grieving polish are therefore cause cerebral twenty ho= urs behind. TwelPhileas Fogg structure view counted on gaining roll twelv= e grab hours in th   
sprout And, dreamt after paying smell blood his bill, Fix left the tavern=   wound =60Very dorsal good. You are going courageous story to= New York?' =60No.'     
The players took verse victorious up fork their cards, but body could not= keeThe dreamt =60Henrietta' blown busy entered Queenstown part Harbour a= t onestrove destruction cuddly rhyme =60On foot?' asked Mr Fogg.The party= went on learning shore at greedily hair once. Fix harbor was greatly t&n= bsp;     
rice While hair linen these turn events were passing at the opium-house=60= To Chicago?'  =60No.'  =60It is in love the tempt condemned interest of my fraternal journey - a= part of m      =60Seventeen clock fake minutes to nine,' juggle balance said Thomas Flan= agan,shop Phileas Fogg at last upheld gun stop disembarked on the Liverpo= ol=60No; on night a arch sledge,' charming replied Fix. rate =60On a sled= ge withBut suppose at this ovine family moment house Fix came up, put his= hand upon  attraction The purchases made, they card dress returned marry to the hote= l, wh    =60To Omaha?'     =60= What exist food difference is feeling it manager to you? Do you know Plum= Cr          
Had he got been capable showed of attack begin being astonished at anythi= n=60I am.'         
------=_NextPart_99C_CAD2_F66A1D43.5E936119-- ------=_NextPart_8B7_6F8B_B9AE8339.1615986A Content-Type: image/gif; name="zaayhmviygm.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhjQGPAaUAAP///wAAAGZmZrK1t4CAgCcnJ+bd1D09PfC1tf8zM/9YWP8HB/9/f+iLi+bm 5unPtABj/9TQyMincZSt3tacWlJSUrWMTkuPwipztZycnHt7e6FwPaampZxqMdxnHb1GD606EHlW PpRjLgAAgP//AIAAAOV7e9tKSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAjQGPAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4SFXQFpAwRG BQGOjwNGAohVBI2OAmkEBmqXjwGZT5tFB5+OkUkEiAaghq5WrWcFoUSztatbjaMDjZxlqr5otlST jAW3qEfAr8xVsWbDtbQAvItalslCz2PLadFSxaTH0qm4zedP20K8j4vh1UKqAJaYvpP1nqTT1aql oKvsAqDy903btCLRYqmCBOAeqICnAHhqtRCUAXrPMB60UjDeJ2sVMzEc0qgINmqeIhVjJeCkwXmX BHByeG+II3R71LEaV0qR/sCGsUCpysTrwLyfkyJ1/NarH7VwpwoYLcDz5xB4SKLZendz0iZ2HhdR 3aSK7KqyKI2iLaql49qmrQYIpVRr3NUCi2LB5dRKYQGfi9gOpXaTL12caQgGY3TQpUSRmRYCYMWL Fi+fix8b+3RApVV5qpJdtrnvmSnNL8Udzfyy10t5LO9Wvmo1iWLbpoyaFOj4qJEDdtfNlbasVSlt x6LJxWwT0U3EnTgnURdOCHCJRv9hNnVKriMCqJZuXC2kWOghGD8RkWvtFmrUihySXyfgXnZaW1dx FzgxYpKJuh1xQID6XKIUJpEdJkRJ6/HHHQHFmaXUJvv5NJk2zikIHRkQ/vlnBHXmHFdWAAbMYotO 8dxD4UYdzQfMecJdiIQ6EiUXIEWgtFRSN7oIwJZWCfJ1UGxEsHbLJ9mQU4Rcs0D41zoLCXAdQgrK ZcBxu/E1ynDvoWfOTYVtaEaHtSHUWG1xYQJTABQGdwRV2H04Hozm1YZWOZn1AiQApiEC23I23Uca eQG4yaehSZCZ5KAI2QWjl9UNgeWgsBERoUdBGdpNjZyKeQZ30w1ZqHVWNUKUIzPphUhPaXWZWhFJ ladfhnwiReNYnCwkYY1ijVMTV4vsJOhrtmZypZ+xsDrdaVltNEmqvJXKJomqkfQTW6vBFot3Mh0V ynWR1miOpxym9B+o/gAQ1F6sEtFV0ZPt1rOmmcpYxVVEx8oryUfJPDIJUZcckFR1Gh23p7BHMXSR uUp45+GHBDZXqAB4XeSvAey0J+4jndHWDqHtjepxROE+Qm4ii56s8jope2ryyjDHLPMaJRk58804 5zyFyTbr7PPPQAct9NBEF2300UgnrfTSTDft9NNQRy311FRXbfXVWGet9dZcd+3112CHLfbYZJdt 9tlop6322my37fbbcMct99x0L41AAnjnnQACUNyNtxF4822F3wkosIQCCyzAABkILGB43V4bsEAC QzSweN+JZ7aA4EI0QIXklCuROACWh+FA55NDHnnqQ4T+hOSsC4F4/s9QgK6E7WIokMACQtCuOtW4 Pz6Z7gqc7kADCjDAgOuTMZD5ELNXjrfnACCw/N18N4B3Zrg37wDepzuvON9+P24AAwogoMDjxevO t/ud43357oqfjoDgBhB/uhD33y3870qDnfJ4V70FeG53Dvhe4nRXJAY0LnTFW4AvRvfAAjouAQb4 2+iKxDr66S51iKsf4k43OtgVDn0LDGHhKEi53XkOcRhsnOIKeMAFOMCEIaQeAJMGOwNITggbbJzh nMe83i3ueZSTYAEvt8HngU58++sd62A3mdThjnWI49vuLgeAJhKwhKfbIgCcdzkydpGAQhyj49TI xR0WjRO4o94G/m1nxiKcr4CF44QS67g7PRLQeQrwYRSlGDrbGdKKrDNjH4fgRSD+cXIzrKMZ55g6 M9bRjUfrniMJyUYj3PGModvjGgGAwDMKAZBIwN0hKXfIR9YwGI005e46KckZUpJylpwhJjMZO9lt roB8u+QQPtk4wSnRlMjcoAMSd7r/VbGQiGQl6zaIOCEscpPJ5N3oEDfEUZoxi8CkpS53STQZOm4x iUMl7AxIBBk+DoKTI9/kSkk/eCaOcxY8J/3utsDErXGZjvtlA/zJiRwOVHHi+yAkN2dC8SkxnWtc p0TJ+bQbcsEAgzSCRbXgQyv4Ioob1ajvKErSkpr0pChNqUpX/srSlrrUUwjQHt7SR7wG7O8Bustb A3zoP3y+9KdX8Gfo6rk/gCaOejjFyfL0Nr025I9yaTzC3XR4hg2qAXtLG2kThOrLow7BnAlIIFXP cckQfiGjnhTjQIvIv3umAaBrOKhWscZVNaaTCPRTnE2hI8zd+RQLDFxCHXt2TSYcEwtohQJbFXvY PBjAcgxowAMgu9MHOJCyk42sASwbU+VJVnmRdYD1HlCEmDZgp0QQrWkHqdrTZlSopA3hL4fpzwWQ dgmmva1llddZ/J2WfGNFgzArOLzCJXany+NiTgVHPwZkdLmdrB7noNvH8zkQCe6ErAOtCwAHFK9w Q/BuAtrY/rzKnW+8DVTeGBnACZlSz3qGg+/9rhfW1m1Od/ajL/lmekregtYA1uOE33RIvO4iT3mL xW7iKHfQ0C1OhgxOpF0NF0LDHa9ILpTh5WRoWbdasMOzdWTqHuBPZ9p1lEh4AAIfGMYU3nOgDpyc 8/5qBmHarnE1HGSDodhFyiHuhZPTnI+7yd679hgA6yPlQ8nLwc3dsIne7ec/JQhj+0ZYxszE6xrV Z8oKElGNuOynlvFGwQVicISmFB/pWFjA7n7RuZNT4AUZK0GJAtiamevhnU245tTtdQgONSeeHSe+ oS6w0EQQKj8VcFvA+ZPGbp5m6ppLv4PG2IDBPYONUxdE/hTjWYsSjF6ax4k6volWnIsbqKlBXcwl WNWv+dukP5WMQtfhzq9KXgwVoarLWa6yigTUMt+e97wjI/mXjUyfGi28bDV/OQo5VN9RCXxUGZ7W vrblp23H6gDeHnQIu8XpgoUQbhUmetzm/Gu3hXrccZ/Rts1VcQTH52E2CFPVyNRkrnN9zdEJc9+A juQMC6vkeiPBqhDeXyPzrOsOKpHgZ2QgH+sczWc6mhOLvOUpZ/jjDzqPkW51YUejCwUST06yC9ah yRPQYB02OKYL9KmK4zlr0m0R0TZHqLtFTDmT97Jzx17gEXD+6OYSgYzEbYMwY6nvRfYR16MmL9Q3 vjhF/oZYyWYVQgKNYNV3g1zWweagoTHeWAsGc5QI/LW+9z3LfG/QeXIc3c7tqmR8/tsJ9CN7Y/Oe 9/COm894zF86Bb1O6/390YieoLtre7/KnW6ds83g5iAsYjm3MabJc+4bympDX8rTp06XYFTXiMqj BxHVdK8evyXN9bDP+OvLXNzuDPdY2o4d4Of+uimpqOa1Z/xxVqVmsHENdc037njUJDkU1rrxIjL/ 2dDrtfQVF8JL2zDdKvTho7OveIcvkHoN4JxD64toGAK7huOEMWjZ2wbZkpm8EHVmg/nMzSkuGJ3+ fDJEiZ3/l98f4h7ESOfGTVpXV4N2Wvc3d7LDRQ9U/krvtjsrJHRaJoH1VIABxTmN01YBtzzAl3/r lGlLIDnUI4J2xE4kSAQD5Qsp2FYYNHN7c1DFoz3nVH05F0g0CHP+JFkzNzkPYHgIAEcOFU+SJzja gzzKtoOMhjq1lTiNdgch9TpF8IThlVgaRYVfFXbDlFr/w0wZhVFXwFZeWCSvM1Ijl1rhVSTcM1cz 03hkIGe1ZWJSc3VGsFNY2HVacFpwCFRnFX79oz55WFGQdoX4VIFcYId6GAaTVQSSdYiMyDh9+ION GImSOImUWImWeImYmImauImc2Ime+ImgGIqiSAcQUIqmeIqomIqquIqs2Iqu+IqwGIuyOIu0WIu2 /niLuJiLuriLvNiLvFgFEMCJwSiJwwiMwjiJxUgFyYiJy3iIzRgFz1iJ0fhT0+gE1UiMyHgF1xiJ 28hS3agE36h1ETCOEWCF5HSNCeRDgmSOqhOOSPCNDjCOCZRA8phS0+gAD9CDj5iPD7B1mOSOR7CN 8ViO81iQ9WhS0YiP/SMBDNmQ/ZOPasg2AGkE1xgBE0COGJmRF4mQR6CQCCABFEABDTmSEvCQ/fg7 E1kE9zgBLNmSLvmSLRmRcPOM+giSJUmSDCmSI8mPTeAAAlABs6Ab43gEV2IUDtAySpOSRJCQMNmU TSmTSaMhXtCMosWQFnCTOGmTIUmSCMCOBxAB/rJyOhXQMnIxD+OxNEo5BNE4ARfQlheAAW2JAXIZ l29Zl2w5AexIDQPSMRUwIJGQAXfwHEQgmLWiBS+DIVJJmIW5BM0YATmpk1l5lToJmQzZhEaQAQHi AGVyBGVJNWkpBM9oAG4pl3BJmhjAlnNZmm4JlkzwKF8JABEQMXOgIJRQm9qABc7BJ7e5mzbBm7YJ jkbgmBJwlSS5lRYgksiJnDkpAVZ4ABpgKRijAahAAAcwljGiAYCpl9KJE1KJBZ8JAM/oAHVZmqRZ l29pmqrJmkugmRUwBO2ZE4MZn/LpDLrJm/Vpn7nZm0nQmCBpAccZkhRwnMN5lf4ZoMkZoANg/oUB 8JxFEAEF8Jw/CRQx0pdP0RCyOQaHqZiwQJiHOZi0KZXfGY0DcJ4kSpepOZ4YkAHquQSTcDoRsAgO oAEMGgFSIgD7Q50CoAEVEAHSiZnlWKMrugWHMaRFkJvPoZhg8iHdSaS9yaTvGJz9uQEbYAFSCqBU epz++Z8BagEqqgQLKiDPiZ0AkJ2EAQAaYBRnOgAGwKBmQBf52Z1RYKS+WaRzep9qqY1IcJTniZ58 Wp4ZkKBOEAFs0hCcEKP6EQGssAg62hAV05cZwCYHQAAOUJ1f4KR2qptH+pv1qaGLOZ/4aadwCp4a xQFYmqUhmaVaeqpUSgB/ao6UehWL4Jzd/vWTXGGmRhGbatKmHuqpVJCfoOqpvnqpIZoE8ZgBfdqn rFqOUHAd71mmBlABCSSrAlOmZooIYLmjFlqpwEqnbqqfltqkvPqr36qSRxABpqqqqJqlU7oBGcAB A6CsSvCowdAt0hoJnVmWZ5ouCdqZasCht5mpRRqsGDIj2/qtw3o7HCAAxyqXLaGmUlAW7XGvFUAx zymoUpKd+SoENNqXF4qb2xqf3bqb47qp9qmf/xquS9mRAzCl6aquU8oB7fqu/sgEFzsAAgCYRSEX PlIBAZABBjAJZ1oAmPkXNrsGwVqbSFunnKqhtAmyvHqweYoxMKuw6Jmj7QqvUKCZ1BIj/gOgG7Ka o4AqBBmrmaeTsYdApySbtvcZskhKsnCqqZr6pCpLAB3QAVK6AXVrt6z6rmEIBTyqAb4QAQOQoGuK sxlwlO86uOoopv36qWvrrSh7tB/itCYLmnjakQaAkQMwtfWRowTgru+KqHkJK5kJtKGhAQUwlg5R AOMIHBXLJkOLlPQZsLtap6AqsLUCJsziph/KBAn5AAOQARAyvKz6pwPwAH2rMiErsiYbt4nJvJML rpUrqlYQjZmLMYg6joPLAdw7uBipjlEwlFrnvWMKuDFqABngI10LuORLDdsJHvBZstP7BdHIj8A7 uPhrv/abvBvStI9ru0lLubgLudCb/rLVm6c3pI6iO44YdUPp2MCjSwUV8Jw+GaSD0KFoKwahqb8c DJEdzL/ngC7+aruFqSHqIcLNQbsUebkdWZAu/MIuHAY/KzAWPDWhuVnIq44enMPIm8M6HMEzs7wZ zAVQewUze44tDMEvLEgNrMRHTDQYjLLeycKZGJ4wfMVXXDdFzIzZeMCb+J27tMWXCMb/SMUSyQZk 7EYh6ots3MZu/MZwHMdyPMd0XMe56MWamMY7JMaWqMcAxMfS2MXG+MWCrIzHiI14bAVATDcCmcAN XFKALAVPfDWhqgX3+AAgCaAAWpLIu8hnnMjr2V3Gk1GTjAQc255dS6niywURwLGL/nqmezkgNZzC KjywWdChUaweiFnJCZnJmvzLW4kAJwkFA9CXs8CgZFoEZ4qz5uiTAyIlehnLB5DMdVDJhgzKqeXC Trx18yjKPSkVV/Ge1tkFBVCo4BypfKIBgkrN0UvAcdurmErCRDqyd6pRvgzM+LyVw7wExayxrRCb tvGc5awENysEPGum7Tkgk3qWTZCh1pwOHMq0Dq2hkYzF8ZiO2jzLRqABAcCafzoFbNowAbA/Xbup EBrSR2Cp/kufQqzSv7qfR/AA+TzTHqDJEmCZjJAMZhvQDY0KmpkuYDkgegnPJ3up8PymlTvPT2vG 4eXE5aiO6ujC7+oERBIKA7Cd/vNQnT5do56rAQ4wsbBZo4MkqEJ7OpHAoF8quEvg0k4LsLtqwksa sEcqxZYbhTN918DclUjAr93l1TKqdUBqHRpAAIA7qxVwuB5a2GdtHbqB0k4wpPQMBb7K1kVdspEs j0uM0QW5uUB80D6psQ/aEO0ZDpE6qZ2hs8DQ0YkKKxczmI5NsEnNrQHMtolpwkOMtJxqwEQg0wDq AR9Q070d3CEJ3Jq8z0TA0RqF3Okiqa/qnIByAPFYJo/qCB0jKR27M0xKK506sHAN2xLjvOSKzUQg uARp0RHAvRrNmT370YJtpoD5qNpw1u+5oAkMrZPq2BfBsyNtE6+d0h8rvf87/rKSe9tDHJBGINM1 7QEKvuAUoODDveAO3tsbELbKLJWdia3QnC7P+RML+qKZ4QDp6yFCfcsv7da0ndK2/bG6rNvXnATk 3cRRHY/BS+HpMK2SQsG0SgmWcKasWRvFTLGWQqaAog393c4vDeBsG7kF3NJ0Xc9F0uAMDuW+/dsO zuAL/gEgMOGJJRcrisqUsLEjLqs/wdGFop40OkxfytgkXuLN67jcGq7fqiGRHF4vbpAznt4EvQ31 Sq2nPZioUNIaftwFEEVbm86Pjba/Cbdtvt3x3OhGLsQwbQQSAOGUTtxWPuUhIALg0TPR8LNlSra2 2t4CUdKtzKZcLilkOuKw/hDb/6u2Rp22z8vq4T3ITCDj+HvnnlwkPi4VOlvMPTupHOMAQxEJp5u6 Oh0A01zM2Wmo09zQSlq7rQ7ZRn3Cu7vL8yu3DboBVF7pEP4B3g4Cmb63WFuusxC8NuqTHQ67wDG4 UjEUj+ojAqCe3gEeGkALlhDas0vA0e6tTWubcb3oKyzeeSq4MOuu4z4FySy4hCumwdsQxjvqg7s/ GWC+hb0O8Sij6om4DpsGkH7tXRCNEbABIAAC3l7y3z7y4K7pfyq6PTnxy06+V03siXvrCTTxuoao hJ0N+IvnXrq7TtrSuEvtuozbHe/kLa4EFi1IZfATz5rrdhDFHk/ELp4B/iIQAiCQASgfAuEesyyv NEX/6lMs8FO4nt0sBsUsME5vNPcouBkgvMUbs3yb9jgD9fKbBXMuySSVkI78ABjpw06Mkkzdxy1c 9hadxXNz99zYwt6czaIcwzEsN4jfiH4M+GJfyIAw+eSyxna8+Zzf+Z7/+aAf+pwf+IGMyLRexZYv BZhPUauvxaSPwGWvUgDpj6UMOZE/Gfm4k8YNyU9wxAks92aD+JuVlQ3J85Rf61M4j0r/x69PbsRP kjSOxGSf/AWZuU4/2MRsw81vAM+Pk9Ffxkif/Jit/IgqBeC8BGzK0CFMv6/vAN2PydDP++Hf+Odd 3uQfkV3b0bdz3Uab/tu4KZhAEAgAiEWiUGhMGokQ5hPKdEYflk2ns5FsJQjJBsyVRKJMwwGtAWjS z/OB6BiU6XX7HZ8vDvX94jTKIc7BIYIjwsGAcLFwQBBPwCBAgChCY2DggDLioOAyIgOAQENt1FFA k2xAw4CNwK+MD0AWNmrodg+Klo/3CbD218hBwoqAgyODq/h4gGvuLmKySOAVaoCPgLJ2+4i2m5sO SWmJifzbLpjpkdAQ0eB9UdGB49HOgLKCzyA/IyMg494BR2dE/VtTwcEBAgkrAIhQQKCAAAbAHVFS 8Qmuixkv7pICLh2RKhYscFAUgZiFDgQGKHqgrF6dA7IExDRyDWNF/m+9cubSKGunRaHeoIQsImhR BESMkJ6kh0eDADYBnrEhckCN1atXKbECUIEMqqtqZj3rOcvWLF47NY4rp6vjxj8gqZAkSdGhBBEb HAEwIGYDmTv+nmkTdaDCM5yWQq2aM8qAJUwKHQgA29NjrrNtMwu12DmK0TgAGAVyarOMAEzXGq6B AwCr6yKv/d2rZBnN2CNmcxLds9Yz8Iygxy0hLhqP0ZQkJcQZ0CGD4OUqBd8J0HBAKACWt/PBuQ/O QzXXWuZbFeCSJsxy0XI0zra9W7iaP7MvSgcpU/3wDKG2Vq07QbSKzaqGXgMAojkcCEDA12Ira7Nw 6OPJs7gqnO84/rqgmM4CwQwYABEARrKrg+rskOieRzQIxZ9zBiSLKtkg1Aoj0Hx7L7hzyiEqKJ/s 8wU/0vRj5J3T7MjkgFAikCixmTIYIEECqNLgIe20ioaADDrBJMrr8NKpDqA0I26oC9+q0Bvk7lDO LrvWEcSANkkqMY9oojrKMomIwEnGB2PU6s8DwaQvPrnELPRGRDnykdD7ysgvEaUklZS/p+qIABOK Psw0U0z7IuCVD/EqpAjHRAEREzkw6c2OQ+MTjlEKFx0TSG6MGtEu3gDgcC8T7XBytjn45HNASiSZ A1BkBQXHxvleRRNDMxUl86NHhdx0tdUUMfKsbplFwhxDCU2C/kdxLpT1N0e3MSoCOZl7AN6UNrAr BID08KeeSQbg5x70OCmgsQDguC6Tf6Rs0qAaz/Tt2RzVeqsXhts7VOK5rGWnpSKLzK8/bz3+2LpG RcZITXQCkQCLLMAAgyQwRHjZAhFC6CsPOYxopbEMVI1gU7yUcqglToX+ktnhYpnQrXLJBZfCcMMN LUiMt9W4qWP8AxlrkM119qyS6xCtXRGy2CvlDsR+eQOZCfA167axdvXMrJGLFFN6mJJngGPYdpvv vj/2mg7R5MDiZbPNfllsLELg62q/Hedm61mxnltSECel1NOfH9+cc1s1jCKCtM9G3HCzQ6h3785V X70PNQvJ/vzy2FNnnfbVAS8DuQcy2CAE0hGXuYIQsmy89uKNLzkp2Zma3fjm+b4d6igMgDc73k+/ vvcsMXnA+e6bh37IRUhj3vvyu4VeXXXgfSCCB/LuB35m2I+MaPPt9xt9/Oq/n/+c8pcCAgEU4AAJ WEADHhCBCVTgAhnYQAc+EIIRlOAEKVhBC14Qgxm0oOegMKRBqKM0/ROh3EZYwuN97gkhHMTViGdC F/rhfy+UIclQOEMbdi6GN9ShHnLYhB3+0HE9BOIQa7UuIh4RZEJEIhGFqMQlPtFiUJSiyTg4RSu2 7opZLCIwtNjFr3nRfE+rSBPvwAiliA+MP3TiNhxQADxU/mBZmuub0yrWh8hFLl3yqZYR8fM62YUo jTd0XfgI2UImEKaM3kjM4zJTRzzgomkLo9UeufioP8bOkIE0n+AK2clMfuU6j6Qd3BzZqoZBi1EX ImMgLhk7muHhDQJhw4M0GcRAeLKT+3tCBLLBINKsKAIV6IpAjlCBy5gKAJmIhCg0UBliRgiVt4DV N8qVlnEpygirTGErZfdKaIQSNrqqZSnHeMt4JAKd8CDE1MzYwppg6ZcBYAnBBOBGtNTTIZ5IJiUy 4EbWZMKe64mmcCh2Ix7FDS0ZqqIwVjMBTDh0ABOYQAQkStGJgqgPGqBKdo7GOjFqzRx41NFIcWfO SBUi/jKvSwo6l4JS/GBFo6/hU2z4NIQFzSE2BWDJNcgQIz4JFJuuklWiyOQRhfLRDBKdwAUkmgGl OlSiEYWoOH8ljSIsSROCGIUzn4HVmjiAFE9akcfIqbCfNCqShYpeCtfJM8wpRR6I4Jk8XkeHfmBC IqrgA015EqPYTIIUzYTQT1kVTaRhU5JqhdZRK8kEiz4VshCFqlI/eVVw+iUAPJNnMgnWCcxqdiES eVIFdDkot3GGPUb9ESWPck50rlOd6aSrHEq7FSJIghIzHU8vJCGInFaDZ4MtqygnecqCQqw+1qTY FmERksdGtqnQnUBlKzGTZ+yDEH4S1hCwmxCySMQw/t4abkKn+bBqck21I8tmB2eLy+W1JBDgpQgB CiBP8EIpIpO4qQAakyB/POkVB1uSVQubR4chqi2/WRq4ggMf5sIQCs9tKlOXSuGnZoADfqDETB6x r3rCaLt7EqY+SSMw6uphvDhqmBif1qPkSmu9EW6pe5OSqkCsZk+YgJ3Q5HqJSth4FdpZzc6KB7fV lnOhR0EGZJmagQtYuKlryygZooGd11QAxJxNpoPIggkCdyvFh6VWgg+aSsWytgib4mY3kUG+NIpU vTWEcIThV+c6TwB+F2BJZSszicjUlxpTKkBiBAxeKa1i0AOoZ79aA2Y7inm1fUUvYte6y/fZGdN2 /uYAiE5cSxIm2QigeHKm+/FkDVgKD6qag5oBkAFWgBVbRHa1Iqi0Kh2T9dEHLu9ZJZZWR84tERoT 9rDl4envyTnUrhbAk5n9ZAFQw5tIDPOBzTucBZsLKA7+orGfqM0OZmcUUYmKVLRXW27PimHjbey5 mYjsOFTu0v3Y9KQ6rUk4w/h87Eait4VxRnZgMnn11rctBz5EfreWxmgsuPfWuPDaHXyFCRe4w9vW cIrbzt0X36HFNc45iHdchxwHOcGROnI1mvyFH0d5ylduwiZqEOYxl/nMaV5zm98c5zmnYMuNLXKe /xzoQRf60IledKMfHelJV/rSmd50pz8d6lGX/vrUqV51q18d61nX+ta53nWvfx3sYRf72MledrOf He1pV/va2d52t78d7nGXu9rXXHe7K2UEd9f73vned7//HfCBF/zgCV94wzsP7yNQ/OIZ33jHPx7y kZf85ClfectfHvOZ1/zmOd95z38e9KG/POIj0HhQnR71BBD96lnfete/Hvaxl/3sO09600dhAKqn /e5533vf/x74wYe87RkPICY8RvjJV/7ymd984Xcv8YsHkOIVHADOE8H5uy9C9lmPfe5/H/TEH/4I bmJ98gOA+ug///DV/3vvLx777++++uWf/vrDv/2ivz8TRp9/8P8/88RP8TqABBjv+MzP+xLQ/v/w L/i2z/5kTwEf7/4YcP4cbwIn7wIBUAMjTwAJcP3sj7PSTwQ/0AhGsATPTwG3zwFRcAElUAVf8AHj DwTxLwXpL/5W0ARPUAdLUAb5bwZZ0ADzLwJ9sAZF0AYTkPw2sPnEzwMtsFTMb/1uMAejUAhtkASt MAIxEAil8P14EAur0Ait0AmnsAu/UAqpMAydEAbREA2HcA1vsAWV0P2aJ/E6YABo8AmuAQ930As/ kAzFEA5x8ASp7w/9sAzDMAvPcAITEf3KsA//8BGDsPF2MA3dcA8bUQ6XkA5LbwSwYPEwAQ/18AFR cAQZUP4s8Qr9sPIWkAvb7xCvUBEbUQwn/hEQZZECbxEVb1EXgTAVY9EQ/S8OM9H3iK8DRgAK91AU p7AU05ACfZENLY8VbfEVU9EUv3AZm9Ear/EVz3AXVREVW5EZVTEJhVH5BNAYkcD49uQYsxAEbZEX KZEafVDyohEWvdEBBxEeSREP47EG3ZEf7/EUHzEQa5EdWRATyTH5zDEdDxAhG/L/MtAhhVEh6SAZ I9IiyzEYL1IJFTJbOtLLNBIkQ1IktW8TG49pTlIIRlIjObHzWFIlX9IcX1ImZ5Im9W8TDQ8nc1In d5Ine9InfxIo9Y70Uo8oi9IojxIpk1Ipl5Ipm9IpnxIqo1Iqp5Iqq9IqrxIrh3LutnIT/l8hKL8S LMNSLMeSLMtSdrTSLNNSLdeSLdtSLdHSLeNSLueSLuuSm+DSLvNSL/eSL4ESL/sSMANTMAfzLrvS Ie4us3YyMQmTMRdTMRlzLP9yUpgmGioT8ChzMivTMRFTUjJrMwcPM//OM3MyNFvpM/XOMU/zNCHT JyWzM2VnNTnzjxYzNk3zNXWyNvsuN0VTNv0uNWGTNcPSNZViM0czGoSA7z4TXDQTOVHzNRMTCYhT Oi3T7pSzOWmTOK9TM48TOpuTO3VzMr0zOi1zPHuTPLWzPIOTJ4eTO5FzNLETNccTO40zOcmTOo0T OuMzPbdTOuczP+GTP33zNgP0PX2T/jLn0z7Vcz0NczYv5z2X0zkzsz+pc+/wsz0LlD7rzjrRczoJ 9D6X0zvrs0Pp80HB8zlBNEEVVCfZszgDVEQHtEDB8z8ddDt3U0JhdELvU0cBNDxNdEefszNt9EZd lD+FVEX5jkVplEQrlEYn1EhjB0Gnk0c1tEl1dER/9EoHNEKxlECflEKX1EKPNCeTNDO700svNDvd Mzt91ExxdEuDVDzDMz+ltDvhVEDttD37M0SrU0Ll8zvFdEwZFFAHFTLPlFDXjEVL8zIVNfBOEigd VS0hlSdRskEP9fAE1VIzVVM3VVLYk1M/FVQh01NDlVRLVS9H1VRTVVXZElVX1VVf/hUsWxVWZ5VW A9V4lCLAsFJXd5VXq1IUehVYg1VYh3UqfzUqtZIrk5V1cPUwa9VZn3VFMRVap5Va/05WqzUuvRJb 5/JaVVVSuQkl9zMntdU0IXRbf7JbS1UIiHJPYdMWDPU625VZyzWZOEtez/VSb5WXmtVZ5ekoc/No RuACUNPLsGQ1yRVKt0sIMEFK3JJRDxVVDfWSJPbu1obw/BUpa9MbqsFc14wqFnZdD5ZfJ1NhO7Jh STM5y4FTR/Ve4dRGKdbuQOVilVJjmQBUlKA6a+oaTjZ2EDY8ycMjeTZNYdZLw/VbH9Y5YTbwPPUW wFVLK5UnA0zwMLYabtZYhdZB/osg9fZAQwnrY0UWNr1sNcCFJXhWaZ/WY60DbRu1LFm0G472Nssz Ouf075DSISxWNLdWa1EvNrGBCKz2CDyWsHYDbBM2W+SJYRF3Sv/0T/HTPVsWSiUncDsUT+HTTx+0 Tdd0J4ezA0ogFuRUOb+UQmGzYy9HFECHl1op9WCTKP829fr2b2MXZ1tJy3SBp3p2ZNPUywAk9+Qp NbWTcpmTcukWXONiF1y2RaNUeD00RxdUX31WKTr3c90URYNUQyF3Xy8Jeifl9CrBQfXWdU8Pdk/X CDg2bacXd92VPGKkXtcXODGzekV3dCd2R3YCbSE0TD2UNkH0bGlXWifzbUtT/nkzNEMnVnWPElep THW993u791fDF2sBuHxldzezjRwK10FLtn13VjVHd4D7tDoVTC2A4mljNH/BdG2x11r/F4Bz84N/ c36RFAqkNnfPcjaZcnxdl4LPtyx+CoMzmLNYol6lZDVRuHlhWEjZwn6DF0CbmEt5tH/PkoV7tFzF Uz7VNHgJT2ZruEJp1jT31oFngYc3ioRlZ3ujwdYQt3fF2GXxNE9/N3+L10eON4vN9Tfptk4bV4VX +Hm5eG3rErim1ovpd29VVo57uIzTdzbFlsEm1yzLbHbFNF330o+TM2MPWXa59pDJWJMVeTapomyv IZHJspSiOC4nOVTX9XUr/jhMPNZo7/WMQRc6HZmUX7l0FRSVSfVbq/iVdzKWwdVz8dVWi2dehVkv f9mYhXOKk5mZnzWXmxmaP1UriZWaq9marxmbs1mbgRVZldWbN6eYy3Kbx5mcy9mcqbKSe/KZC4+I bdmd3xme41me55me69me7xmf8xmfFVgs11mL1e2bsYYz09l5iTl7zVJKytcoA5pv3Kwg+DlmCc+f By+htfY/GLptIPqPGpagLyeC+26iBa+iM/kmyBejP0ajzTizOpp72RjwurVFRZoWpu/8GvmkvSWl e3alK/Zmb5ePDRp65TWmA2+kgREFBxegFyWpzS6nPXqn1wxwx9ZBxVWK/vsYSjt4SEVTFjqxAEPR xagtTPCNb2zayEyuqbn3qRc4mUx2cQvTqkF4aOPacfc3cyWlorn6F2sXreJMqVdnucT64hSYUnE1 rTd6rUFlNcyWdFdTMuf0hfFYfnWaCJqQFvU6gN92hEdYqMpkYjo7oTi7OEQYs43rzLBtYu4Nax4A AcwNnJu1NDmam3YKXHo3q63UdP/XsYH0iPnXeiXbDi9RHeMGtRzmryXNuEFbcoOClJxFmsDaYxzg ARrABE7gBBZgAU6ADvl1P2FbezmrM7G2Tdv6Lx31hVN4f50aADxR8UDR/pA6lTY7sSDps+Wbvq1t Ld7j2hAKaeC7WwwA/gGku7qtW8CtG7tvdWQ/k7s32qePE0rLdG3H28GP2LZhOHgTuhiPEQTd+8X4 e5Lq28PnW7ifRUyGSrFG/LAw4gEUgLoHnMUHPAGoG8ZjXMZjHAEWAGTO2q4Lu2cXvIh1O4YhPG6v GIvTlMgZN8fjj2wPMMT529dOnMmLC7VMHLQlbcP5ug8eAMZbXMtffMa7/AQUwAQawAFsHKUJOsHN eMF5uchjJ6SJeqsX8glD/GHMa2vQRdecfEKwTc/JxUI8O7MRbKnrwL8bYMW1vMD7gMw9BscJG8dB xZQnJWKRFvCKeqc80stgodegKNBT7b+nOwEIHBYSHafNXMeh9KOX/naZv7Ko3RnTO4qIUBtr/Ju1 o0DUu2XReanUr/rRHdpxwpksi/qmy6DWz4KXljLX/TLVgxLYgx0Khh0z4vnWNzfZgRJvo1lBF4BV ybLNXxoW4JzpvP0snJ1ztL0rz9nczx3dy3kBtvlqzZn0mL1/xB3e5z3U6d3ewUHe713f6SDf993f maDf/13gA17g/Z3gC17fDx7h7V3hF37eG97hmR3iI/6mJ57iMdriLz6gM17jvZnjO37kGuB+Pn7q Br0BTh7lU17lV57lW37lAcDlY17mZ57ma97mbx7nc17nd57ne97neX61pwgBppu6w/znjx7pk17p l57pm97pnx7n/j09AUwAAZAIAai7AWYd5APJAAj9BKr+h7D8BLhn6zvu6sdehxogAcC+7Efu6tn+ hQhd69te3wwgAUT+haZ77ule3xxAAfC+hOCe71fO7gX/frCc7Ae/5QwA7UXo6xUf6K5ehCQf8n/O AR6ffzC/8nmO8u2n8zef5xrffMIc9IFOuu/nBPa+9AcOy+2H8Vcf6BJA9R9n6GH/5zS/e07e9nmO 9MtH93d/5Xrfe0zABIB/5U7f9wHf+EEO+b3n95cfFhwgAaaf+oufCBDgxYsA+w9dhpo/95X/cepr tj1GO+ggGohAp6Ag/VuF150jDydOhgxAyxPduq3fug3fhLzf/nmef3MGTVLMAwgAwiGxaDwCCAUk MRIQOpBLZpN6LBCMgYi16/2Cw0zDIkFcLBpQtOO0OInjcnnDNL+LG2o8H0sUPEERZB1xZRAODRAM DFVsGUUQZAg5QQ0NRgH4AThkFloOcQkdMnIGVHgCOE2KUroeFimWEpkkIAjV7tUmmHHyQvEm2AEg JMARCxMhoLENuaENmzAfk/XiLgwDSDMzbWMP1S4v+KIVW/PF1aGvM+mxz20OBToWBATMUtrXBzro 2yfZC9QowD4HlTRlCXgPIcBURR5tOuhPgCZ9RAISOEARwIAnTvYFyORPoJBlx7gBYLYgyrZbDcqg EYLSzS0h/mSwPROS4E3LlMLQnDBwU6gBcQbOoNlj5Nm2YzuBpuSJ8h0YdVSvursaJp6QLf1KASqy qmuWA1MABJikpEi/TAUEHPQzCWBFRw4fconoMVCECkK4duXSUUiFA6oCEDpg+IDfv3OHxBQ3Tpw0 O8wsLxB3i9nmcUQaZIpJTNe3YcvM3FT5jUjOIw5ER42y89jpkrC1WrGKe13W3V0AbyFA8lEogX4W ChGwZC0R4WIDYWk1ZB++IxAJSTw1CzBaUQsXHuT4RF+BemeF0HRDUxromDDHxXxpwuQbk0UMPIPd 4Ok3BPlRQ/PMUUSkdg44q2nzzU41VQaZZ761kw2Ed/Q2/qEUiJiSxHnE5TNdQq2sxdwl5x32FwHS /RXAASRZlxd2AjnyD0N4CcHYYCV2+MQgg1RH30pviAZNGm5IcxKQrwFZk231BRngN9DsBGAvLz0o EzblGNHgNXbsNKCWUVmIhG5hpqMUmUVwFdaNOBbnIVqIFOCXiEKs2VdcWXhi2HEbIXEdnYGU0k8W 3BHXUWH5ZJLBeIgMcNc0UYnmjQOS1aQSAPkVsaCVANy0ZUq2SelMGQdOdhuoQ2ja5ZKrnvmZhK1+ USGsmlQQga2OeFdABB2RGJ4fwmUQASBcCIeiiruecidaA0RQD0NOiHLXI44M0NFeJ3bESAEHOISY PMg5/nFPR2ohFglyrGH5zB5IejYVlXCIA0c1l76BX0xIIkBZSg2IE6qDtyCZiXqcjhqVCQZso9MC A0Z1gjezCjEmxLmZOStIBM3iwD6NNWEcIcLZE6g9qWhsj1/KxlhAFJuENWdgKRagqBAgeysei44Y BoAjxVmLCM0YDiEOq1YaeYyVlWZGsBns8pJ0fglfFtO8QbuHYFQITO0Af9aoCgwbpp4p8cTtVDy2 2XiQ2N1VjLV5NhUG3MWpEQzjRrdrSE0sttuflb23313s2kRY7wgbUtt/Iw4GvvYaDavef8uauORW DFBAdXxojI/Gk3NOhTfNQPy435F3Xrrpp5stVNxh/r+aOOmowx677LN7Ifrer9Oeu+67d26727jz Hrzww7fq+9nAE5+88svzYbzZyDMfvfTTG+H82NBTn732xFufd99xcCeHyzNeFd47K7KolfmIf5z2 Omutfzgfj/nWfejfi7F6HOOHj078fDihURP6n9sOMr73TQFF8rvDAbHSOsRhrwueiIIkkOAAHhFB EZE4iyLIN4DHHEI6pCDCCJ8DgAzQ74Qp/KARLogIRaFIOq2QxRBSIQpiyfAJKIzFXFwYih+C4oSL IIIPa3hBJMBQQ0lIISxcoUEk0FCJqkjEENmkQI5UsIZLHEgrQvjDE+HBfrOKoBV+NRIjWKsejaGH /kXQQhB7ZIFm1fJHYybSlTfyKR8KiUI/AjKzgOCDjfcIV826ApYn9HEfJuqQG8vTsT0CJGSCZARf avYdPP6ROochSB71GJwz2ixOdwSkFt6ooyVkR5GV6AfHpmNKCp6RZqE8xR0dSaEHQg5/W4mj4fph LEIMpi1dWYLMTMFLecwiJAfpC46Y2bHEGEY5L3MOW5ATlvgdCi2TMIs8JqGXrnTyMNCkiykOqU2A LKEfzfSLMMVzmMu1TTh8fARyDKeiGpGomMuCnw4FMsiQ0LII+hSAYeRpCmJN4Vz2DGc6cDk6XYLh V2fhUBOUoCOBSPMt8ohjAglSnnokRDvfqsDl/sJTJ1xJsTnDsVX6ghmIc2X0RS8z4Z+kSM3AyOwt TyDoHUmayY9ugYCMFFFQPQpStaX0L53kpyY6ScgrGPUfREXoYT56VIrOQYyOg+gXJCoPFKVsRSld Szy8Ks4dgVFnfiTMWg9XCWuhdHxzKqp1BjA4DpFVpkjtWJuYM1cujMeX54rRRdGaBaHiaKpOQCtg ReEywDAVME5Y0eXKY9iUPoKfhm0sOrRaPK56wax7NUUmBrMmbmbzTZidIZ2g4C2RYSg8zknLNNNW p70cgaC0Ve1f/LKJG2GVTc5hzm3B+QTGCAS2gwEUmwoRiKkitRTEcVlqUcjU6garn0aowFkc/sAI 6DKHQ9K9Yh4cejvQ/oajXyViuRT10gOYC5XlWpF6U8QssS4WWcwqV7YeOceEwNceVNWCrnjV3BrK CCDBGpZa5/hSBYbrv5gtMEGSc0+Q5QNblxwA+qwIiYVAtx77nanL8qsoRchXnBE4cVx6dSxDrRYg eRmkWEebVfP+Dr1lrK+N5biQkr1lCtZSDo/VGrI/whHJhcxHz/50jwBQ5IAlCygB73kJUsKsmMEN YJJTOmWOCeowj/kZFNDHLTYF1x6HmKgoYjTemdkWI0o8iLW8FZ7dJiIgjYFuH6NA2Dc3D8fH0/H2 IHQu4qW10LvxbNgIreircDh9wmPoo9nB/mgykbHSVKmc/jTtaSpcOkyZ/jSpS90qEwj6eY42Natb rRUTrLpVCEi1q2tt63UoINZn8s+te+3rq5zgAaVrw6+Lbew5nKDTewvKsZvtbCbw2nSwfja1qz1q iEW72to2drBRd4LGbTvcrs626cgt7nOX+gRKOt0JdI3udwsPAQqQ3QO6De97b6/edjudufHtb+Xh Z92xawCz/23w4bVB4LIj+L4P7vDTzfsBaQjeMhT+8ItPzgEEtzjt8KNujINccv5RQMN35592Czvk KofYA2rx8ei1/NsOg7Ueam7zm+M85zrfOc977vOfAz3oQh860Ytu9KMjPelKr4MJTmAMKBOkPHsO eAAClm71q2M961rfOte77vWdI0DZKx872ctu9rOjPe0ODwIAOw== ------=_NextPart_8B7_6F8B_B9AE8339.1615986A-- From sip-bounces@ietf.org Mon Jan 15 13:49:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Wt1-0002jz-VC; Mon, 15 Jan 2007 13:48:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Wt0-0002gy-86 for sip@ietf.org; Mon, 15 Jan 2007 13:48:50 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6Wsx-0001XW-Q0 for sip@ietf.org; Mon, 15 Jan 2007 13:48:50 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0FIk6W6017693; Mon, 15 Jan 2007 20:46:34 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 20:48:33 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 15 Jan 2007 20:48:33 +0200 Received: from 4FIL28146 (esdhcp041243.research.nokia.com [172.21.41.243]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0FIkY6e008151; Mon, 15 Jan 2007 20:46:34 +0200 From: "Kai Vehmanen" To: "'ext Paul Kyzivat'" , "Jiri Kuthan" Date: Mon, 15 Jan 2007 20:48:31 +0200 Organization: Nokia Message-ID: <000101c738d5$c0ca9580$f32915ac@NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acc1s0yO/DbK9JtDQu2pFFr7GMr+9wAp7nvA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <45A689D2.4010402@cisco.com> X-OriginalArrivalTime: 15 Jan 2007 18:48:33.0058 (UTC) FILETIME=[C1993020:01C738D5] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070115204634-44CF0BB0-7FCABE59/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip@ietf.org, "Isomaki Markus \(Nokia-SIR/Espoo\)" , "Niemi Aki \(Nokia-NRC/Helsinki\)" , christer.holmberg@ericsson.com Subject: [Sip] RE: TCP connection establishment X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hello, On 11 Jan 2007, Paul Kyzivat wrote: >If the server cannot establish a connection to the client, but >the client can establish a TLS connection with mutual >authentication, then that could qualify the client as >*needing* a connection. I'm talking about other cases. In >particular, if we are talking about TCP rather than TLS, then >the client establishing a TCP connection doesn't establish a >reverse path, unless outbound is used. well, it's worth noting that in many real-life deployments the TCP registration does establish a reverse path (even though no IETF documents specify this yet -- waiting for sip-outbound). Just look at iptel.org SER for example ("tcp_alias" settings, other implementations use "persistent TCP", etc, etc). These ain't pretty, that's for sure, but allow to use TCP as the transport with some of the already existing clients. >You can register with a server in order to receive outbound >calls without maintaining a connection, as long as the server >can establish a connection when it is needed. But how can a client possibly know which is the case? With NATs on path, this is still doable, but with stateful firewalls, neither the client nor the server can possibly know whether TCP connections can be established towards the client. Deciding-by-trial is way too slow as the FWs can drop packets silently, and the default timeouts are long. So except in cases where the access network characteristics are known, client will have to assume that _it_, the client, is the party responsible for initiating connections. -- first.surname@nokia.com (Kai Vehmanen), Nokia Research Center _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mansionos@Judiciary.Senate.Gov Mon Jan 15 16:28:00 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ZN2-00071f-96 for sip-archive@lists.ietf.org; Mon, 15 Jan 2007 16:28:00 -0500 Received: from d212-152-23-106.cust.tele2.ch ([212.152.23.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6ZM7-0006kb-16 for sip-archive@lists.ietf.org; Mon, 15 Jan 2007 16:28:00 -0500 Received: from mansionos@Judiciary.Senate.Gov (Celine [121.112.83.23]) Mon, 15 Jan 2007 22:27:25 +0100 MIME-Version: 1.0 Message-Id: <9FA1E7F1.000004.00175@Celine> Date: Mon, 15 Jan 2007 22:26:54 +0100 (GMT) Content-Type: Multipart/related; type="multipart/alternative"; boundary="------------Boundary-00=_U8IXI22JDTD5BHK00000" X-Mailer: IncrediMail (5252670) From: "mansionos@Judiciary.Senate.Gov" X-FID: B433CDFE-B71C-42C2-A5C1-D34C076A9851 X-Priority: 3 To: Subject: double X-Spam-Score: 4.0 (++++) X-Scan-Signature: a6ea8837e8866a83aa68ed7cf9155ec9 --------------Boundary-00=_U8IXI22JDTD5BHK00000 Content-Type: Multipart/Alternative; boundary="------------Boundary-00=_U8IX8NBJDTD5BHK00000" --------------Boundary-00=_U8IX8NBJDTD5BHK00000 Content-Type: Text/Plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Yikes stupid, sections annoying page lawyer layman sooner.=0D Utah truck, camper shell ac.=0D Ordinary, lovethe catch videojake snl cityragget dirtysean preston, spear.=0D Finely, honed mind accentand grasp spoken english explainto serrinwho.=0D Ges diesel, drivethe, hard clutch ivenever gears yard.=0D Backyard driveway everywhere arguably desirable sale, children legacy impinging?=0D Cash repairshow comparable area worries investors moveto civilized, seattle.=0D Heck motel sideday mii, dayfrom ejw jim santa cruz.=0D Motel sideday mii dayfrom ejw jim santa.=0D Yikes stupid, sections annoying page lawyer layman sooner.=0D =20 --------------Boundary-00=_U8IX8NBJDTD5BHK00000 Content-Type: Text/HTML; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
Yikes stupid, sections annoying page lawyer layman sooner.
Utah truck, camper shell ac.
Ordinary, lovethe catch videojake snl cityragget dirtysean preston, spear.
Finely, honed mind accentand grasp spoken english explainto serrinwho.
Ges diesel, drivethe, hard clutch ivenever gears yard.
Backyard driveway everywhere arguably desirable sale, children legacy impinging?
Cash repairshow comparable area worries investors moveto civilized, seattle.
Heck motel sideday mii, dayfrom ejw jim santa cruz.
Motel sideday mii dayfrom ejw jim santa.
Yikes stupid, sections annoying page lawyer layman sooner.
 
3D"FREE<= /HTML> --------------Boundary-00=_U8IX8NBJDTD5BHK00000-- --------------Boundary-00=_U8IXI22JDTD5BHK00000 Content-Type: image/jpeg; name="455-CE38B1E.jpg" Content-Transfer-Encoding: base64 Content-ID: <084A88FD-2CED-EE68-921D-C813A407600A> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAUAAA/+4AJkFkb2JlAGTAAAAAAQMA FQQDBgoNAAAMRAAAErgAABxuAAApE//bAIQAAgICAgICAgICAgMCAgIDBAMCAgMEBQQEBAQEBQYF BQUFBQUGBgcHCAcHBgkJCgoJCQwMDAwMDAwMDAwMDAwMDAEDAwMFBAUJBgYJDQsJCw0PDg4ODg8P DAwMDAwPDwwMDAwMDA8MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8IAEQgBZAD7AwERAAIR AQMRAf/EAO8AAQACAgMBAQAAAAAAAAAAAAAFBgcIAwQJAgEBAQACAwEAAAAAAAAAAAAAAAACBAED BQYQAAEDAwMDAwQDAAMAAAAAAAEAAgMRBAVAEgYQIRMgIhQwMTIHYJAWIyQVEQABAgMDCAQIDQEJ AQAAAAABAgMAEQQhMRJAQVFhIjITBRBxgUIgocHRYiMUBjDwkbHhUnKCwjNDUyQVYJDxorJjc4OE JRIAAQMEAgIDAAAAAAAAAAAAEUABIQAgUGAQYTCQcIECEwEAAgEDAgUEAwEBAQAAAAABABEhMUFR QGEQcYGRofCxwdEgMOHxYJD/2gAMAwEAAhEDEQAAAd/gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAD8OrGXBGUls1gAAAAAAAAAAAAcWM9OE+jCfXjL5LTZrAAAAAAAA AAAACC07ePEvrKN1TxPxevSKl/cD2HjwAAAAAAAAAAAOhCVVq2ZLbCM17KrUsVKna165fc9Fvb+F AAAAAAAAAAAAp9WxwYmwqVS1RqV2oVbGMtdn0Z9l4wAAAAAAAAAAAdSOaVTtSOzEHp20ShexhQ6N F076TLPqL7LxIAAAAAAAAAAAqVWxw4n1oZxhyOrTdFnGui3jjXtpF+PsL6jw4AAAAAAAAAAHRhKo 1LXanGH0bsZ83o67cru12UMeWcU3r6fbbr+LAAAAAAAAAAAx5Qu9ycetGVap2arUtamc/u0uaAva ZrZo9e/QePAAAAAAAAAAERq2Y3oXZfbrhtO+pU7lZp2tcF6lXcbo7+HluVbJnX5oAAAAAAAAAAx1 St8GJfOM1CjbqtS7TqlyuW9W1/W4U5t09zfqsm7UAAAAAAAAAAMa0bfS17YDRvpXPv1uta590dl/ Q+a/M4q2ndBatueOrzAAAAAAAAAAODGcW827ijk9itabUPp3werfsT3fNS+7RXNW6GhOPjLbX0PC AAAAAAAAAArejbrj5n0WKavW6Ms9PXOBjnNdviWuzVgY74iOzqs70+r8sAAAAAAAAABivl39VfO+ rjtueFiI1yxZar2bZX2P01YmO6Hxv5pQ3y9d5MAAAAAAAAADF/Nu658X0EJjbXU8KWquIe/5vIGp tX5z0d521e7LV9Txtf6LigAAAAAAAAARWqet/H7OCef2Nfb9TEnc839ZhwmQa1ndrh9aRrWOprlu 37PygAAAAAAAAAA6cc+dFO/p7bqRMoj9w/MputfvNXoWvTv9fO15YAAAAAAAAADomlsc6fs4ly+W e7DPElI6Op3dV3sw3yEc+3vV8gAAAAAAAAAKPhrPjGnTOGMy5sZltUrlps5j4/WokLsJts/LPNKP s76HwwAAAAAAAAGAqe7C046U2IY/ZkIZnoz3mnHM3Pu6jcfsVnXu6eu3x5zzZj61+x8MAAAAAAAA ImOcHVdnntrsUexpr04ZQzj06nDL+URCWiXnu9Tqt+Nhc4cZ+8x9SvY+FAAAAAAAAxjpnG15afat molyGxNDd2+nV9L5xmQDXnmXdZuB6vi2z68XVi9NvY+EAAAAAAAGEaO7HNbZg+WdXL+neWcNkNOc lWYdgAFS1T1G8x6yKbofVOIxL0q9l4UAAAAAAfhrfV26mapWLfDOe2Gx0sWHIAAD8MA8brYv53Up 2i5fujztwvQeaAAAAAAEdHPKx3JAAAAAB+EXrmJXZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD// 2gAIAQEAAQUC/o+MrQvK7WOe1qMxTnrysC8zNXJdVcFUKR4WXfNat/0Y26m5k8cEFGjcppgFNcFX U++PZHqr6QvlaKJ76CeRTXCmn2rd31E8vhijaSSKKZ9FdvV3c1E9zVfIGpvX75GiglJIu710ckt6 Cr6fvLc0XydRPMIWMCP2lNFmYvPA68eDPcblczUW726e4m89wOwe9TTKeUPWa/698+fsLee9P+dy OzTX0/x7W27pzi0SSqaYqV65Z7ZsVh8pnp8HwzD8fj/9Jmnz8tFbx+yalJpNpmkqppqFvHH8nu7L Gx2ds20toz5W6fKs33puGtE141T3O5Sze3H4a5zUlrbW1jBLdsap740+adNI8RMv5QIri/7vvO8l zUSXAXGZw3ES37ipLpPmqvNpsnI1kOSy/wAtPuHE+UhOkKmmXH8iG2108te6dPmct3bS8reWWTwV 4qox0EtGjJ5KOAcUyIube0uhcNuWOgcXVW11NLylm6ykionUCuLkMGXzQjUcdxkbiLN2WIVlLBfQ xS9hj7N4+N20t5aMvYMnjJ7V19MYFls06rnFx3v2LA8husJLj8laZG2lhZKvg29NNNDDOz9gclwb X3NtLbn0R3E7YLbkebtx/r81t0tzc29nBmM9lOcsvMhi8OiSSvHtaxkkrhbFqESEa2e3SZzkON4/ b5jy5WPk/L582UyN8jv+K2WI47kM3JLjsdjI7mxFfi0Xxl4Pbo+XcukwM8eTwGKsuQckyPIrlRQb 1bRXF7LxD9TRQnkWLjt5r+PtAfJG+Lv414/bor2+tMdb5Hj1ryqZ8+NsM9mcNcYmdkbGjjvFsxyy 54vwzFcYgV9atvbbIY9xu7m2jgkMa8a8fbQ8g5VjuPsk8Fo3l/Obm/TrhYaJ2e4Pwn9d3fIZLDH2 eMtuuZsPFnDHU+NOjWw00Ga5hZWb8VkuN4pc05deZCO2sMhl5+Jfqdts/G8QwuJEUUcMfoy9t5YL yy8F4YFM3aqGn1+S56/vraTHcvvzj/1nySdY79XWLG2GKx+LZ9DkGILJp4C1Otp55P8AG5Lx/Wur aO8gggito/qzWVpcKCxtLb+Bf//aAAgBAgABBQL+j6qrra9Kqur3dSpqtXyNU77N6Epzk4qmqf1c USjqiaIdCU5OOreehT5KHeigtuoJp1KlFVXoxupJqUU4olbUGoHavLp3Ggb0JRKcmINRa1q8w08p TUUSnFVUIW0oRgKunlW5Fyc5VTIi9NaGrci9b9PK7sZFuVelu7271u6V00hoJJd3pjdQlVVdPdfi AqKioo4tyuIqFpqvtqLn8adY4tya2ikZvBaqrYFTTObuD46dIod3okj3I9iRVeMaeiMTT6i0VdE0 rwjWE0W9blVV1X3TpA1PdVB9F5FvW7SSSEJr93UnpRSs7u9FdGTRfdO7hj9yqgOpFU9vc6Vz6dO7 1RP9rvTI33DSSSUTChVxCovH6nhFtCjoS6qEa2qn0p4+7gqVXxj9ciqAp9YtBQaB/Av/2gAIAQMA AQUC/o+oqa2ioqKmr29QoKOXxdUEegCAQC3HVN6gIBU1Q6hNTQqapvQJkdVsTUdSBXqFCdpI611A FB0AQamHsiqjTtFSegCAQUakkDU6Vz149PEiggE0IBPk2IvRedQxbUGJrUApJhGnOLlRBq26dgTY 0GINQCuvzDVt6U0zVHDtVFTrOyqatqpp7f8AKqqqqqfJtUcm4PZtTDXUQfkHdZJQxPkLlE8sIcix eRwW7TA0UclU3upptiJr1ZJtQNUHUXkOobI4KtfSz8W11Na+gNLk2CiDFtVNW2IlMFE3TtbVObT0 7lE/s1fYjThObT0g0THdo++lAr0+yqm+prvaNI1qK+yqqqvqCjfVtUNCAi5V+nBJRNctwC+UNcHE IuJ/gX//2gAIAQICBj8C9PxbfQ9n1r5/Xw8F44moVF7RgDnpUQ2ANd3hOf1ybilDUXqfEEceU7J/ /9oACAEDAgY/AvT8H30tsU1C+V3dF8+cCWXTR4ipVd4ULoXzUaAaLpo5Fw0EbJ//2gAIAQEBBj8C /uPrNqLhllp7IsEo2lRvRvZWUNZt5fgGpYUSlP5jfmje/Tn48qcULDKSeswOi+UaoUg6LIlm9pl2 Xy+XKksjdRarr6TbCgb4tuj/ANWLxZSpei4a4KlWqVaT0mUSnhKM0GL/ANXKUtg2N39fRYqRjhPW K7h0wbdYjEL88K0xOf6k8on3juCMSjMm09KszibW164OKxSbFQbbM8Kj7v4soVLdTsp6D0EGHEi5 VsSnDnClJO8TE+AqXA4u6dzHLF1ZO67nAkjrNkCL4InGkRZDCx3gRHs3LacvEfnPGxpsemqEvV7o 5jW7xKrGkq9FGftjcPyd3zZPRsfuLKyNSP8AGJwR4DWNZY5fRKnWPi8z7iNZ8UN0XLqdPL6Ju5IF p16z1xiKeK59dVsXjRk7S1HYbbw9pMz5IIFgEWGcG2CZwcC+BStmT9Qf9KdcN09MjC20JJHli+eq L8Ii/JlOKuSIStxUlOKJiQNueDJXZ0XwjSpxaj2mCm7SIst1xaY+nJk4zJueJzqTbClAYUixtMds TicXxSIJkhxGCfpAmCrMrosMb2by5MJd6Y+bpvgzgi9WiHadbk3WVlQHor+mPZ35cYWBR70W7puM aYu7vlyZH2vN0m2Chs4nDGEETNrjizJCE51KOYQ1S8qYD7QWFcx5i4n1tRLM2DuIGbOc+iG6hhQc bcGJKx8bxGCqQXUfuC8dYzxxKZ5LnoTjdTov15MphyydytEFtYnnQsXEQoGyFNNHazmCpRmTBbxS QTNSdPX0bPrqRw+upifGnQYYqadVlQnEhBsVYcJs1ERaB8eqNz4zycofQFozzhXK+QN+1VQVJ7mA OJKfQb0nXEqnYqFWlg76ft6Oq/wUshakhLnEQRenqgBNctxIzOyX4zbH5jW5P8v0smdqqp5NPTsJ xPPLMkpGuKqm5O//AET3VZChU84dElVOG8JExJGnx6IVSe7/APJq7qj3hcG3rFOnuD0r4JJmTeeg LcsnuJzmJISVHVG1f0/c/FkqXa5wl104aShaGN99f1W0C0wrm/vq+OX8opjxKX3dSvYToNQofmLP 1RHsdGn2DkzOyxRo2cQF2OXzdGFAmYzPP/5RHFXNil71QoX6kDPHsrAl+4si0nWYmkdP3fxZI1TI S2006j11c53VrngCE3ZpmcVfvMurqOf81kE1dY8AqpbxbiMI2WmzmKdk6c0casXgZQf41GncbHlO voxqOBoXq80JouWMKWpZls3nrhrmHvH65Q2m+W5v+zzQl5htLTDjeEISJJSUZpCFE9vbBQU7h3tM XdF3d/FkaqqtqEUzCL3FmVuiG+be8FOaPlVI2os0KppdUBPbfIusuA+WK0crefHIFFTSFLM3UsuC Sjh7yfRN4vthIcSPZqgY6OoQcTbiDaCg5wQY4j273W85hLdK1wqRO++bEJEJFO2HquXrKpQtnq6H GFd4bB0HNCqUjbxFB6xHs7W0Kex1elf0dPZ5ciQl3FU1z5w01Aza4omP6/z6rqEocQkNcoewFKFm 5KW0iZWesxVUyHuC3YltptUhTy+s4m1bhuwjZGuDw0hCSLVkTWRcersjm9A+jG97uLTVcrcN4S4V Tb6iQYRzHm2Kn5cDMJN69Q+PmhFJRMJYYbuSny+Al+WzUIK0/azwpRvWSo9p6ezy5C5SUrntD6dl XB21YrDhSBnlDnMa9VM5zx5ZWKZTiF1SJnvLcKcJ1WShCFUiqMNYv5imykpSqzC0T3lZyCYQzR0j j5VYy02JiWkHPrhnmPvC5jfQcbdA2dkKGdR8kVqKNhSW6+QqEKUVbItwid0IaaQG2mxhQ2mwAeCl 4CblIriD7Pe8UPtd3FiR9k2xd0dnlyCqpuQNVDlE1sV3NKZsurVOzh06RfrVcIWml5JXUjTljiuG oOuf8jpCb9AknVA4zLVCj/cWPmTOP/puoqFApKOGm1JBnsqzfJBRQ0jdOCSThGdVp+BaqGU4mwMN miLpQENoK1KsAEbu37LxMPp49zrw2/Drp3sXDXLFhJTcZ3iEtMpwITcB8NN6nQsm8yibFOhs/WAt +X+wX//aAAgBAQMBPyH/AOHq1lwTnL463ORPdONOWO5xHOkXGF9ZLJ8O52mm3Lu+ASwR7Mzoi7fM a6358eqZlqn0CAINN58JyRKmWAqrdoz4P43qh95t1p7EIVp3l5mu8Gk4bShZfwipFSGmU246kgnq K5loRG1VrdZWhGlvtzMSfcIyjWAbynyeeqN72zef+iZi6iCyjHEfPdOUeFDBpsdE01y0eJWvorq+ ofPODlYrdg2crrKKKNN42OkoJg0tQS2thDvoxj5hQix2alvm6janem8Gr6sxc1xK/RqRLbcQalSa x6MwD8yxaBlgFydoJ68D4d34vp81V8Q33lini+JpJjV59JdkX2lBMLvxNY8oRGFWPozFWdu43XB5 auxDN5p6DkvDn2kx3iq7vvq9P06fC31LAMyVH5RKxZqkpL0jezEthb3lsHcvjV807Mw3V7xbvdN1 QhRPVdjQnuW49un01MTuvgIdYwWtQlNQW6P4iWqzmqjnoGfvKlTArbc0709CHl/IBcq5WWN38NPe OVXJi1+3fpsdl5m1gV4NuNalLI5W7ZoiZDf5S0znW784Lh32mbSjjfAfBM1VGg/MR1W5fiZjY86z Tr9H79Ng3r3J4e9QxlduQvfzjhy7vvB1s0wGDKbvuhXEfQ6/OWqpsnDFNwvfWN1M7y2z+/TPomGH nyR9zesTYm9pvHYKo1gNrZ/eWcPbCZD0LSxgHYDz3f8Asxw73+Z3VtKnybprVdl+X4hG1mbgo2lk 0DUnP8O018VV61PAf4ZxMXvbvcxLGpTxGeWpt34THaCLzjC+pcRdiRjzNSbGzjTurXXpmsTmGqN5 ovT6giNZIjeAOKJwylZUBUwwI07q8EAM5SZ5v8HftnMmsoUKXqCZB9plKY09NPjPp9YxRt73tDi5 Tr0R+8o2vWWIwMsDnDf3eYPGpcsLmRE7tpjeiB8K/Ka3JxNcb16ZXVCxOqmLPa+fuR8wY1QZZK6m nRKza3dk1iJn22VXVXw2x5/K9idldDQmjr+EauJVtKdL8kVygwZIXfQ3YAhRdi2i7bCabpCz6YBu oY0bHB3c+BJr/HnK/wBwv5hN9U9Y+g2l7NKsHkfWS01m5HSqCNpbb0nlfYd1ApSTIVGMTWedSGi3 SFbAmoyeNZbnHyLL2MeDl3cd+0CpFguzFr67SrmtyOorX6XxBPIBgcHACRzII3Js4IFtH+RxJQvS D47dJamUAEFYBeq7BFqAGm3Yo6lrpeyFqIpV2pjbsNHkG5sLRjZoEvOzkYDxf9T2igElXyF+u1uI lU6uxZz089fIx4Yb2zhdUaaKo2SWZ/KgEXt5e8a5+JTb0W24uu0tjb78S5CM2TGrhoMpXoSlqmlt YDDYwuuECbIr8dm8Ktnb4ktbgd2CECAqrYfo35AKSgVbpa3f4CZ7chXyzNupJykqbS8uvScXh0O+ Fi6W6Ly0oA0y/bqEdhgoq46q1Rc1bY6GrR1SyeCQMe8D5pTK/MkxubKcIZJzftRbUWu8BPsQC0AP 4+t+A6D93pApMLPOFXvKHlKVJn4nL/vdMukz2ZeKtql0VNpZfX+g11WbyPvNZZO7O/Lgq4TYvRWm 1UmEeM7mKmr3f6EERLHUic7ABUtg9Lg2VtY4bKRb9p/kt3/0Mf37MDVGilg1jME6GgV64/todS48 6pHJ9TMbV/X7gz/4L//aAAgBAgMBPyH/AOHz1oteBZSV6t2nivCFvjqlUCj+OFeqVtQi+IqV1NS5 l4VRyyX1VjUPCkBheC9fTfqKkDeMdSrBQblkrqsXi7l4AR5OnzHgceNq4bWXsyR9fmdr/nT1UQeG qWeBVXb6+YLgwfMz2r36gcjKHh2Rh3GnP1vCKIg6gLUIy8BUZWB74t8F304Mk1MPBZrMc6RI+Fi+ mfiNPA77SiaxX2moaxylyumNxh4XHdukA0QbUUUdYYVnBdXTjoYmMcTsCBWniPnhsWvU4Q6xDSH8 fQdTYJ5vTsDxu9IBzG+kYeqlqZ8swZrHUJi9O26uYfm8aJXM7prDeYxJdS+kALY5XwTZf68+8Id4 7CUQPCtXgBBo2j4V0QeebfHMlunECTF2uvrA/jWIy8Hou6JVqL9bwWvZBWngy1f5WEu/EvoGw98r mcK/1JUxJd0T7H0f3gKYAo/u14mmn/gv/9oACAEDAwE/If8A4fHWoXCSLS3VnLxEtfPPy6o2+CvE 6259rqjRfgHjJefrqRbGEMMrhTqji/EAgQIOpuR8XkkHaVUXq8B4dEulj6ixHhDxMRYgdqYbEl+n GrH4LvAwwz3Zc3kxMrp3iFo0o8MnnhEIHUWFx1x4hT4I+J4JFdONuPDBjBLmePomZ4AyumNmH8HM Ww8TLux9pTlSzpnUWS7gQiMX4A7SzSXZxY4B6ffuDGCBgQ7tleDeSV7NI3UMU0ht3G6/429e4uoD UUvHSMUJvpXDqIPExMzgSthHcolErpC1MWQ8Dw7JoPBXgEldGFwaxMddPtLGNJUWXfhcuUyKOb7Q 6RY7QB4WRC/xslgeOOht1nElAjy/oXKt8OXQ0a+Iv+qsuBKtsz+vxz/eNRb/ALtAZqD/AOC//9oA DAMBAAIRAxEAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ4A AAAAAAAAAAAABJYAAAAAAAAAAAAAYdEAAAAAAAAAAAAEW3AAAAAAAAAAAAACNb0AAAAAAAAAAAAl Vi0AAAAAAAAAAADT5VgAAAAAAAAAAAV1W9gAAAAAAAAAAATR/UgAAAAAAAAAABfwu/cAAAAAAAAA ADy/eJ8AAAAAAAAAACI+hs4AAAAAAAAAASYBjbsAAAAAAAAAAA64sbQAAAAAAAAAAf8AKweEAAAA AAAAAAEj3lEdAAAAAAAAAACMZtklAAAAAAAAAAA7RKCGAAAAAAAAAAAFMd32AAAAAAAAAAVdjWM2 AAAAAAAAABZvh7HqAAAAAAAAATR8otHmAAAAAAAAGr6wAFfUAAAAAAAAab1gAFR1AAAAAAAg4CAA AEAQAAAAAAAzAAAAAAhYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/9oACAEBAwE/EP8A4egFANVw EMoOzWPd+pvbl1nTStdes0bNgyvQiLB2Mj7aETWDbsPxAzOLGyY9GnO969W5ojdZhhNuOfbmDBbM o2vncQG0mdwKdJjEDoqpu19Nyfbc8n59UTm3wM0eS3LilKdy8sw1a5QUHgJv2gk0WS9M+feU0rW5 zSU+c+oH9jw6p0MZTs8PU+YDbhlgBUFWrSBEq3aekGxnA3aOa5l+diOladyaPsPbP79TRE3l23va 9o0FeqZCwhTFvnpEw/soLZKGxQXjSKsRulN1ctzVjcqq7ma7e7Wq6nQaLNHSH6MykoeivMLdZhrT kYYhKi0A2O8ISU3wLhuFbLYRWN7bgsFal1ovITYtal7fndRQRbTw6vY1Yyq6nVFrHLNLR0aL2uAb W5rXclshjkEMys+4LZfyFwcpU7Mzv34iKeRrnAvecl6j3gveRom2o+0zDU0WMeUoqyhCmb8uIZFp aO2OZXKZVby6MC2USaNv3QVKYDl5YKOC0kdrZ8fv+u/RfTPTiYb2eS0Ozb0l2E1HU8a3xxDrSCkz bRseZg38yHmCKSnF40uz8S1lLKacqd8wVXbeS2eULtwDhu7PvGSgyCuCHlBe8QYbjuUZWRozyQ+F XOS5MXuxfT1GEPvIRtYgBNCwajrQ1zSMJYQoYspMcDp2vsQgVS4QwtDmoEjmlYKoS312iYq2C0av e+NI1lQNoK5hDk1AqDpHsEqqK7jbLCKZurBunxE2P+obvjp3BC5Wbs7ZXeEQChXRoSrugvTaBA6y 0usoUHTF1sRgIUGheL8sjLIBuzkpphppFii9jQ25ejnUFvA0eZ6nLlvdhlYSKzFpTz/6hgWy0P2+ s1G/ejTC/LplpsO9weriXtyUs0V25PoFQQAAPI4MmRt1lXNkWpAqcuQXmKR1cNlpsvvFAdQKZ0OA blYBrqZD6jHAuTFZMZasfTb9g8kGw6Lb7Np3fGjXppAu/nB7n4IIpKyI8GmFpbXltDAC5tuwNNtW YDa3z0bdONoWoEQR76j6ypYBfRjN1AXwGhQFG2o9obUc15Uq/J+8Ne0Ws4+YigjBtV33n1x/j0w2 kyAa1v8AtKrZaWLhr2mtttWCgxWOYAWFuWv0edXHgdItWqx8REVDkycMUUJgpLgssNkcWXLcz6Tc ZVo6m+iCW/rpgMUsnkspAAchua63l7YV02ZWAvZUh2K93/NSPP1ARnOfm4batsxZVZgxrMBsetve aWtc4w88q66ChVjoybY1hy0KUQAr1wbppwqqNUJtGx0CnhnDjwp7MfSuaR3Npd2qU3Tnd/CM1r01 EUxx0oXMeTyHjJnsmzErcVO/YxFOqEjt/MQCitarAtoN7iU9C9NtfBP59Y6DHaApxRgaMV6Chaqm yVa6XojBspAJW73KjOecO3qNa31+3TtX4h4plGCjkSXSSRtkAKy03ck0NFuOoOW42PmsC/AoK1Wl /qPDBHPuVpAU0bpeN8wUiC0oMWoj1JH/ABhjpiL/AMwcqA4OXBmFZUvMlOGst5klDxRJEdXhdQFr UnoAbUloZVcq+F3CD8GfI+lxW85WJyLsHLGDvIaHghKJRndufKcM/fpd4X1XGryAcLsEs1ErbW/o oFdhcRXT0A/WzRfO8HgyA0o0G6tA7sT4eU+hG45Zey92W6s1ZcDYd3aC3AtTjKQtvYAbYjTFNcCe dxcmRdQRyUvLx6TRU26ea+kTQkHbEO7UxNlbEwZABVb+5JAw7PSeY7Byp7cwCF2by66g6vfSPUIW LQNiK1bq4F4hVVFCb4Mg8q8cyy5TYXFAJQFYYCQvfm3l7ysCqAU01TWdJTpKhAq8kqN5rYSfYtN+ jXa+JRyq3tWFdIXclexczBUC2GbgcViDQopjApWV1D1WJXKjgo4SnObhhdnhFrajbFLQp0QeyDIB RJERU1DqTgULKykBLcmafJw9rgJlfeBb5JFBUO2WjmbF5uC7FLAG3lKwR7Iqf4g06IYRhEYCpA2m rbFGJYfv0FWCjfXeljIIg0FkFaWw2BincYlJoEip2HctYZhOAEXqTE0FNqjwSGhQmC7VpFB9EaiD dmALdqCgD+FkPE2LQnenuivB50gXfeFjXt6cRKCDILFHvOR87foR18amaKshFxxnIgP5+NLEwlWg UNACqfY3uTDugk0/j7+YAKFi1pQUA07+Bnj8STc1Skipit6uRFWp4wED9CsuhwAH8Qq6wC6NHfVB h5TDbq9NqrHYA7K48oCMUYvHYz5v+396gUAFq6BNrGfrNtixgvClsUB003BZ5IbIpNgVSMWld6hK bb+eWHErBGpArRz5pQKCFCjBjH9AJhIhYjqJK/McHS1XxG9VLqoOSx9YQUyNS1gDlufiQ+mA55f3 sFoTkArQQC6SxwwgNygaKsALay1/agoBwlwVPAEVaXUveD2ah8eMlPX/AMF//9oACAECAwE/EP8A 4fCaS/WDqjxnKyredzqyV2N4S4ZBm8bn5JivO75rqrZ7QACXAIktKczb+ua6p6uhrDUrIEG0dZTL fnqQRQWt1iQtUBtJSrSpmSsXW35rqag7Q0SyYaZuZ2eZeYl2ZuqaT6auoGyXZbzI8BgN9nvDa6zT S4T8eou60MQwSiJeuIThgKqJCyzMpV20v0ur8r3079Pf7tvOZkSMstK+vr/IlXtCVEo0egPr8Rag pttjt+WOxO80vR9Xl306cxzK+3/ZhuVRJYmgihzA4NCl1yt+tP28JvqzlfXf2jeHcyf0ekpz04WH Gn5/BEiG0Oo1tZvS5Kjrw7B/xv2RJ4Pr53ZrDMWJf6PrHTALYStq37cS7BNt9ZjPggRebTskW6Ro t6faFRq+kV4VsHa/uyzBo7xjaIxsUseu0UcMFvFNJo12/PTIVN/2QlIWiW8SuYSSNDCAef0JTt83 P+/9l6nTw3rTb89NW+f6gTce0QFOJXiufMDBRHWpt2T8cw06Gv7/AFDKCOdzzN/PWCXd2/zWaND3 OmZScseTOeOjyRzDNCjxLvQ6P4e32jk6Gv4TtC1/XtMf1z05NC528+qgAo08blRmIvJ384kuD2x/ k7nu/wA6dWSg8VqvdLY6IHahS2X6ValsDwAWx8r7obr8P3LOrfgi1kLRilenSCt91tXpeeMMK40U 8mp5n1xK8NllglvNgn8PrWUDFo9tILZlxFLwaNfq+jUJQStg1a7v69MsDYUtjbDQpgRo4T4nZTU+ vmIw8w8wDwJ1GH3S0Xd5/wCQ8SneV6IvOeEShiTT/Gl79t3EEfkOzn/fYhlOX4vaYZig9Sn8Pmd5 Tg0/jQhrfvUIFd244NI61lY9Pz0L/JbEopK0KcVuoq+OCCUHj9u3Z1YBrV93eZiMSjIG3z+P5Zc1 M/v4hLaXjyckSsQUS1en56C/KzfZ6c+kJ6X5/j/bl1mvvDFQA/pIBjR/cA3VMBAW5h05+t/hn+9B oMABQf3aLM0KPL/wX//aAAgBAwMBPxD/AOHysp1i6JyTgJdt1lUX4K8AUjLp+DNW2z46qhJZb8Ds 92PUn0eefbqu6GLLHwNFNIQslv2dTTEoFGkUVlWstWlj4Kuprs3iwA5JqEN+0UqVlbTBKz9cdQtE VYIQ3HF3anJFnBlYxS1+v46imvVzHLLpdGFko728I6Mz671rvWnn09NGMBZvw3znJKkMUUO275Rt BTjX329J3z3348/np7+0V7/8mWpczK2IBLIoZksH5eD7/MJ3fjPrtBaujgx1CthzcRXzEakwqhLU oyWafk9vljFLX69ozL+/T7FEYg0l5aTDk+qlyUR18UHtB1hbwrp096xa4PNjsHLvBEBxAaRpG1JG 4qRuQt4al6dMVrb9MG41il8CVMEXNiOSqodDvH3PmvppAxawrMmu/wCOmp3wgo3ZeXLsS5XkQzlW idn88QQS1L1vYdPR28pk6d6/Ok9XPTOImWiASH6/2ef6jV7WPgbrXj+SED2phBfrzmXX6rp3bVSx qXoc94yLK+NRZbqF5tGoYBz5n/Jjg+f304IUuXJ8aNUuAX7Rcs34lIxANpq06ZeJuvgEHqgH7j2g U0HywRmDRCVv646TLVH18RKtueTmUeAuABwRpx77/wCRFvKP3jvBDI5mZOOWv1/HRoqNZoVL9v3G 7LuPuO3aVDqafqVNZTFavBzEK3oSjFOYfTeGjw313/HRaRpzLz831tDNc8xbpgmUtdvTJ+vKW/xt eCe0IAaAHxEl1Lt6/joUz0QK4ggnXvLm/oRUK6FfyrU2cTkuqfMxCVFF+v46AcnXBLsXjtE1UWv9 QqdcnnFbzOgT02Ps/L+9FZEVv92rBNfn/wAF/9k= --------------Boundary-00=_U8IXI22JDTD5BHK00000 Content-Type: image/gif; name="Irritating51.gif" Content-Transfer-Encoding: base64 Content-ID: <14EB431C-1565-DDAA-7D37-1FDB0C4E000D> R0lGODlhRAF8AIfoAAUAAIsNAACNAHx0AgABgHUAgQ6Bc722sb3auJnJ/UUfAGMXCI0qAZsaAL0q ANQoAgs7ABU2AEszCFI0AI1DAKhOAMQ2BO47DQBSCBJqBDJqDmRkAIVRAKpeAMJfANFTAwyCAS2I ATGHAGN/A3R8AKaEAMx2DdJ/AACoABagAEWbBFOdAHGiAJKsBMuTANyUCADJDBG6ADe5DW6/Dni9 AJjLC7nMC+SzAAXWABPpBkDfAF7ZAHLaDKjfALXoANTWAAAIRCkJRkQAMVwAOoAAOJENNbEAOO4A QAkcRyAuRz8oMlokO3IVPpcoRMcgQ98gQABBRR9LM05HPWpOOo1DRpIxSMo5Suo4PABiQCFmSTpq RW1dO4xsAK5cO75YN+hTSABzOi16NjOCPW6LO4l5PqeAPsiGM9qGNQCiSiGZPT6cR2qkOnyrNpWb TLirOuefSADHTBOyQEe8NFzKQI3BPpS8Ps7KTda0RAbgMxnRTUTbTVvePn3ZO5nZSrTgP9biTg0N jiMHiUcAhFgIhXIFcqQAe78Ag+YIhQYWfhEeek4reVQoen8sc6Qsh8wajuIghgtEhxoyfz1IhWw/ gItKhaA5fLM1hdFAcQtoix9pe0RffGlchotkc5NXhbJkd+NcfgCLcSyHd0R0g113g4qBiKKEc7N0 eeWFfQmdihKWgEKRhGGbcnGRe5ani76WieaUgQe9dBy5g0HOiVTEgY65gJzBjLi+h9zIiALidCbr fEDoimDUcYjrdZnSdbrsduTZhAAAvycOxToLtFYHyYAAw50Ax7wAwdsAtQAswxQouUMjtmAYsYgo xKUswMwYxdEqwAA1xRw7ujRGzlY7tHNKtK05vrxNzu5GyABityhjxj5rxWFYsYVkyZ9kybxRy+1S tgB7tSt7tEdzy2V3uHJ/updzvcyJs+BxuACrwi2Ys0Kjwlyaw4ObtaieuMKjseGYzgDNzRjLxEO2 w2fItYfIwZ6xuPX+6punonOLjP8AAAT/Af/1AAAA//8G/wv/+P7//yH5BAA0+L8ALAAAAABEAXwA Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnCjxn8WLGDNq3Mixo8ePIEOK/EixpMmTKE+OXMmypcuX MGPKnEmzps2bG1Pq3Mmzp8+fC3EKHUq0qNGjSJPaBMq0qdOnBpVKnToUqtWrWLNq3cqVqtevYMOK HUu2rNmzaNOqXcuWLde3cAu2nUu3rt27ePN6jcu3r9+/gAMLHky48E+9iBMrXsy4sePHOQ1Lnky5 smWCkBdf3lw4M17Ofj2LHk26tGm7oFOrXs26tevXsBOaBQCAJT9+o2Pr1kq7NwCUBAhEpA3V90Dj A4MrF24PmPPnu6P7dBkcY/WYtFlmP1r7Yvfu/8CD/8c43qj08wyJH1Sv3p7v372Pvyc4Xz793zzx G9TPfz36/zu5tJ1G2w3YW3jZFaigRQaKN96ANZXn3YQMbiShSwBmKNF7+rkXn30eCsQef/i1Z2KH P6Eo34ceIsehhjBedWJ7IdY4IogngsiUiiLS1+N+MQb5EE0NQrggggw6mKR3Shp1YXjkVUjgaVQu tWGHNNJoY4lc4kiijjXm56N7Y/LIo5BoovTifQXduCVyIsIZ5pw7wVkfmfvdmWaaQ0FY5Z+AEuWT lqopYOihhrZoHIe/BeDoowHsKWlPjk5q6aWYBWoWpjFqWhOnoAbl6aikprWbA3wtMFmkol60QKlg Of8g66xpBcARBCzNSqtItkIZ5T8MBBusRgoxoBOLAwVLkLFjhgpUjglBAMFV0lY7kLUIUaDttgIx e5BHuFrEQEbjAotRuR9VuxEGHXFI7rvmxpvRk7AWJYAAF91rFgr/8LtRuP8G3BK+FgFcsEXsXpRw SAYjSK+/t2aU8MQbEVwvhhJJe+209lSrsUAooDAQBiSTPBAMKKNcEA44PDQtxwbpkxAMB4Vss0Mi X1sQxzSf/FDObSYkgEIwCzS0PUMfXbOzP5Vc8kA3E6Ryx0ULNLU9V9vDMkQmH1S11Cn3bFDLDAGN 53FG33svREoThMHMYQO5cstkb11Q20wfa6aKIQv/9DFBf/9NEbYEkZ3eQWITLXVBPScOkdlQO1Q1 5AQlbXRBMufNk+BQU7621oavKOdEjRdEOUJf23N6zARBnnPqDaWOd0KZR+6137gXrrlsLflpkb4S J4yyRsDX5C/EUoIU7sL/MN8RDhnBcJH0v7/kvEXUK6+w0xpB/4/33l8U/sUrTUQo1QZ9nHXaA30e 50Nqu0814XAMBAZB9/tNOEN4q105QxoJW/YOhpHsGaxhHHlQeSxGPrAU7yJgAMNFgEBBCk6wgkDI iAVXIsGQZBCCEewgTBh4FAx+8B8idBi9tNPAluwGCHGBYXSYszuEtPAlCTnTamhYwx768IdAbMoN /6u0Jx0G8YiTOR9FeBg0JGpOQIxKiu9e8p6MXGeIWJTKFEfiLosshwAX+SKTeuereZVxJk4EFaHu VB9oQYtOSlQIfOSGoiza0SMmieOb2PS+ML3xJFrqz2DueJotLglJ5GlSFA9JpCIdiJCQjAxF1thG FLnxTHoczo+alcZO5qlNX4Ijl7rUR1FOcpNoi0okVwnFeX3nSIn0DZMeOcsxakeWU9qLJ6VDSRcZ MZODshQraeIXYPbEiLtM5k4gxSplOvOZ0IymNKdJzSMO85pSyQc2t+kSWYlGAdyk0kRmRRByRkRW EEHnSYTlLYUoYCDgBIkDwolFYZ1rWLdcibZmIv8ekFDgIv9MHi3/ua1/VBM9vmyPx2C2UPYhTWlO e5tAItq+2S1EovbAqNBSCTidoS93raJnXUiXMquV1CCfQxZx2tM3kAFNfhnVaOw82rGOWo2mZJOQ PjCyU5HCanhh+8fwNBIyixQVI/FDqsWKZ8iR2Oyo/2CgxRbW038ArGQXQR7yfMqYifTtqaoDmgB7 xrn9YW2sJ3PcRNp2tKLBTJBYQ+lNfXZQyrhEWgULF177BbGj7vUi+ghsVa2KQEbCZHze02q+FDY9 Alq1eovlqmPMR0o3fail9mmP+9yHWZdGxK1zDS3MgIZRlhkOSxORrKkksr6zVjR+Jt0Zx/4GhdrF 1haU+mntQmx729BeTWxvFYxqBcWpENojf2QS6HD/VFeeLFeXzbXrczES3epa97rYza52KTJdIm4X id2dy3f/Et6M/LC8gBqveq+C3rKsVyBcfe9k2isS+QpxufbNr36lQ9/PVLO/AA6wgAfMyv0aWFIE TjBqfKjgBoflwBBOrYMnPJUIW/jCGM6whjfM4Q572CkUDnFSPkziEpv4xBM+sYpX/N3usjhAIiZJ iWNM46q8+MYQrrGOd8xjluD4xxjusZBdEhAAOw== --------------Boundary-00=_U8IXI22JDTD5BHK00000 Content-Type: image/gif; name="imstp_usa.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlh4QFQAOYAAPONqgllpNMPHQWvEqKgl5IGCNuna/y2Ae1GYc5XBf7+/vmaBPruztPn+9HQ x1xaVv/yAP7G0u5uf+cCPptADv7TAHciAf2quwUFBe7KhxfhlBtTSv/7m+r0/QCh6f/2daWJT3pW LXb/zX99df/63b+8tfLYp/HivJYGRQBzG+no44rG84KqFgLH//3SMeiBQNPtqc7I2f6sM2yo0bz0 /v/3Ms7/6fvb4w4lgcDc+qamwd7d233k/hWcfOV9BPjx9O325r3KPO/v7EyRxdCmAv///wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/ C05FVFNDQVBFMi4wAwEAAAAh+QQJKABFACwAAAAA4QFQAAAH/4BFgoOEhYaHiImKi4yNjo+QkZKT lJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uK4ru7y9vr/AwcLDxMXGwLnJysvM zZkrOdHS09TV1tfY2drb3NYBzuDh4uO4Kwrn6Onq6+zt7u/w8fLs3+T29/j5nubz/f7/AP/V00ew oMGDhPh1WMiwocOHECNKnEixokWG5wYi3Mix4zKFF0OKHEnSYkaPKC9hWMlyxA6WLQXBZLnj5UwM hW5i2DFJiIMiDx6AsimUXFCgQh/gTLSigwKIMBuuXDhVYlWrGKRmLcnw6sWnGlOKfYSBQKGXZgWN wFCiCIaihP/QKnqLSUjZUWuF6DuqVFHTpw6rXvU6kfBDr4ZHJp4IdqxjsmkHyR2EYYRbuJLvJqJ7 aXKotQT5LkX0t4Fp04i3Lj59ejXqra9Zy55Nu4Fr2o0f654bWZBnt5Y5x9WMSPggAm9XEkBeWS1L sy2PAl35QC/z5i+VYtjA87rlQWtX7nCwgbreB+WzqoX7wHL4u8h5AndbHjN56jLTcy/Pvcj1DT/x ldRoh0CjgGwr1ZagbRi0xpKDsc22YIQMTgjTaxY2WFttB4a124cywSSUZ0q1ddOIN31H2UxCISfU Wi9mtVZbStV011FrOeBAZSU0hxwBL20gxEsj2OUeBj+Bh5P/XULtOKB8guyo10sOzDjdDvHJFNwG hTBZBJFuIWmTA0QaWYSTSKXZF1MNHMjahAhquOCccjYI55s6RUhnnXpquOFsHYIoKGW9fXlTWsb5 RtwhifqHpKM/9bjDBnBVJtdRlBICmiDogZnmdipqipMOOzknhHSENDcCl5lqmeV8zRFCapKgccYZ qpwmpet0fuXgpjR3AstnDsFeeA2cdEaTrLLDBqtNoIMKuqihZu0opEyYKVpoTtk62l2pksZ62aVC GYdqjZodVYJ2D0BZBGibeourWqwGp+JbrzY37XUsXYZtrmcGhZ+AvDLlKzUrHYsBswwjzBI2CQvL LEwNEztT/8XdKJCDh9E6Nu1kaPp71rTcGpJllpK2Chy5Raj87midpouZi6J6a+q81JaqMo+lmrmv eqkWdWu7b7WbKcFrknbwNBE3HPHTCztsscJMR920xBhnvY3GHHcs1sfEraWDyMNtG7TJpaK8k5VK /dQcjkgy2aNlyLkkM5ieOleEl2jiPF1RbCO5o2VKBVeol0JkamtRQSH3E4xqdlvg0lVXDLXTVi98 deVYXz415t1Yw7XXH4LdW3k2zQSkTu7qtFza4Jb6XlqFS6ddf95RC/B11dV8Znq9+/2jkso5l5zh hty3HU+LA8xuX0gTaIiB1lDcedQWN+251Fhnj/3V1n8e+v/opJdvPiNSkkN96Oy37/7715B//vz0 A6w+5fDnr//+1MhvyAQADKAAB0jAAhrwgAHsRAgWyMD6OfAQdinV/TTGvwpa0H3+GwQAEYAAAADg AiAMoQhHSMISmjCEHuRgAhnRQEQskAEwPIEMQ/DAGhZkfRfMoQ6z4aEJIEACIIyAEIdIxCIa8YhI PCIIAYAAAC4iBDGkYSFeGEMZWlGKNsyiPQLAxS568YtgDKMYx0jGMprxjGH8XweTyMY2ulGJEnBi IqAYRQYu0ARVZIAVTWACLGrxj4C8hQ8v8MZCRkACQ0QkEj0IRzkego56zIAkJ2lFPfYxBJLsYyA3 yUlY+BD/AG2UACiJiABCIhEFo0QlEiWAACReoIlzJEEMKcnHPWYgBAYwQAb46MdO+vKXogDgKNn4 QyICAAVsVGUElGlEVibxAo6coiwtWctqzjCXu5whMLfJzU4M0o3FHOIxk5nKYRbRmUmE5SOnucd2 9lGX2bzi/CxAz3ra854W6KY+MzEBRbYxnEIcZ0A56E9lKpOJazxkK5PIygmss4ru5GUmbdnLaFlA ADe4wQkR2kR67vOjk5iAOdOpSACwEpmHRIEEJICChRoUlMf8oSrRucg4PjSi1ZykTrFZURBZIKNL 5OgEBEDUohIVgB59RAI4mIAEgBSYEzDlP1uKgpYiAKUq/02pIl8aAQ4K0as0XaVDDUFHnO40l2hF a09389MLeFCoATSqXAUwgXw2ggIrXSkC7OpTvj5VEiJ9I0FHOc5jsjSrQuSqMp0ZViOadKyEgGRO J6lWO1r2sh+yACE52kQBznWufk0EBQwgAQNcQK+hHQs9I5DavzoisOD0ZwQK21LZLrOctxUiYxe6 SnVGdpY6zUAuGTjN4hq3uC0Ui2Y/yMHODvCzoGUEXksrQ9QKggLYpQBKLBCBjLY2FmgMbxcRSN7y buKbbWTmbLFaUlVy1auGFSxkB1HWsxqAiseFoX73y98FpmS5pVQhAaEb3UVYgJVAJIEJVpoACoDA ihnALv9HfnqDCPzgu7AQr3jLy2EDnhe25DQmSo9ZVcRy9QIlXuhKnxnNIly2nsTNLzWtac39rpUg AA5wAQlcYEVYYKk/JORpEwACDhg3AyDQrkF+amEJ7EACGHZFFxfiRSpPuQNVxvKVx9vhLq9QE/2U 6ioda0xzDtPMZibiZdeM1he42c34Zac7g0vneDLgxvnI8St3zGOjRnkQPyaokBNgABJMlAQKMLSS cayAC9wAkTH48ye4tIgtW5qLVsa0ljXdxYDMgxMABKIhR23IO/JxotbEpQHeDGf+zvjUdE4rNnXK y40sF6F7fm6f/eyIQAfZBAgosnBzeQE8KhrHN2j0o53/LABJc2IDlFaEhsPraXl4M8ykzjYbQwDr Ot8yl6yO86u7PWxZmxueu8QzOXKsY137GZ/wLoCBgQxECTh42G42rRUXfQ/N/sDRERBADABQAGcX AtqSEFK0EwHGTAfA4RDfdKdHgA6KV1sdntigqLXN8SHSkbJp/TarE8Dt/c5wzQs8t8pnrW5x3FqF uY5rUet5QhIKoOCJ8DWDQSBJcLu52LLk9zi4e4EfrHQHBZBADApAAYMTAtoIb8QGNGCDhSOi4RKP eJa7OIKuU9zrCihS1wE4Ai8LEBQb/OEHa852ERbRhAAo+Z3LPdwQvJnkcochAxfA9777PeUgCLzg QaBy/0m2HBzsjqpzh9pseqIwhQIeYAdDiPND+JqDPC/3mw1gbKGH46cAEAIABPDkAsSgBAXQgdMH sQERiCDqiZi6Bl6/CGhPO4xgX8eQVMD7mjwAgL83ezDNTt5SDhGaB5R7ymVtRxnqd4F+X4Adoy/9 EAz++uY2fEESH/PGPx6u8K7nJ0H43UALIAEsyLzP8110IHi+GRY4ByiFIIASLL0AJUA9AJKac/5D WwRVB3stA3UEKICCUIC390Vdpw67VxMO+IA68gAOEHxd1gyhZkrQpAh5B3iDt4EhQH0hkH/5ZwHU J33XN3jZd3jw51bNpXhIFVRv1YL0JEscQAEFcIM4WP9wFjB+5ZcAE2AALMACurR+7HcCJPB+ocB/ gLZ6RRB/jeZkCCBwElAACFACo0cBAVBPludmoTV1ANgBBOh6AGgDZKgANvB6BfiFXHJpD5d1bmhx T9F7EAiBOlKHDnAOD9APzrBBm+VbjwRJd2ZZzxcCJEeCfReCIjiCB0B9FmB9J0h4zLd9LNhZe+ZW b8VZdWUBEMABRhZ0OZiD9DR5qeVgBZAALhAELEABPcdqb+ZoJ4BdTdVUoEBPPoAIPqCEPhYB7VdK BBcDMYACSRcDO/AAXmRPgMaFhiB7rgdtGtCMzuh6ZdgBVSeGGhB1bKh1U2ZxckgmdtiN3Zh/QXEO OmD/bXu4QR7UYmQFiP31gQkggiFwAAfQjvbXjYbodw7miCcYiTjGggEEg5y1V/SUABAwkNlFAjX4 iaAoioVAARwQeDXwACzwAKooXKz4cxRQARUwkJzoVJ1gAbW4CLfYCERnYVF4f6d3g07GAzywAjgQ AEMwBFxkTy/wXcwoe9VYgAU4e7K3cAnIRRSnAl1nh4lYh4lYlOD4ADowjvAgDgXEQuoIfQuQAERZ Au8olXeoABiADvXodxbwiIGnj/oAYIrXggFkT1ipAAIJARSADglgkDaIkDe4g3u1kJIUhNUBAxK5 ihVJAQsAj/BYARzAkZqwen8WfzdgUkIQAaaHAPhX/wJRKAAI4AEuiQMz0AErEAAzMAMxOZOxt5Mb 4AGg6QEbUHWhKZqtZ4A9qY0OQABBERRG+ZqvGXwogECH4APZhU+VUFWGkAIDkAKEwEWgYFk+wHdW uSM6QpVSmRFnqQA/5gOL2JcL4GBeCYnDxQm2iV24SQoAhlBlWU/pkJUBIJBrmQ5teYvhp4UL+QIG gIoPBgLrMpGrtpfZRQEaKZiXYFfXeZvoSQhR5oSHBABIJwGohwCnR1QW0JJgNAM0kIXIiAhT93/Q FpqnWZqj+aCFgHVbt2VF4hMlsBxCsByt+QCwGZslRl4L6QOdeFy2iWEp0KKGgEzHVAS6yZsDMABe xP8DLdA1m8CXxKmcWakAhIgOkukB5+CR2DWcz9mVXqlWO4qiMraio7BcyGdPizieQhoAHtBg6pCV CVCDkUABPrCe6UcED0ACDpBkevlmtgmYHKCRG6kJYJqi/AWlvZZsCiABAicASneD9jd6LTkEChAD LXmZCGoBnImTUFeNoNl6ztiojdoDn/mgiDqpbchFsdhgFHCcHUoAH7ocnjoCHTqiifgAJTabHnZd TmqQnPgBEICRrhqd35UCNtCivikIqORByNRENBoAKsmrLSCZwAkKfHkAFeAD5zCkRboAxnqs55AA PpAAHpkAFUCsFaCkj3hfKihdTkpPq/oBH1AD9AT/AbCahORHTxk5kNMaleqQpdH5nQoQnhnwkZCQ AOoZeAcAAjAABCUwAvDJarbZl35JrANpn5MQpwwwn976rTWgltnVaxYWcDHAQTFgg0q3AzrQkgoa AJQ5A5NqAwtBhstYjRrgAY06qbK3qNUohmQojWhoe1/UVBzwAS7gAvCIXfnnoZ76qa05AgQgquuS lEnZDteVoqu6sAPZqhjZqgvQWjRao7QqowjFRCjAm7xKAzmKo76ao5BAT0q2nwtJrG26rESqABTg l8t6DmAKrfDYqtTaiCiXrdJlZLQYs0Z7tOZZAUs7i+Y6rRm5os4Zj+RZs+kwpAmQAV4KCWDqZidQ /wMU8ABBEBRoSpGsNp/h2qqBWQkMCUNWSrZHq5bkKZKiFKCoZ4U3GANCwANchKBeNAT/x7KOKrI2 eZMbQAEqagEb0APOyKi5C3Vj1JbeSrMBW60PQAAF+KnL4bPrgpRA6w5FkLkG+QExe7R766oYeQBM W6M1WlXHJLVXVVU2iqMtkKOgGb6S+QgeCQFH2IQQYJuHcJHRq6zoMKzP6QPPmgDKagEXeQBsi5FM WLByi6LR27mde4vT2r8iaQHVi5HmaQHUGo+xGLAJMLiE9gLp+6U+8AIS8AEVwAJEsAAsAASRG59q GqYnoImuCgEE6wjOu7loS5DrkMKWhwA7UJJMF/+xkKkDQ0ADQ0CZHbDDTcGgOFmyGoC7N0m7MRuz 3loDRru0t9uMkroB14hlvjuz1ltPftm4OUu8lHK8+aepsKm8QcsOtEuDAXy0/IvArkqs1nsINAqj HFSqMDoBWFqaRAWawepj+cTAgKldmljBC0kC3iquUYldfTmtz9l3t6i2Gcm31WoIOAinsmQBNZhd Asyw2AUBCLzGnoDGxOqcA3m+bLuIAbuIEdysC+Bmfoy4L2CKHFABNAsCOZABeSm5atp0rdx3gAnD irDC7tqsVvqjzcoIFwUAS0e69heFOJDDOIADKzADqsugXZiokAptR8iJ8ynA88mM1TgIUTzFh7z/ tPVovTybxTzbxUJJonBMQM7LiW1qxouMt5zMt5pcBF80AKjUXChAAhBwAPeMAvQ8xwIgrgJAA1jr Yz5QAU0ItnxcAR/wfgz5AfDorEhKvX7Jd7dIeHpsyPwrCDdYBAUAmYwpb5aQuZK8ufR5tJsrkJls wAaWwOeKyT+mv9XrlzMdi3y3aqmMuJiqxBUwAjkABAQQwpMLmHibXcSqy4jgvCbwy+/qy+cAnmwp aRc1sQIHjKaLAM/ckjyww5tJk5AKqdXc0Olw0p4bv7a7zYJARt78zdQnzl7XdT07j+eMzlWlzp24 qp1Lva/KyQuAkXkbAOhgtQFgz6W6z1almwFA/9ABvYgCAL5aiwh6nNB73IQM7dCAfAC2ab+FPNPK ml2QiMYa3chUOIVERVBTiLl3zdScW9bAnADUmrecEM8vbcXoqteGPMq6lNOIW9TYFbM8x5r9yoUA SwF81LCPoNRLfaVjq6UKgKzNGpI+hn9Lt6cCcLpcxAM0MKSSWZmGypmHwIxgHbMszLnj3XSwp9Yx m64l6HeY7QNG6Y1ebJSkWqIC5AOR3M7ubNvVC519XQGdRgNWm6PZi1Aphtjg6wECsAACML7hq6OR rcdeisAN3b6XzdvzeeHHGwEmQACc/JfVeoM/FNI4uFIiLQn27ZboANVoOZ4qjpbUioSV0OGzzf/h HqnfFH0AF5kB0Avj0jWtFxmdFfAAZEoAI6B+bnaL2KWeeMTjFG5JOD64bGmlY2vKTN6EpkdwUCgA KMBFDb7MKECMLWCoGDZ14S3WKR6/Zx6/sPcOCSCzbL3eo9zePkAmdOgA8v2zYRy/covfSOuq87nf /L0AgC3Y4Zuj33DPV0XgNUrPOCqZPFCaoengxCrZXuoDE96+DM2qeMsBS5uzx2mEMEQArxjK1IqD HHRzRvVDp/2lRsYBEYYOXLTc4xnrbMl38BzbM520mMzhDpBdABvnmF3jH6DbSrXPDInjNPu4QYCX wX3BL3DBnGcAVT4ImctHhlzKgVsB2M6Wwwn/3T4mhUn3AwFXVDcoV9DsoCIwxBuQ3kwN2GT71E2N tgsQde7QpTS73vjO3pj9gA5o5/INtHmuAPYtyXlNvSYNj7bOd4NutXakAJcpoxNQVV3lz4s+x9cd RrT6tNROrGBKrIx7kWqZ1CjKquhqzQygex56sPtM0weAg0SVg0Wl6iXuCPbt6q9+rFjq1M2d86Zc yNNuvjMtsLtuAXT+iud5kdI67D9/CAKJ4xyA4wbAuF2Jl/yql/Tr7LpkbyrMAOl929vu2mr89c85 zz4mwwRX3edwWqKWUXja3TSp7un95OeQoy2AtnMfAHUv7xZa7zKb734fnRG9jePh70UJxmHM/5Ak iN96Xd4Ij/CD3gIhoLQhoACCXQQDAPG6WfFcpJwZgb3YawNOy58NXNsZCeMUEMi1XYNZ7KnncLAZ Kcr6+9EwL9Km3lwdfVdGJkkysLlTztzNTZ58R6ywnQkdTq1Df5VWpCM5K8ltipEavPSG0KU4buzY Bc94CdxW7+wvIElJFrcM8AF++7eXeuOXuoiG7O0+NgE/8AOl/Q5iju49AKka7OPpkPfvPvfAP++v d0CmCAgyC4OEhYaHFIQ+KjuNjg4lkZKRDyiWKBMTFCQ+HBAQFKEVowkKpgoYp4kLBwcLATQtLSGu PiEKsQFFAwEtsAHAwDQ0AbjFwwEDysvKKf9Fz88WraOfB58+PtDa0QWf3hUJDKfjpgwUFRCurBUF AgXv7gLu2u/12/famxwZGa2l5D78kVOQoNAoC/gSKoQmrUKraRUoOKBg4cRAUycscNiI7gMHHxQW ikzAAV06Cy80HqBQggCMDA8o8DPwoqaPmi8yvAAhssimDz4sCGX18OEodEePFnWIsGcRCwJuKLjg rp28q6ZQNr23QUOPDR8gOHRFYWCisuRWLei6IZPbtwlcqCsUqq7du2pbCWH0CNKkEg8oWXKrr+Q/ BefAnSqWSoGFQa0GBQsBIEQIWbJ0BeDRwgMPHpt9mSJW4tiKZM2WOdsm7YDJdK2w1cX3zlv/tU0D GSQ4lw4yvHbw4s1zqlBfv8iHFQR0fSB5QYMVthIXSQE20YgOdle0eOrECQIaS3768CHkdHwkIXA4 ILTkSpIkWDwAYWEmzvsZQJgvziDgp8djTePaa7YptcBB00ElwSk3XHDDDQAg0A5KKeGzgQhegVWD XBAMkpxaaJmSSAWsbNCDCG295VZchoRyyIuGHJDBXnw14tdfDzwwwgiDacLRYamcc5gHAXgg4gK7 +bDOMcP4EgwvnHkgD2ZEAqOAACRSAMxpqDWDDwXLoXMASKGMx8k97xCoHgXhMODmbsypE5xVBRQB HAISnvclCftUoEBkoWBjlCu7sTmIAqwc/xidniI1pE4rFJyQgHZCVVopR7YFxeg9JIkn1gIUuLAA ByQQ8AAQMdl3X04G7JfQT95YENAoRlFj262tiCVdT0IJgMAFETzIoABaJXThV+SJFdkgdj3EbF2F uMLWRYiJSohaMMLow4w01ujAjZI8oMO45CIm1mGMIZackSK6IhSYFcCCmS8pLFOklCRAIIAH/MKC iwALgDQaMl4m1FoFH21UzUOuPgOcrR2uV2gC1jj7DgLyWDVPOxJKUOem0PyUgbLMrifrrMsWwg9E u4Kcj3WsRCoppZZSoHCBDbuc3qcUgPBBBRkoABMJMIxQXwY04ZdBztvYHNYnFCma1K1Uw/+mK6O9 XiWPVBS2XMQGHYiA7CekJKAkZESlfIi0GqB4EQWCMEtXpXid7c8i3XoLbiQ6iEvuuNUpZgqRRlIw 5kDPpaD44ikEAwwzygAjQG/7+ksMmAI8AMswxAywmsHTeLLwu6GgmXEBSHWo3kbrRXYxnsINVwCe EtT+jstOZ0ArpCcJuntRzK2zqMv4OPooWpNOSvfN32hKvDYJiJWlAUDUIGMFDzhAQAksyKTqCwYs TR0DT0NgQQINQVz1N7kOj7VQN0jgzgXFWojh2Oc+ljLwaj+61okbeJs6VkERC5DrAQRI4PZKEIrk VUAFedMbjsblN3IFzgfjYFdiMHgKinn/KAU2gJwIB1CXF/DAcAsQAA+IYYx/GcNxlqDOrDzxEK9t Y3Z4SpNSirIAeOAJYxobjp1oVzuP3U5PP/lZgKrDHmwkJUBxYtnzineguaxEAd7JIgFsJjqykciG OisJqChAABe4wCEsAMEIQBCEEXhPVeJbiAXIFyvtyeqJeITU7q5GPEt1zUJhy9DTlPSYtEFkhzys oolE0IEUvQWFY7TAJS6BQAVK4luOgGAEbbQ3wFiCR5jQhFgMwMFTYOko2JhUZNylOMjVRRkUeAEC AAAACnSmF57xgOZ+MZoASAABKFBABIDZqEAVEIz08BXs6sHMeihzmVr7GDRw+MscbiqJ/16MCASC 4kehTC1ACJriPR7Tm2th8Vvg8RRSvihOTimrgSAgAhEoYAAQGIAFLDAaPfnBT6ZpwwIVKJ8F0Akt /j0kKD4YCx+nKJQK2e9+YPlGRNL2TTwWpGImapsjCTPASU6ykgssASYzuUlOdnKSE8CE4chTgVIC LI9qs4BY6gXLCL2AAiQcxAtq2S8q6aIIViJGNVEQgV+igDgN4YA/kzm7av5Qa/L4ITSjiaZmguwc yfKG4V5DHvJw4mTSqxUy+6ioudhFJXhcwFiJl56QsAl89nwAPvEJA/1YwADhi6NCZMWBp1mAADtQ gPa22E26/e4k4myoQ7cBNrEJ8lYTHf/Q+tABqlwdIKOM3GgmzkIBj1LSkiIdqSZLyslJBAalKQVT X0mUAHlILSk8dJf0FEcBALxAUbypgCwpUKXOeMAX71AcMIxqCQQYNUGuUapI6GRcp0r1uVVRZsba eY9A9VWrAwrLE/8TsN8xZ60uKyTJBsG61g1oEOBlawJCBr78bIAFBBgBB0owgtpZoGdLzUdWKbAD ApxiB98abAIfUxIogkKcZOSAUOzXNg0IsnxaTR8eR1HZXJmoB21zW1pApYC/lQukkcBkBEn7LdPy rVwdpkCyrDgg2PJQIwEChW0XAAHEvABRoQBGNxxHtgIoAwXAVEA6LnGepObXTlchYhH/l7xMq8Bu utQNWUlUXL6tQuAD/MPGycZClANHeZwjmvATQZXeKMcSryzIwAlGAAQ1SsAAtUOfU2Sl1cAm8CI7 4KJ3mTJFm1nPhhdqcIZ8sL6VGM6gbKrVhb2SWbOUxcOnAHFoRztivd2IgiX42ynoDJtaPdFZavXE WBxCAQTcNiKICQXjUDcIH7C6hz+2RG+ISkzkIiy/QVQyAIqIMag+VYhmdg+nQTGg2HDTUk5c1ne/ bDD9TZgsZWb2mfkJgh2MYALGvQCcJXDkZ/BGLPw1hQLHvcUCr9Ia3e7JWYQiZ8aGDcMO/opM17ce MtFtqwq1QA/23WANjyNEmjZFJUPs/4BGVPoHmwyMJHQwgkyjWERIeRRMPQRjhzjEyyWMpW4pQFNW JyBNg/BxMIt6iaLWGqmu8bJCcv3cXmtNqlA2M16aNTUI1KC8pGrNo9DNbDkWtlI9R+I++5kAPBng AiaA81rvSLZwU2sHCeDyOtjzvLMogIa7aqxjHWwiplcN5xJVB1P2De8TNVJFb7mEWyQt4m4hXAin imD2FF6CT3rULXd8SAEG4eIe7l3Ug7qvqWmMGCEv4KbLqEe+9v7xARC1dsCU6lGLnHJcxw6qvoY5 sMWJDZx7XnRQ3O7JILPsoJv+9D4ZugWkaoAHXYDbvDpQ0xMQWHLkGdSuUWvVQaFz3f9ro7En4nqG ALQ+6f2OEF8ke1cYnVm0u6VHE6hkwzF5qrjHHe57qX4jsoeCHNVd7SkNZSb0h6TzkX6AB1CYQ9ah +9reFlQvINECEIDTAXSDHZ+ox49NDsxJYq3yC0EnmPdy0LV5COZpYkYNUHRQo8d+0YZ6EKgnhUIR k4InF0ACSScBS6co70R7jrAb64F8HfKAxVMWCnZfLXMhjrVvXcGC5HQUEgVFIqhWZIdhXSE2zed8 KfUW0hdalYACbIZ9QmAJ1/cAjvCDQHh30Dd+rEVmfmQ4oOcK1uB7tWVqbnV4s4RT9xcw73AgsOZ4 RPY8DaFypnM6zhRVzfVkR/RlsmL/UG54FIUVMEoyhSQYgXaoJ6tHOxfweho4ZxxYDROTfoSQcr5H PIajc4jFWCKwgl/hFV+xAQDyaWrDd190YfyWUSfib9QicAk0AoJVcH4zAo3QN3sxLjuiAztghAzn YQGnA+TwFIPgDZ9HMuclHbPhba9kf/L3cXznaqnhOQwFgLTRcrCjZLVzOqd3TN1kF8txSAchhwnF Tnc4jUGXh831S+kVibLIOh2yDp9Sh9UlU0OBXlyxiMuXIRmyAZBIiXFyfpSlVpZog/CmghvgFAg0 As8gUg8ADaK4j0VwKvdghEWAj1hDNd4FGd1YZsqwd1yYAnuHDT7mOcCYWMJ4Q1K1/2QYCURrSI3/ RCbNyIDYQGjkyJEkGWWrx2vpxhAjIlHfwDPgWDzWYD4LxhUOpgHnWIPqCImRmIDwGI9kJ3xc5xQ7 og0E+Qz9CA3+uA1FuSn39VqIlHsUoScL+Q7NYA+p8TliWJHTRIDG9Wv2UJIlaG9+5ERZ8pJgeZbQ U0ApyRphllZRyYaRAUbneI6O+Ij1WClOqVYLlpPqyG9AaZPEsZT4IJjVmAgtZiAzySgT6SXAyAxY mZXo0DBBhHlfiZYGAyYhmZmEZJaW2ZmJ9XOc6XNjxZekqY7F000KUZo56Zl4CJrEw5iNKZEF005j mDPNZFWsKZqFlZu82Zu++ZvAGRycwjmcxFmcxnmcyJmcyrmczNmczvmc0Bmd1BUIACH5BAUoAEUA LAQAAwDZAUoAAAf/gEWCg4SFhoeIiYqLjI2Oj5CRkpOFK5aXmJmam5ydnp+goZuUpKWmp6ipqqus ra6vsIMrObS1tre4ubq7vL2+v7kBscPExcbHyMnKrisKzs/Q0dLT1NXW19jZ08LL3d7f4OHi483a 5ufo6ejc4+3u7/Dx8uUd9fb3+Pn6+/z9/v8A7TljJ6+gwYMIE06iF7Chw4cQAQ5USDEehosYR+zA mFEQR4w7Nn7EUGgkhh2ThDgo8uDBK5EuKxJqydLlA5KJVnRQoI/jvYv1gPITOhTDT6MR7RENyJOg zKfeMBAotHGqoBEYShTBEJNQVUVcTwmROgyrEKiGaN5UpJMnPqFE/5f2k5tvKd2Hd/s1Rct3GVmv fz2O2Np10NdEYU0dhoW170ybOBG1bUCZsl2keStXzmwZaWfNoEOLbsBZ9F7HqIkFFrR46+DEgK0i gj2IANeLBGxjGFwEK+6tF0fQZHnxwVndu4tsvIlhA0rkvK+CdLCh+NkH1Y1e7fpgsG+ytlG63lq9 MPXiHrM7r+68CPINK9VCZttAAeiLo/GTxrAZY//PoekH4H4CctRZgfyNNpp9TqXm4CofubTYTVqN JOFI0XkUoXthYeWSWVhpdVNIZNGElQMO7FZCcrYRsNEGQmw0wljeYbDSII2N5VKKkIknSIpnbeRA iMTtEJ5g5BWio/9yyV3kgEhP7kZjETzWZOVaOdV3X4IBJqjfl17yJ+CWIwEIZphmcqkgaAw+6CYr qzH5kVW0sRZnSYUJYttKexax4g4bdLXbVzQFSkhjgmAnY6IuNZchjiTpcJJ0QgxHSHIjbFCEoYId OV5yhEh6Y2OJJWYpo1fOl6V9tozZKpo5uBqrf7qMCSYtt+IKq6y9tPnmr6fE+VWKMHqUJ5OyHVIn h89N+ieohBHaaGGWjvgXTSUw94CPvZGEKLOnXqXpBq9Fx5WnTSbL4UeEGYuqAy2hJx9xbOWgwC0X 1YqBrvzii9Eu+dYS8Ej9zspRwcDc2yCwDD8i7F9VtkvVnZcee+T/kX9y6pq0mxb2raLXFmabx5FO 2m2lx1Y1qcYqTjplnJKeVbG7NS23raHzYimZvf6+2u/A+/YcMC5Dz4pwwUUf7YvCDTcdycOyYaWD xLGBZfGkGJ9E5E0rJWeijTquOJhtGoW86KKQFrFkleEmmtjWNqY42E2vqbukEIaWGlNLfXqYaiOz 3Nuz0T8HDTS/SQscdOGMNw7MLUw7LTkjUBNSnUhzYs4RtyblhrWzk35nFd3DMdcedMiiipxxh+J0 HlfXHcth1BhZ5RvdW6lLpXoo6Y2qtmvlHNkhgedysOJI/+u4z8jrOnTRxxP+eOSTV2+9MkCiVfzj 3Hfv/fe6UH/9//jkv9I2RduDr/767OMifiETxC///PTXb//9+MvPSgj891/+/6gYi8mgkr72GfCA 3HufIOKHAAQAAAAXiKAEJ0jBClrwghJ8YAP1xwj/IYJ/DAjhCUYYAgCaEIAFRKAKV6iLBk0AARKI YARmSMMa2vCGOMwhDiMIAATEbxEhEGEJCwFCEY7wiEM8oRKtF4AmOvGJUIyiFKdIxSpa8YpYlKIh XggAHXrxi2DcoQR+mIggCrF//DOBERlwRBOYIIlLjKMcq/fCC4TxjhGQAA31mMMHipGMhzAjGzNA yEIekY1vDAEh3zjHRjoSWFz8ogS6WEME2DGHKKBkJnMoAQTk8P8CPiwjCURoSDe2MQMhMIABMuBG OD7ylbCUSfwo6UUY1hAAKPDiJiOwyxt2UocXACQRR4lIUxqThKpkJQljycxmIqSOYLQlDXGpS03S 0oa/1GEoA0nMNnrzjatUJhJNaIFymvOc6LSAM9fZjgnw8YvSnCE15dnAd+5ylz104AyzycltDtOI 32zlIk/pSutZQAA3uAEG8+nDcrJzEQ59qCsmcE1t8hEAncxlHlEgAQmgwJO8tGYEcAnDTfIThxid ADeLeUw3FvKlGUhmQSVngYTykKETEIBOd6rT+EVUooWwQAR+ClRUTOCS8PwoCj6KAI1ydKN8vGcX GzhDqp4Uh2P/XGlAYarKrnp1pk2r6QUeiFP58fSsApiAOos6iJreYKhsNWpFc1hPSlITlx596gyl GtJ9evKqNkypIQRpzJd2FY2ITSxYH2QBOzLUh/NDK1rXGlcL/CACCaVsXClB0TDGc6S5JOk79yrS Xf4SsDXspEr/eQKYxtQA/SOmbGcrWw++qbEQbCBk6SfZyVZWAjuQwGVvoNllZPG4TsyfcperCmh+ sZeg3etFN8lXquLVs6slhBlbW8jDCpK2awyheMXLPzfh1pIbrF9vfctWC8QgjwpVQHGVgVzkLve+ 92tuZ597zXnicql65esFAAzSjgJTmEVIrDljC16WtvSQ5HXQ/3nRa7/1sheoB41BR+NL3G84sR5P BPGHOxBiEo84ufhNMQdT4U6kcvKG/e3vNG8pYxoqNrFdfYGOdVzEbm7VtTA1JQMWW5EJg7LCFubp fJ1pgQIAIAYCwOwFfnCBJadCU4s4sZabKGIum9jLTlSHNlYRvxji8cx4TKNLxWnMVBpgxzweL0DX 7FqvJvOlrXQMbvN5ZN4mWckYpkABNFyA4ArXjlY2xQawrIj6HlfM2WBFmV2M5krfMAR0BrKb4dzj OReWkHYOdVcNSWSETJjCflZyOlddACbroAAliEEBgCsAAAjB1oneFKMfAaNdIyKKXQ5AsIf95TCP 4BnHhnQ0Wv/BQDNb+tk2DmF3vYrKN+84AZgeLwlv7GZRe5uQpTbInjfYZ7Pu1JwYrKAACpBrhpkT ohYAAKxLUIBBl0AAQhipM3K96EU7YgMasIGvDwHsYhO7xE4cgcKPvXAFzEjh8RuBiuf3CgbCEILp zvgEbXhBAGR7yK/17rXTON7+LeDkKE85/wwAgpa7HATfRiVaTn3U3eZUAOi+aVnp50AJsvt6FtDx ks0ZAArUugQImDWUERDcKf+g3RsQgQj8rQiAa2Dqi1i0o6XYcGnESAVgD8kD4jf2icdi4su1JA2D ib+Pr9zOaBwheUOQ8gWgse52D8HL9x5qcEOF5uXGeWN1rlv/n666nFyMYLvNK/S2Et2J2yI0CmIg 69z+QAGIznrUBU51QfT78/02BOi3DkWFR+PrIUm96lH0AHiZPSGTnmEwFfHxIady77XnH95DUILe l8ACeLf73l/e93DHA/CQHTxZNbjBco6SA4Kut/TZbYHEL14eRBVE9h3/gnM2cQhDCAAOVsADHgS3 3rGu99Ivm3lGAFwENujA56UOfxvYXwE2mDro4S//ImxZ2AYXgMnGE2G3equHIgjoAM7wAOZAEQzk WP4USN+VWHOHbcCHcrzne71nAQeAdxagd8MHc3D3d2OVXkc2VsunWw1lAR/AARxATNE3ffVWTj13 fe5QTj6A/wg+sH1FEHQW0EQzMAMBoBMzgAPh5wEIoFMI0HsFwHQFEAFCMEk3IF+NYHVSt2gakIVa KHX31wECR38aQHX/d3AfNoCod4AJmIa91xLOoAOR5oAM9EAINljfJWe6lwC+FwIHcAB4GGtpeIEp RwEgAILDN4JPcV7yo3OPhQDmBAGO6IIvSALQJ4PTZwE1SBEWkIOLsIOGEHTdFwA0IIRRhAMHJQCx lnQlIAGFhlFQSIVVCHBWF4agB3pXZ3W7RnpNlGwFmIYJqIG+uIYPoANueA1PYT8dVIe6twAJgIC9 p4fLqIAKgAHPAIgpZwEh2HKGKBOICEqFJz/n5IgL4IiO2P+CkTiJlDiDL2SD4aCOPdiJnyh+Qyh+ MaAA4YcDtRYD9DZoEiAAUCZcCtBh/2aLG+ABBOkBGyBwBWmQUdd5goCLuph6zPiLEvmLZYcC+XMI PkABGplOpLBUhpACA5AChNBEr4BYPnByz5giKFICIbCMAxGN+5YAPtCBC9CBgniNIqhKxvcIGbmR 6MQK55VP3mhOFVABHcgBEFAB4QiOJxeJO3h475YQa9WTGkkB59SJQSV0Q4ADARCEXBmK4qcDIaGK FBADDQRlUAhXvCaL+leQC5mQBwmLhVBwCHdiD7mSE5mXGvgAAKZchUABPhCJtJWRiZYChmkIoYUC ReCRIDn/AAPwRDzQAguzChSAcgnwktKoAC35DB4QAB6wbz15kjRpjdd4WKoAmM43W+VklYSAAtOn mIWwVK9JCLjFdueEkkVplAuAlEoJjrq5mycAfQ4CmIIpZ4QJUd1Hj6PYRDwQI/UGAPSWiqsoAUs2 i/0WhgQZdVq4ndvZAwMJi9YZngCIcDOiEg6ggbmRngSgl77Il32ZX4JAnM/ngh9QTjVQA+DImoeQ AjZgmCIpCJn0QLnkQ40ZAOVnoC3QmST5CpV5ABXgA87QmZ8pXwsAoRHqDDKZAJmYAEZZlKQZgrC1 k4yAmpkIiR9wovf5lFbpmvoUARegirC5mBZgZi/qmm2l/3jltIcLoJQLAJXhuKO6CQG7SQKa2Bfy WZUUcKIfcJ8QgKSJ4Ik/2AErYIQdUIRDQANDoANJiAAxIGhLtwOMGJ7x54X5N3VhqAEesJ3haXXZ GYb0Z39eqH9ad0UjgJctcad4eqcKt556GYzCOIzSEJ+CSZ/46YjlVAGOqJRL1piO6Z+LmU89hAIg aaA0IJmRiaCSmQqrqX2HipQWOqEUsIcHYKHOAJgauodJ6aAV8IHcdpockImSyAFLKo60uoMLMGun x0uKuVSYJXsa1Go9eKhGOaqAeXIUAA3SGAAKoIy5eZRKaQLCyRcUEInH+gwUQKvViqGIUE7v2EQ4 MANTiv8DWGqPXEpv0DloAIBznhd1ccqdZxqLsrgB4LWDG9ADWqid99pvV5QA/JoASNp701hOz/AA ucGe2eKnwjgNllUE0/p8LfgBtAqOFpCbRrmojumYS4VLkdpUS/WYkdkCkkmQINuZqJCJEEACFNCD EJCREFuh1lqTNOkDPsCvFWoBFGCUqeqhxDCtFhCrshqxQDtrU/gMCZVQAFa0LvpAHZV0wVqUe6ih ykiTlxmhnpkAPXp4GYCysKCRPekKDcsA2Wqtjhi22noIPuitQ8AD8OhEOIAAzjl5AlCW6mo5tHiv GmCvsoiyGimrKFqoGlmvWQieGzCGX8avsuoCLiCqq8r/gPumANlKsHx6nn36p4DauI5LTPSJrVWp qE5bsfuJsSPVQADGqwAwAZ6ZkDpFkAtKCQ7FgRUgnBZwskkqpMqokTU5rHW3g6eKqB26qoYgfalA ASTQsxyQchFblCjHiEW7vEV7AQXgdC46Vp0EQxagmBNrlDO5h6FqmZyZANr7DMmqAAmQtSnbChop qtrLCl8btpkpvtnavuJrtkKnAEKouh5AA2proEKwboSGjz9XddfpnYs2StMKsUArjkqJhWE4CITb RAlAAieauOi7h6vqDBlJqgTrexFJkaO7VN4YP18LidgKDTfbgQ56wpQFRQOQSbqFAiQAAQfAworZ RAQp/wBCKgD4m6mTkIkV0IMOCrsV8AGhyocye7vNqqM1C3OuO6w6WwT15sQC0EBPXAohfAAkcHKo mqgviMVPxbzMa2uyJ70q2FQ96LSquqonaZn9ir5TK6EJ8GZaewpIer4TTKyuKkLvqwDK6r7OEL4Y Ol/cagGSyZc4wJUg20QoEMXn92T/W4Xe6Z0EDLEnjLMI3KwWIJcNaUUP/AGIewC3icWWtawJIAML GLm9OJHu6cE+tQATEMI/K45k67g02YHIq057rACVGgArPLowzFQeCYo8YMMdKAAfq8OR4Lo+/Lop O7FCTKxWa8S4S5UieL1M7LtNqIpKCEOqSApVvMW3q/+qEODNB+BklLZDKDi9LwRDrXa9FFyUVkmT KTfByhihVqtjcWwK0+qIPgABJ3oAMGzG5YvPkehG2SqhGFqtBo2hnJiVP3hW9cZTUKiKEgBl7IiF kDy7DkoCqurPSfmCG33JjKbJEJy41UiNnuwMpKwAGeyHaojKoxs/PgDTz1eV4ji10lCZNXlyRRlm NFCpkomx+URgv/yxHiAACyAAInvIO+ygyQzEzayUcxzVBRsBJkAA7NzOTXbNSTd9HQWskuADz4eo 4ty54XzFNUnOGqe06PxCXV3Gw6qqFnCq8Iy+TquMNLsAbxatkBDVgCmqLFixHFCxFeuklCC8iHQA YTv/oXx8oc9gtQHdVkInABKQUC7aUU6nAOsGAGDKjptyt/L6sz+s0UWZlGIt2oh6AJ1nDZsswcEX z3mqwU8CkXi5l9nyp9HQsBxg09cKATYNk/uGxSinrLkMspIpDCzcVEHtmP4XmZ3JAwlZkJMJUUzt usLpA0J8okm5mz2qnit5AuJFACdwrW9dlNLXQOvGU9rs1Y+A2xlQ2lhM1uLsZMs338u3tOnF1gaw zmYM1w5g1T5AsWf8mzl9AKt0zyOqkVlLW+f0AYAt2Dt4SFUZCQ3rRsPa2xjqoBYuvie50NwXytSQ hPj2A2oVCdrpnaBd2uDM0R492kZJdaotqwLe2jCL/74y6wOxjYYUSbmVC9a5fdu8/QzKmpk4zaPC XalopAArYNwTwKtkrNyny5xS5J+O2gih+qAzWQE1oJGIWsAI7ILC63W5QcAwrLjj/NDrJn07ld6R wOOE5N5G7KBljcXy3VF0Xud03o0WJwH57daKu6ooQgBVicV1PMEZYMWPjQhVmQEK4GPfVGUvvIOB 7cnlREEuFeFUzgAw/ta97b0nvOmzDMjJidkOXQACMGU3MLeQAHAmDrEdWtYpHs4rzruovcCqzcnw LOO47gOqJ9sSibAJ67gfEAG9LeQ2ndDbq6PC3QIhkN0hgMuZOgCLueSK6eRN9JIDcbEXawON6ghL zP/Rudmk2J2oyqye6ukMYHvaMAsBpD596yYI5a1bUzyiL0hIMvC6Hg2zHeqCGn1yBaBK0zvGY8xz MGQA23zVFGwB4K0A/Q3oVnl4FCCTLsDgh24IFJDgJOBGEhRqQrfPO/jonghnOxZOGaCRi9CwH0CY Mvu0/QrgfLjGO7qHHK59kd2EAGBTQ6sA+8jZmyICPeCdrE7Brj7a/qzv4KybC4k/CcABJI3ruD7E CVCAEOnS70kBEWAANh3kjuuyjP3M/nqSoAiyelihzZ7LRfCYkkkDUNTTwl3kuoztF/ufjcCB4AzD +uwDBXC8D1wN5w7D773uD03q7T4IMrjekkhI2hv/1R0a1R9F8P+ugvajWx1lAGTsunRNASdAAM9w AryYGy0HfEKaARyQkYpQ8aNkAhcA8qj/AjJrTk+ZiTUus6gv8hNPCMJ78uY043TN4hT71ijsjgd1 85QNSoI3Caq+AazOxEF/2rBu2jkLi0jPyUzf9DCr67u+A5JL29miyq1c9aRq0ENMquIL3KvpA04U Ah4XAsSdqQjqAQd6qc6A9iUg3En+9m8PCXKPqI4oqjJL0+IICAcUDAqFhgwJFBUQBwsLBwUFApKR ApOWBUWam5ydnpqDHBkVC4ocFY2PFIIVp6mQBgYSCLQTtre4tBK7spmgjI0HFRQnCgQEhsmGJxQQ /xCoHx8Un5sUGSQnGQYv3N3e3+DdPuPk4Bnn09SDPgfOFguoB/KoFYvO98/1jfUWnhbcFhTcsERQ gIV+1BJq2iBCQ48NH2q4kCcMAgcSwhYd4MARY71njTb0ELEBF64ELmQ4WsmSgsuXMF1SlCdExY6b Nx04KMGz54MHI0agQGGLgoyjPgx5UCCA4oJxCRKwXGABpI8ACmhobRGga4ABAXi08GCphVkPXpmS otB1RdcBcAekUPiJAruKB3y8dPaBhA98HCgkYEAY0ap4jipdmlSEEi1fdDfpTQeKhCjE5Mg5zTwO RYFYu2qZnEALAa9YFlBssiAsVT1ihY7Jlg2idv+zjxB8ICwSNaY1EudixQpH3BtnH8QNoEs46MM9 C+z0zcOND5+8Z7s5/bNwQZKEGwezR/bE8GE0qy5beRwmqGNGl48qbNCwQZkhlKlawp/K/5G8DDXZ hJNOPfmkw4EIKkDBB0c9ZYgA/snTXyNV6RMADWaZFUAKcQXgAVkkQCDAh2jRkBWEehWiFQ1fyTWe P9P5wJEzMylyzwIcHJCIYO04FQkCmBCUiSQIFCABZJENckB2zWUAEn/TSTgVChZIIMssCJiky2kS pNZJM1K+Vox9ypyQwEfDbJLALmzuYo0owQm3TXF0hiPcOeiEJxgnFHDgnDMUvFPPoPZUV911FYj/ p8k/L4R30IsKbdCBCOY5U0ECrE0GE0W+scPOAvORRCZKU+3XH5R5ARiggDkVyJMODyCIoFENLpCA JfFJx5KEKfTqawpevRUXXF0JwMgCI16YVQB2CfDAhSt+NRek2s1j3ZIwFbDIIgtYxFGOEv5Iy2KM NbblkUgy98GSfPo5CmIzEQrvTJ5RcKVopJlmZSxFqtYJa4h1O0wCY5LJDJq6gdLmlW5akwGc2sgp 8cQUS4znxRS0uUsC1TDwJwQWYJpRoYbiEw921GxHbWQMOQSRMz5Q9dRUM/UXc0gj1WcfBS60dCrN jsiTgA+rstpqgbHCKqsO9hqg0q4jSyelBRyk/2DDsFjH9dILPKyCLA8sLnvissEOtTKf0XEADLvm PqbtoDM1Uklp5JbbdpuRZBITn4wwSUI0UscrbzzzUEQlm7VsCZoF6WoHT34gCXbC5JSb2Wc+VFWz ywUnYHPDDSZcgEBMD19s+umop57BS1ZewPkFsnBchAUeP+cAAdANLq88ipycaMoAnU2NpA1VCpIg MQcdt5SOSPUIqCN1UJJJRq1EQUuOOvpSVGeqULTRO7n6wFBCETWBvR8YsPzgUmKqdgW9Yv0SXBS8 gAAAAFAwVgBj8eDBsxfCyrJmgQIFRAAB/hIedGQUqEdpgkjjypsE8yaA0gBJEkLqRAF0UZpMQP/n b9F4yTj6xicQWkp3HyiUvI53AM/oqzSn6Rdd3nEsR9xDRztySQI2gjkm8eJ1rnOdLEb3gA345ohI TCLrABDEz5HgBhtbVAU+ZgGdEOAlEVqebnzgO0WtJjzCI48IivcyS/FOeVEjXCOu9ziRaIAko/Fa KRzRwKGg4AGz6YlOcOK97+WEQK6yI1GIsgrAUaQAjiBUuBD5Pn1wiH4AQMALKDAANr4gfx/i31kC oImuDJAWKIgAAcM4O2EERoOTMI0FgVSQClqwbnbbxAR9UZV8TBFmeiEhKKb4MVtOUQHxINkJKVKP AqBAY7HwzIsEhQobOuNb0LRl5viksWrS4gX/QWABCzYAghFswAC12QABugmCDYygNkXsJjfPyc1t boAFMADBuVp3pXRAx0/uIMAOFHC7K2ZPe1LT5Seo9gHZkbIIxOuByz4Gt0D5Z3fy0EswGOFGEUiP eqlwSWoEeUfZ6HGPfPTjH5FWAkHaAgV28VMzMeU8p5RiI2rLB0V6RQEAvAAew9iW/SiAFv59iCuR 6FVXCDgUVSbwbAA7JScwuMHQrPKpk4AgJiD1Ty5qBEzscomMenmPb71iUDWQKTGXdDhedOmokXmH wBpxD7hNxxGKooAqn1qaBCDAANl0ABBGAAQgwGAEROjrMWDwExhkYAQEgAEB+AqDv2ZAmyPg/8AI 5PpUNlFmQX+iwA6QUYgd6KSfx3jHKdQIAcoMtB1KDWPLGrJQrjqjFKtYniDORBEIiEShY9SZIeRI gaUhCI/H4AlI+yjSAYWPJw941YEMwbTzkEIqDdQeD4e5j3bU9KYQUNALFADbrhQAAsGyVAHgggIE KoARdjxoUk3bGILMU2MRxOC4pkpKG7Wnb30axnkMxREF5OUuEPVPaTVBJeF4aWUWuJ5b4zaoUnix CHLlnl0RIOFbISAID8gBYYFwWBYcIMNAIAALAPuAv5bAv930K1+1yQIQwIACFeTeKncDnXto1hic VcYO+jTaeLFtoAe5XmrPtloNuOwvJbPIU/80GuTDBFM+PVBo9HRbiOtRQAG+PRBwCSDcm3yvuIAs gZbFnKBC1PgZzvQWNGMq1ocKQpLwuPJLfqUtR/igzgsY7wDseKxQIpCU60Wle/UlAQAgrpWuZGXj 6HLEeMiob644c8k4kqg+KS9grdkNSg1gtjAeJFe7czCjo/vPBFMgm0U8wAbeWQ8igIADRAgPC8KT AQUAgQirBsIDtHkCEJQABJR9Kntt9Iwb43g2x8jvvAacMtQqqFvsfVFCjeyyWiZ5zW0lrQWijNs3 UvnZV86yAoDbZS9/+Qd+TG5PdDACMi93t8JM8gkJ9zhmb61+FZjkI+ucgEiQIs97NqAE7Cj/yj97 2pTRxqAl6IroV8ZyPKGAZlhphGSY6CXeXW0FB7iLRuUxW5YUWDSCSw3Gg0JYFCzIJggykMIKuKAG YV3SX3QTIt08LIUgAOc7s3GOwPwz2rmzlLHJtAPafvXH/oiQqT8u7UlRitoiCbq8IRqmJXHbyFOm HgUmwFFbbLncRUO3EB6Qbgeou6QoKJ8dbyH1qStSQoVLMJyze2UILGCScclbiBDZ7z2LkoAWRCu1 Ao1KhSO6IKuk7+B9SZ1nqJnSbTeUxhWQPCnF3ROCN7nm65KAcwQhCLWRiJ9qUIHa0C43VENFeCrg auXkXDnnAPYy4SH0BOxTx7H96jQT8o6D/1hEQQ9OSEJZO5+HCMrtUlsJKbYd5fk4ZIwXvcXWTzqU WwC33XskO9nHLvbta/8mD3DAHZNrUq6bzxbMlPzbXSqMzF2Xji/49+jg8t0KfBcCeSNvwREoSPUi 3BNMdXiD5nAiN0N3wWC+ZFX6kH7VoRFPUXkr0X7Bt3kUyByCMScvkAC1YXrhkUJLEmkVoBsg8AIW kwgIhlORY3s4kQg5onx2N4Gr0SPywBrRFiljJGUP4RDGJzDUsWD5wS3MF2X08UZZNxrmd37XVwI6 MT5p5z3bNxTbpwIPgBNMmHZdx3UmkX7sszxB84KgEEmTBGF3dz+UVH9PEQnwAHB7ll4USP94SyUk EjRoToUJBZhW2aOAM3GAFKGF81YPE+KFFRiI1CJC3JAZe+iBqbckqgcOL6FAKEgjO7JDHBCBQDh7 cFUVCUYtDPF0zaeDq8ZM68cffmgBtyWEbjQSokImWKYDhXB9/LSEBzICNwErNRGLI6ADOzCF7LY0 q8iKZDI7OKVGXJgruwdhLlEN8zMAeNZviXRncPFI07J5bvhAdAUk70WHgshFcaMbVQWKPpgfxAiD gjiOnpBDLxFTfxENPSIdvmFQnvaIj2d38YFm4qgdvidQ0pZb1JaDD/GJiUQPlmctcFWKCuVG9JFb 44FHI6AJSvgAmyCLDlkEZOcJU1gEC4n/VP84jIkkj/WoCfRnZwWQAog0DnrGIdEojf+3VBZUTYeW N21IddxYg4uSkS5FiRxJjjgZRr4hW3pBjglGeyfUVmgWKBg5g0QGdfvIbau2AZ+mO4RCFavGbVJp ZM5HH+MRFJxwkZoAkZsQkZ2glQqkYE7ZYERJLfQXCc/oks/oIhU4jYYHQ3QTVXWoQHqoJ+Pxk2NJ lh2Zk3xpgXEjk20oloMjap7mQEdJldSmg/24AbPTlE8JRksZlQqFmFT5ImD5CZeJkz+ZRs1kmCvD ls9YBC4yLCepeW4pgHQ4l+pll0h1PZxJIXvZl7KpDnZxjLJJcp45m+QRmbzJmP7wT8LXIZurppuC iJux6QmhmZxyERelaZopKUuz5JLEuZokJ4iBAAA7 --------------Boundary-00=_U8IXI22JDTD5BHK00000-- From sip-bounces@ietf.org Mon Jan 15 17:02:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Ztk-0006j5-5E; Mon, 15 Jan 2007 17:01:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Zti-0006j0-6l for sip@ietf.org; Mon, 15 Jan 2007 17:01:46 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6Ztd-00034u-U2 for sip@ietf.org; Mon, 15 Jan 2007 17:01:46 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l0FM1e5e012093; Mon, 15 Jan 2007 16:01:40 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l0FM1eu29881; Mon, 15 Jan 2007 16:01:40 -0600 (CST) Message-ID: <45ABF9C4.3090305@lucent.com> Date: Mon, 15 Jan 2007 16:01:40 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF9423256701614C26@esealmw113.eemea.ericsson.se> <45A7CDFB.5080705@cisco.com> <45A7DA65.5090802@alcatel-lucent.com> <45A7FED7.90604@cisco.com> In-Reply-To: <45A7FED7.90604@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: SIP LIST X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > Suppose a server can support 1000 connections, and devices connect as > soon as turned on, and attempt to reconnect whenever their connection is > dropped. Then when the device 1001 attempts to connect, the server will > have to drop somebody - perhaps the one whose connection as been idle > for the longest. But that device will immediately try to reconnect, > forcing another device to be disconnected. This will continue > indefinitely. Doesn't seem like a very good strategy. Paul: Yes, you are right. I had forgotten about that insidious side-effect. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 15 17:03:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Zv8-0007AO-SS; Mon, 15 Jan 2007 17:03:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Zv7-0007AE-Ko for sip@ietf.org; Mon, 15 Jan 2007 17:03:13 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6Zv6-0003Ba-BF for sip@ietf.org; Mon, 15 Jan 2007 17:03:13 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l0FM3B2K013850; Mon, 15 Jan 2007 16:03:11 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l0FM3Bu00997; Mon, 15 Jan 2007 16:03:11 -0600 (CST) Message-ID: <45ABFA1F.8060809@lucent.com> Date: Mon, 15 Jan 2007 16:03:11 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kai Vehmanen Subject: Re: [Sip] RE: TCP connection establishment References: <000101c738d5$c0ca9580$f32915ac@NOE.Nokia.com> In-Reply-To: <000101c738d5$c0ca9580$f32915ac@NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Kai Vehmanen wrote: > well, it's worth noting that in many real-life deployments the > TCP registration does establish a reverse path (even though > no IETF documents specify this yet -- waiting for sip-outbound). > Just look at iptel.org SER for example ("tcp_alias" settings, > other implementations use "persistent TCP", etc, etc). This leaves you open to the sort of attack described in S9.3 of connect-reuse (http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-07.txt). Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From janhan3@start.no Mon Jan 15 19:12:06 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6bvq-0008Bi-Sw for sip-archive@lists.ietf.org; Mon, 15 Jan 2007 19:12:06 -0500 Received: from p54ab326f.dip0.t-ipconnect.de ([84.171.50.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6bvl-0004LS-24 for sip-archive@lists.ietf.org; Mon, 15 Jan 2007 19:12:06 -0500 Received: from 195.159.73.45 (HELO mr3.start.no) by lists.ietf.org with esmtp (B1.5N5F;2 E5M9K9) id ((0N0A-TC.C(,--; for sip-archive@lists.ietf.org; Tue, 16 Jan 2007 00:11:58 -0060 Date: Tue, 16 Jan 2007 00:11:58 -0060 From: Otcbb Alert! X-Mailer: The Bat! (v3.0) UNREG / CD5BF9353B3B7091 X-Priority: 3 (Normal) Message-ID: <510794138.66302636840666@thebat.net> To: sip-archive@lists.ietf.org Subject: MHII.OB(MARSHALL HOLDINGS INTERNATIONAL INC.) this special for you MIME-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Spam-Score: 4.0 (++++) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Double or triple your investments just per 1 week. Go MHII.OB! About three million have fled their homes.
THIS IS OUR NEW SOLUTION BRINGS YOU A LOT OF EASY MONEY.
WE ARE GOING TO PROVIDE FOR YOU MARSHALL HOLDINGS INTERNATIONAL INC(MHII.OB).
THE MOST TRUSTED STOCKS THAT NEVER COLLAPSE!!!
FOR ELABORATE INFORMATION VISIT OUR SITE HURRY GET THIS STOCKS NOW!!!
IT WILL REALLY FLY ON THE TOP COME ON!!!
ACT RIGHT NOW AND GET MHII.OB FIRST THING ON TUESDAY.
THE NEXT PRICES ARE: JAN 8=0.01$ AND CURRENT JAN 12=0.04$!!!
MORE THAN 50% EVERY DAY!!! ON TUESDAY 16 JANUARY IT WILL 0.17$!!!
About three million have fled their homes.
From sip-bounces@ietf.org Tue Jan 16 08:55:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6okr-00022n-Ow; Tue, 16 Jan 2007 08:53:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6okr-00022e-0A for sip@ietf.org; Tue, 16 Jan 2007 08:53:37 -0500 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6okp-0003Rc-HF for sip@ietf.org; Tue, 16 Jan 2007 08:53:36 -0500 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id C8F8320A2F5; Tue, 16 Jan 2007 14:53:33 +0100 (CET) Message-Id: <7.0.1.0.0.20070116141404.01fdb658@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 16 Jan 2007 14:53:32 +0100 To: "Kai Vehmanen" , "'ext Paul Kyzivat'" From: Jiri Kuthan In-Reply-To: <000101c738d5$c0ca9580$f32915ac@NOE.Nokia.com> References: <45A689D2.4010402@cisco.com> <000101c738d5$c0ca9580$f32915ac@NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: sip@ietf.org, "Isomaki Markus \(Nokia-SIR/Espoo\)" , "Niemi Aki \(Nokia-NRC/Helsinki\)" , christer.holmberg@ericsson.com Subject: [Sip] RE: TCP connection establishment X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 19:48 15/01/2007, Kai Vehmanen wrote: >Hello, > >On 11 Jan 2007, Paul Kyzivat wrote: >>If the server cannot establish a connection to the client, but >>the client can establish a TLS connection with mutual >>authentication, then that could qualify the client as >>*needing* a connection. I'm talking about other cases. In >>particular, if we are talking about TCP rather than TLS, then >>the client establishing a TCP connection doesn't establish a >>reverse path, unless outbound is used. > >well, it's worth noting that in many real-life deployments the >TCP registration does establish a reverse path (even though >no IETF documents specify this yet -- waiting for sip-outbound). >Just look at iptel.org SER for example ("tcp_alias" settings, >other implementations use "persistent TCP", etc, etc). > >These ain't pretty, that's for sure, but allow to use TCP as the >transport with some of the already existing clients. > >>You can register with a server in order to receive outbound >>calls without maintaining a connection, as long as the server >>can establish a connection when it is needed. > >But how can a client possibly know which is the case? With >NATs on path, this is still doable, but with stateful firewalls, neither >the client nor the server can possibly know whether TCP >connections can be established towards the client. Deciding-by-trial is way >too slow as the FWs can drop packets silently, and the default >timeouts are long. So except in cases where the access network >characteristics are known, client will have to assume that _it_, the client, > >is the party responsible for initiating connections. Absolutely. In addition to the client-server-oriented NAT/firewall friendliness, one can argue even more generally using e2e principiles or Murphy laws: network can always fail somehow and the more robust approach for the client is just to rely on itself. -jiri -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 16 10:03:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6pph-0004tM-AK; Tue, 16 Jan 2007 10:02:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ppf-0004t9-Sm for sip@ietf.org; Tue, 16 Jan 2007 10:02:39 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6ppb-0005rY-0s for sip@ietf.org; Tue, 16 Jan 2007 10:02:39 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l0GEwDEB001985 for ; Tue, 16 Jan 2007 09:02:34 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 09:01:53 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 16:01:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-uri-list-message-01.txt Date: Tue, 16 Jan 2007 16:01:44 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180AEE95C@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-uri-list-message-01.txt Thread-Index: AcczZtHdKAHZM8weSvWD3vWmU3oinAGGEhXw From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 16 Jan 2007 15:01:44.0616 (UTC) FILETIME=[3CBF7A80:01C7397F] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I have just submitted the request to IESG to publish this document as proposed standard. As a result the document will now go through IESG review. The required PROTO writeup follows at the end of this mail Regards Keith Keith Drage drage@alcatel-lucent.com tel: +44 1793 776249 PROTO writeup for http://www.ietf.org/internet-drafts/draft-ietf-sip-uri- list-message-01.txt: "Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)" (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Keith Drage The document has been reviewed and is ready for forwarding to IESG for=20 publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Document history: * draft-camarillo-sipping-exploders-solution-00 was submitted November=20 22nd 2003 and expired May 22nd 2004. * draft-camarillo-sipping-exploders-00 was submitted September 9th 2003=20 and expired March 9th 2004. * draft-camarillo-sipping-exploders-02 was submitted February 6th 2004=20 and expired August 6th 2004. * draft-camarillo-sipping-exploders-03 was submitted February 2004 and=20 expired August 1st 2004. * draft-camarillo-sipping-uri-list-01 was submitted 6th February 2004=20 and expired 6th August 2004. * draft-camarillo-uri-list-02 was submitted 27th March 2004 and expired=20 25th September 2004. * draft-ietf-sipping-uri-list-00 was submitted 30th May 2004 and expired=20 30th November 2004. * draft-ietf-sipping-uri-list-message-00 was submitted 7th July 2004 and=20 expired 5th January 2005. * draft-ietf-sipping-uri-list-message-01 was submitted 14th October 2004=20 and expired 14th April 2005. * draft-ietf-sipping-uri-list-message-02 was submitted 2nd December 2004=20 and expired 2nd June 2005. * draft-ietf-sipping-uri-list-message-03 was submitted 15th April 2005=20 and expired 15th October 2005. * draft-ietf-sipping-uri-list-message-04 was submitted 24th October 2005=20 and expired 24th April 2006. * draft-ietf-sipping-uri-list-message-05 was submitted 18th January 2006=20 and expired 18th July 2006. * draft-ietf-sipping-uri-list-message-06 was submitted 31st January 2006=20 and expired 30th July 2006. * draft-ietf-sipping-uri-list-message-07 was submitted 27th February=20 2006 and expired 27th August 2006. * draft-ietf-sipping-uri-list-message-08 was submitted 5th September=20 2006 and expired 5th March 2007. * draft-ietf-sip-uri-list-message-00 was submitted 24th September 2006=20 and expires 24th March 2007. * draft-ietf-sip-uri-list-message-01 was submitted 8th January 2007 and=20 expires 8th July 2007. WGLC was initiated in the SIPPING WG on draft-ietf-sipping-uri-list-message- 02 on 12th January 2005 with comments requested by 12th February 2005. Review was made and no comments were received. During the course of the work=20 comments have also been made by: Paul Kyzivat, Dean Willis, Jari Urpalainen. draft-ietf-sipping-uri-list-message-07 was extended to refer to draft-ietf- sipping-capacity-attribute. The document was moved from the SIPPING WG to the SIP WG in conformance with=20 RFC 3427 because it defines an option tag (this was added at a late stage in=20 the review process). The document was regarded by the SIPPING WG chairs as=20 being adequately reviewed and no further review took place in the SIP WG.=20 The SIP mailing list was polled on this status and no complaint was made. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? The document defines mechanisms that are entirely internal to the Session=20 Initiation Protocol (SIP). The document shepherd considers that no external=20 review from an external specialist is necessary. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The document defines a new SIP protocol extension for a particular purpose=20 in a form that has been used for many other extensions. The document=20 shepherd has no concerns with the document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is a strong requirement from OMA for a SIP solution in this area. The=20 document also forms part of 3GPP Release 6 content. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) None indicated. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The document has been reviewed against the guidelines in RFC 4485 and it is=20 believed that the document is conformant with those guidelines. While the document defines a new SIP option tag, these have been performed=20 as a SIP working group item, and therefore this draft is in conformance with=20 RFC 3427. For ID-NITS the document has been checked against idnits 1.123 and no issues=20 have been found. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has split its references into normative and informative=20 references. All the normative references are now published RFCs except as=20 follows: * reference [10] draft-ietf-simple-xcap-list-usage-05 is in IESG review=20 as proposed standard. * reference [11] draft-ietf-sipping-uri-services-06 has been submitted=20 to the IESG by the SIPPING group as proposed standard. * reference [12] draft-ietf-sipping-capacity-attribute-03 is currently=20 in WGLC in the SIPPING group. It should be noted that reference [7] is a normative reference despite being=20 an informational RFC. It is believed that this meets the criteria of RFC 3967. The document needs no informative references. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? Section 11 of the document registers a new option-tag; the new option-tag is=20 defined elsewhere in the document. This registration is consistent with RFC=20 3968 which defines the registry and is also consistent with the current=20 format of the registry. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document contains no entries written in formal language. While the=20 document makes use of XML within a SIP message body, that XML is defined by=20 other documents (RFC 4488, draft-ietf-simple-xcap-list-usage-05), and used=20 in this specification by reference. Figure 2, and figure 3 contain an=20 example of this XML usage which is apparently well-formed. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document specifies a mechanism that allows a SIP User Agent Client (UAC)=20 to request a SIP URI-list (Uniform Resource Identifier list) service to send=20 a SIP MESSAGE request to a set of destinations. The client sends a SIP=20 MESSAGE request that includes the payload along with the URI-list to the MESSAGE URI-list service, which sends a similar MESSAGE request to each of=20 the URIs included in the list. Working Group Summary The document was originally produced by the SIPPING working group, but was=20 transferred to the SIP working group due to the need to define a new option=20 tag, in conformance with RFC 3427. There is consensus in the WG to publish=20 this document. Document Quality There is a strong requirement from OMA and 3GPP for a SIP solution in this=20 area. Personnel Keith Drage is the document shepherd for this document. Cullen Jennings is=20 the responsible Area Director. =20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: 08 January 2007 20:50 > To: i-d-announce@ietf.org > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-ietf-sip-uri-list-message-01.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol=20 > Working Group of the IETF. >=20 > Title : Multiple-Recipient MESSAGE Requests=20 > in the Session Initiation Protocol (SIP) > Author(s) : M. Garcia-Martin, G. Camarillo > Filename : draft-ietf-sip-uri-list-message-01.txt > Pages : 18 > Date : 2007-1-8 > =09 > This document specifies a mechanism that allows a SIP User Agent > Client (UAC) to request a SIP URI-list (Uniform Resource Identifier > list) service to send a SIP MESSAGE request to a set of=20 > destinations. > The client sends a SIP MESSAGE request that includes the payload > along with the URI-list to the MESSAGE URI-list service,=20 > which sends > a similar MESSAGE request to each of the URIs included in the list. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-uri-list-me ssage-01.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message.=20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then=20 > "get draft-ietf-sip-uri-list-message-01.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sip-uri-list-message-01.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 16 10:26:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qCX-0008UA-Bf; Tue, 16 Jan 2007 10:26:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qCW-0008U5-H0 for sip@ietf.org; Tue, 16 Jan 2007 10:26:16 -0500 Received: from chip2og50.obsmtp.com ([64.18.13.37]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H6qCS-0000mR-NS for sip@ietf.org; Tue, 16 Jan 2007 10:26:16 -0500 Received: from source ([192.150.11.134]) by chip2ob50.postini.com ([64.18.5.12]) with SMTP; Tue, 16 Jan 2007 07:25:56 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l0GFMgvV004442; Tue, 16 Jan 2007 07:22:45 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l0GFPoeA021424; Tue, 16 Jan 2007 07:25:51 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 07:25:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: TCP connection establishment Date: Tue, 16 Jan 2007 07:25:49 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223ADDD2@namail5.corp.adobe.com> In-Reply-To: <7.0.1.0.0.20070116141404.01fdb658@iptel.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TCP connection establishment Thread-Index: Acc5dhNN9ESQ6o74TfKdtTUXGY/SlwACrKwg References: <45A689D2.4010402@cisco.com><000101c738d5$c0ca9580$f32915ac@NOE.Nokia.com> <7.0.1.0.0.20070116141404.01fdb658@iptel.org> From: "Henry Sinnreich" To: "Jiri Kuthan" , "Kai Vehmanen" , "ext Paul Kyzivat" , X-OriginalArrivalTime: 16 Jan 2007 15:25:50.0277 (UTC) FILETIME=[9A6DD750:01C73982] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: sip@ietf.org, christer.holmberg@ericsson.com, "Niemi Aki \(Nokia-NRC/Helsinki\)" , "Isomaki Markus \(Nokia-SIR/Espoo\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > network can always fail somehow and the more robust approach for the=20 > client is just to rely on itself This is an excellent reformulation of the e2e principle.=20 Besides failures, it applies even more to security.=20 We can't risk our life to depend on unknown intermediaries. This is the motivation for ZRTP among other. Thanks, Henry -----Original Message----- From: Jiri Kuthan [mailto:jiri@iptel.org]=20 Sent: Tuesday, January 16, 2007 7:54 AM To: Kai Vehmanen; 'ext Paul Kyzivat' Cc: sip@ietf.org; Isomaki Markus (Nokia-SIR/Espoo); Niemi Aki (Nokia-NRC/Helsinki); christer.holmberg@ericsson.com Subject: [Sip] RE: TCP connection establishment At 19:48 15/01/2007, Kai Vehmanen wrote: >Hello, > >On 11 Jan 2007, Paul Kyzivat wrote: >>If the server cannot establish a connection to the client, but=20 >>the client can establish a TLS connection with mutual=20 >>authentication, then that could qualify the client as=20 >>*needing* a connection. I'm talking about other cases. In=20 >>particular, if we are talking about TCP rather than TLS, then=20 >>the client establishing a TCP connection doesn't establish a=20 >>reverse path, unless outbound is used. > >well, it's worth noting that in many real-life deployments the >TCP registration does establish a reverse path (even though >no IETF documents specify this yet -- waiting for sip-outbound). >Just look at iptel.org SER for example ("tcp_alias" settings,=20 >other implementations use "persistent TCP", etc, etc). > >These ain't pretty, that's for sure, but allow to use TCP as the >transport with some of the already existing clients. > >>You can register with a server in order to receive outbound=20 >>calls without maintaining a connection, as long as the server=20 >>can establish a connection when it is needed. > >But how can a client possibly know which is the case? With >NATs on path, this is still doable, but with stateful firewalls, neither >the client nor the server can possibly know whether TCP=20 >connections can be established towards the client. Deciding-by-trial is way=20 >too slow as the FWs can drop packets silently, and the default=20 >timeouts are long. So except in cases where the access network=20 >characteristics are known, client will have to assume that _it_, the client, > >is the party responsible for initiating connections. Absolutely. In addition to the client-server-oriented NAT/firewall friendliness, one can argue even more generally using e2e principiles or Murphy laws: network can always fail somehow and the more robust approach for the client is just to rely on itself. -jiri -- Jiri Kuthan http://iptel.org/~jiri/=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 16 10:48:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qXd-000761-BS; Tue, 16 Jan 2007 10:48:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qXb-00075w-L5 for sip@ietf.org; Tue, 16 Jan 2007 10:48:03 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6qXa-0004CD-7i for sip@ietf.org; Tue, 16 Jan 2007 10:48:03 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 16 Jan 2007 07:48:01 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l0GFm1hT014512; Tue, 16 Jan 2007 07:48:01 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0GFlsnR017955; Tue, 16 Jan 2007 07:48:01 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 10:47:56 -0500 Received: from [161.44.182.244] ([161.44.182.244]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 10:47:56 -0500 Message-ID: <45ACF3AB.2080703@cisco.com> Date: Tue, 16 Jan 2007 10:47:55 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Sean Olson Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF9423256701614C26@esealmw113.eemea.ericsson.se> <45A7CDFB.5080705@cisco.com> <45A7DA65.5090802@alcatel-lucent.com> <45A7FED7.90604@cisco.com> <45ABF9C4.3090305@lucent.com> <4C1596FBF66C67478BCFE7B3F81FC1E01781EAA5EC@DF-MASTIFF-MSG.exchange.corp.microsoft.com> In-Reply-To: <4C1596FBF66C67478BCFE7B3F81FC1E01781EAA5EC@DF-MASTIFF-MSG.exchange.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2007 15:47:56.0118 (UTC) FILETIME=[B0B11F60:01C73985] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2470; t=1168962481; x=1169826481; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20TCP=20connection=20establishment=20[was=3A=20RE=3A=20 [Sip]=20Question=20aboutPoll=3A=0A=20Proposal=20relating=20to=20keepalive, =20TCP,=09and=20UDP=20usage=20indraft-ietf-sip-outbound] |Sender:=20; bh=0Nlm9sy8tlmk0DFTpghCr2R4NH4OPuSzTMZsAxqfpMA=; b=UigC+Tf7OLoVByJnMW1Wzm2lkVKHjMdJ7zRS033GAbc1AhHbQ8KMxFTbOLq5pPmJu9OhPta/ HUaDh0h/HW6hiD/Ok6YZGAjHITllG6ev+ZyJ6f+v1Pya66g5oKOqCEaR; Authentication-Results: sj-dkim-7; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: SIP LIST X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sean Olson wrote: > Wow.... that's one option, but certainly not the only one. This is where I like to introduce multiple servers Sean - I'm not sure exactly which point you are trying to make. Certainly one option is to attempt to over configure the system so that there is enough capacity to accept every connection attempt. In certain closed environments that may be workable. But it is certainly not a solution for all environments. Presumably every deployment will have *some* limit. This limit could be reached in normal operation if the operators don't have control over the number of clients attempting to connect. That limit can support more devices if they don't attempt to keep the connection up all the time than it can if they do. The limit can also be reached as a result of devices that malfunction, or because of a DOS attack. The impact of that may also be worth some consideration. Paul > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] > Sent: Monday, January 15, 2007 2:02 PM > To: Paul Kyzivat > Cc: SIP LIST > Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] > > Paul Kyzivat wrote: >> Suppose a server can support 1000 connections, and devices connect as >> soon as turned on, and attempt to reconnect whenever their connection is >> dropped. Then when the device 1001 attempts to connect, the server will >> have to drop somebody - perhaps the one whose connection as been idle >> for the longest. But that device will immediately try to reconnect, >> forcing another device to be disconnected. This will continue >> indefinitely. Doesn't seem like a very good strategy. > > Paul: Yes, you are right. I had forgotten about that insidious > side-effect. > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 16 11:03:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qlU-0005nl-1Y; Tue, 16 Jan 2007 11:02:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qlS-0005jW-0f for sip@ietf.org; Tue, 16 Jan 2007 11:02:22 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6qlQ-0005pI-Lf for sip@ietf.org; Tue, 16 Jan 2007 11:02:21 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 16 Jan 2007 08:02:20 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l0GG2Kht027655; Tue, 16 Jan 2007 08:02:20 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0GG2AnT027502; Tue, 16 Jan 2007 08:02:19 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 11:01:48 -0500 Received: from [161.44.182.244] ([161.44.182.244]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 11:01:48 -0500 Message-ID: <45ACF6EB.7030903@cisco.com> Date: Tue, 16 Jan 2007 11:01:47 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Jiri Kuthan References: <45A689D2.4010402@cisco.com> <000101c738d5$c0ca9580$f32915ac@NOE.Nokia.com> <7.0.1.0.0.20070116141404.01fdb658@iptel.org> In-Reply-To: <7.0.1.0.0.20070116141404.01fdb658@iptel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2007 16:01:48.0223 (UTC) FILETIME=[A0AA44F0:01C73987] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2662; t=1168963340; x=1169827340; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20TCP=20connection=20establishment |Sender:=20; bh=v59yJjSTztRqY/DuNqRHWOJTys/euQFJDiD5Q/YwRc8=; b=aXwVoHpJea9erxG+pgoaMXrlpu/iT1VPp3U+IlkWXGdKuqhhx5hVFom+rWZ80TLDfWxKHMFA M58lCI8GuZk2FRJn7dhxdSzMWwSK6N5uaje2CaN5Ao/mliUFW91SraVN; Authentication-Results: sj-dkim-8; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: sip@ietf.org, Kai Vehmanen , "Isomaki Markus \(Nokia-SIR/Espoo\)" , "Niemi Aki \(Nokia-NRC/Helsinki\)" , christer.holmberg@ericsson.com Subject: [Sip] Re: TCP connection establishment X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org comment at end. Jiri Kuthan wrote: > At 19:48 15/01/2007, Kai Vehmanen wrote: >> Hello, >> >> On 11 Jan 2007, Paul Kyzivat wrote: >>> If the server cannot establish a connection to the client, but >>> the client can establish a TLS connection with mutual >>> authentication, then that could qualify the client as >>> *needing* a connection. I'm talking about other cases. In >>> particular, if we are talking about TCP rather than TLS, then >>> the client establishing a TCP connection doesn't establish a >>> reverse path, unless outbound is used. >> well, it's worth noting that in many real-life deployments the >> TCP registration does establish a reverse path (even though >> no IETF documents specify this yet -- waiting for sip-outbound). >> Just look at iptel.org SER for example ("tcp_alias" settings, >> other implementations use "persistent TCP", etc, etc). >> >> These ain't pretty, that's for sure, but allow to use TCP as the >> transport with some of the already existing clients. >> >>> You can register with a server in order to receive outbound >>> calls without maintaining a connection, as long as the server >>> can establish a connection when it is needed. >> But how can a client possibly know which is the case? With >> NATs on path, this is still doable, but with stateful firewalls, neither >> the client nor the server can possibly know whether TCP >> connections can be established towards the client. Deciding-by-trial is way >> too slow as the FWs can drop packets silently, and the default >> timeouts are long. So except in cases where the access network >> characteristics are known, client will have to assume that _it_, the client, >> >> is the party responsible for initiating connections. > > Absolutely. In addition to the client-server-oriented NAT/firewall friendliness, > one can argue even more generally using e2e principiles or Murphy laws: > network can always fail somehow and the more robust approach for the client is > just to rely on itself. What point are you making? Vijay responded as I would have - the single TCP connection has major security concerns if used bidirectionally. You should only use TCP if you know you don't have NAT/FW issues, so that a separate TCP connection can be made in the other direction. Otherwise, if you have your own cert you can use TLS and avoid the need for connection establishment in the reverse direction, or else you can use outbound. Practically speaking, a UA will typically not have a cert, and will need to use outbound. Connection reuse, via TCP or TLS, will typically only be useful between proxies. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 16 11:14:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qx2-0005aW-Jf; Tue, 16 Jan 2007 11:14:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qx0-0005Z8-Il for sip@ietf.org; Tue, 16 Jan 2007 11:14:18 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6qwz-0007aR-4V for sip@ietf.org; Tue, 16 Jan 2007 11:14:18 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 16 Jan 2007 08:14:17 -0800 X-IronPort-AV: i="4.13,197,1167638400"; d="scan'208"; a="50911250:sNHT53284422" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0GGEHLl029776; Tue, 16 Jan 2007 11:14:17 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0GGEGOA022360; Tue, 16 Jan 2007 11:14:16 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 11:14:16 -0500 Received: from [161.44.182.244] ([161.44.182.244]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 11:14:16 -0500 Message-ID: <45ACF9D7.1000304@cisco.com> Date: Tue, 16 Jan 2007 11:14:15 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Sean Olson Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF9423256701614C26@esealmw113.eemea.ericsson.se> <45A7CDFB.5080705@cisco.com> <45A7DA65.5090802@alcatel-lucent.com> <45A7FED7.90604@cisco.com> <45ABF9C4.3090305@lucent.com> <4C1596FBF66C67478BCFE7B3F81FC1E01781EAA5EC@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <45ACF3AB.2080703@cisco.com> <4C1596FBF66C67478BCFE7B3F81FC1E01781EAA7A7@DF-MASTIFF-MSG.exchange.corp.microsoft.com> In-Reply-To: <4C1596FBF66C67478BCFE7B3F81FC1E01781EAA7A7@DF-MASTIFF-MSG.exchange.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2007 16:14:16.0278 (UTC) FILETIME=[5E8A6760:01C73989] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4271; t=1168964057; x=1169828057; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20TCP=20connection=20establishment=20[was=3A=20RE=3A=20 [Sip]=20Question=20aboutPoll=3A=0A=20Proposal=20relating=20to=20keepalive, =20TCP,=09and=20UDP=20usage=20indraft-ietf-sip-outbound] |Sender:=20 |To:=20Sean=20Olson=20; bh=gYvLv0iPgQGCfc5FtMtG/U3mwyzOc8tPgeXBdJjTsVA=; b=BEFoUQin716IUwu5zo+uRVchDNIRAvOaacLPSs6PYjERxnGwvs5TPf9ACTTIqxTBMPkWSZr/ ANSRsICB37aNQWzXDDFqJqaqRfm6O1vrcuWOpNujXB9SojcdbUvNIfuj; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: SIP LIST X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sean Olson wrote: > My main point is that dropping prior connections to accept a new connection is one possible policy, but hopefully not a commonly implemented one. Every deployment will have some limit. Very few deployments have absolutely no idea what their expected use will be though. Proper provisioning based on intended usage and empirical evidence is a reasonable assumption. There are other queuing/blocking techniques that can help with overload situations. DoS attacks in particular should not be responded to by dropping existing connections in order to feed the attack. I certainly agree in the DOS case. And I am not knowledgeable in this area, so will defer to somebody that is. But at some point one must either drop an existing connection or reject a connection request. It seems pretty unfair if you end up rejecting connection requests that might be important in order to preserve a connection that hasn't been used in hours, days, or more. Unfortunately, what the connection request arrives there is generally no good way to tell how important it is. You might be able to decide based on what it does after you accept the connection. But that is too late. As I say, I am no expert here, so I will be happy if somebody can specify how this can be handled reasonably if every prospective client continually attempts to connect. Paul > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, January 16, 2007 7:48 AM > To: Sean Olson > Cc: Vijay K. Gurbani; SIP LIST > Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] > > > > Sean Olson wrote: >> Wow.... that's one option, but certainly not the only one. This is where I like to introduce multiple servers > > Sean - I'm not sure exactly which point you are trying to make. > > Certainly one option is to attempt to over configure the system so that > there is enough capacity to accept every connection attempt. In certain > closed environments that may be workable. But it is certainly not a > solution for all environments. > > Presumably every deployment will have *some* limit. This limit could be > reached in normal operation if the operators don't have control over the > number of clients attempting to connect. That limit can support more > devices if they don't attempt to keep the connection up all the time > than it can if they do. > > The limit can also be reached as a result of devices that malfunction, > or because of a DOS attack. The impact of that may also be worth some > consideration. > > Paul > >> -----Original Message----- >> From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] >> Sent: Monday, January 15, 2007 2:02 PM >> To: Paul Kyzivat >> Cc: SIP LIST >> Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] >> >> Paul Kyzivat wrote: >>> Suppose a server can support 1000 connections, and devices connect as >>> soon as turned on, and attempt to reconnect whenever their connection is >>> dropped. Then when the device 1001 attempts to connect, the server will >>> have to drop somebody - perhaps the one whose connection as been idle >>> for the longest. But that device will immediately try to reconnect, >>> forcing another device to be disconnected. This will continue >>> indefinitely. Doesn't seem like a very good strategy. >> Paul: Yes, you are right. I had forgotten about that insidious >> side-effect. >> >> - vijay >> -- >> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} >> WWW: http://www.alcatel-lucent.com/bell-labs >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 16 11:46:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6rRe-0005mE-T5; Tue, 16 Jan 2007 11:45:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6rRb-0005m9-4R for sip@ietf.org; Tue, 16 Jan 2007 11:45:55 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6rRY-0004kW-M0 for sip@ietf.org; Tue, 16 Jan 2007 11:45:55 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l0GGc1O24878; Tue, 16 Jan 2007 11:38:01 -0500 (EST) Received: from [47.130.17.73] ([47.130.17.73] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 11:45:38 -0500 Message-ID: <45AD0122.8000102@nortel.com> Date: Tue, 16 Jan 2007 11:45:22 -0500 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF9423256701614C26@esealmw113.eemea.ericsson.se> <45A7CDFB.5080705@cisco.com> <45A7DA65.5090802@alcatel-lucent.com> <45A7FED7.90604@cisco.com> <45ABF9C4.3090305@lucent.com> <4C1596FBF66C67478BCFE7B3F81FC1E01781EAA5EC@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <45ACF3AB.2080703@cisco.com> <4C1596FBF66C67478BCFE7B3F81FC1E01781EAA7A7@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <45ACF9D7.1000304@cisco.com> In-Reply-To: <45ACF9D7.1000304@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2007 16:45:38.0997 (UTC) FILETIME=[C0BA8650:01C7398D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: SIP LIST , Sean Olson X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This isn't like provisioning a telephone trunk group (circuit group, in European terminology), where you know each trunk will eventually be freed when the call is complete. In the present case, you either provide for every client to be connected or you need a disconnect policy. What I suggest is a policy of disconnecting after some period of non-use, rather than in response to incoming calls. That prevents "feeding a DOS attack". Paul Kyzivat wrote: > > > Sean Olson wrote: >> My main point is that dropping prior connections to accept a new >> connection is one possible policy, but hopefully not a commonly >> implemented one. Every deployment will have some limit. Very few >> deployments have absolutely no idea what their expected use will be >> though. Proper provisioning based on intended usage and empirical >> evidence is a reasonable assumption. There are other queuing/blocking >> techniques that can help with overload situations. DoS attacks in >> particular should not be responded to by dropping existing connections >> in order to feed the attack. > > I certainly agree in the DOS case. And I am not knowledgeable in this > area, so will defer to somebody that is. But at some point one must > either drop an existing connection or reject a connection request. It > seems pretty unfair if you end up rejecting connection requests that > might be important in order to preserve a connection that hasn't been > used in hours, days, or more. > > Unfortunately, what the connection request arrives there is generally no > good way to tell how important it is. You might be able to decide based > on what it does after you accept the connection. But that is too late. > > As I say, I am no expert here, so I will be happy if somebody can > specify how this can be handled reasonably if every prospective client > continually attempts to connect. > > Paul > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Tuesday, January 16, 2007 7:48 AM >> To: Sean Olson >> Cc: Vijay K. Gurbani; SIP LIST >> Subject: Re: TCP connection establishment [was: RE: [Sip] Question >> aboutPoll: Proposal relating to keepalive, TCP, and UDP usage >> indraft-ietf-sip-outbound] >> >> >> >> Sean Olson wrote: >>> Wow.... that's one option, but certainly not the only one. >>> This is where I like to introduce multiple servers >> >> Sean - I'm not sure exactly which point you are trying to make. >> >> Certainly one option is to attempt to over configure the system so that >> there is enough capacity to accept every connection attempt. In certain >> closed environments that may be workable. But it is certainly not a >> solution for all environments. >> >> Presumably every deployment will have *some* limit. This limit could be >> reached in normal operation if the operators don't have control over the >> number of clients attempting to connect. That limit can support more >> devices if they don't attempt to keep the connection up all the time >> than it can if they do. >> >> The limit can also be reached as a result of devices that malfunction, >> or because of a DOS attack. The impact of that may also be worth some >> consideration. >> >> Paul >> >>> -----Original Message----- >>> From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] >>> Sent: Monday, January 15, 2007 2:02 PM >>> To: Paul Kyzivat >>> Cc: SIP LIST >>> Subject: Re: TCP connection establishment [was: RE: [Sip] Question >>> aboutPoll: Proposal relating to keepalive, TCP, and UDP usage >>> indraft-ietf-sip-outbound] >>> >>> Paul Kyzivat wrote: >>>> Suppose a server can support 1000 connections, and devices connect as >>>> soon as turned on, and attempt to reconnect whenever their >>>> connection is >>>> dropped. Then when the device 1001 attempts to connect, the server will >>>> have to drop somebody - perhaps the one whose connection as been idle >>>> for the longest. But that device will immediately try to reconnect, >>>> forcing another device to be disconnected. This will continue >>>> indefinitely. Doesn't seem like a very good strategy. >>> Paul: Yes, you are right. I had forgotten about that insidious >>> side-effect. >>> >>> - vijay >>> -- >>> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >>> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >>> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} >>> WWW: http://www.alcatel-lucent.com/bell-labs >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 16 12:00:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6rfD-0007Zo-82; Tue, 16 Jan 2007 11:59:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6rfA-0007Xx-Hu for sip@ietf.org; Tue, 16 Jan 2007 11:59:56 -0500 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6rf9-0006jx-Bq for sip@ietf.org; Tue, 16 Jan 2007 11:59:56 -0500 Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com[72.190.0.23]) by comcast.net (sccrmhc13) with SMTP id <2007011616595401300m1h1ke>; Tue, 16 Jan 2007 16:59:54 +0000 Message-ID: <07a301c7398f$2cdebd50$6701a8c0@china.huawei.com> From: "Spencer Dawkins" To: "SIP LIST" References: <7374777208BDC7449D5620EF9423256701614C26@esealmw113.eemea.ericsson.se> <45A7CDFB.5080705@cisco.com><45A7DA65.5090802@alcatel-lucent.com> <45A7FED7.90604@cisco.com><45ABF9C4.3090305@lucent.com><4C1596FBF66C67478BCFE7B3F81FC1E01781EAA5EC@DF-MASTIFF-MSG.exchange.corp.microsoft.com><45ACF3AB.2080703@cisco.com><4C1596FBF66C67478BCFE7B3F81FC1E01781EAA7A7@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <45ACF9D7.1000304@cisco.com> Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll:Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] Date: Tue, 16 Jan 2007 10:55:49 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've been watching this thread for a while, but wanted to respond to Paul's note... > As I say, I am no expert here, so I will be happy if somebody can specify > how this can be handled reasonably if every prospective client continually > attempts to connect. > > Paul Personalizing a bit, if Spencer says "I've got to set up my connections (and do TLS exchanges, but let's ignore that for now) before I need them, because I care about setup delays", and Paul says, "I need to close inactive connections, because I care about the cost of reserved resources", it's hard to see how we're going to both be happy at the same time. Without suffient resources, we're only discussing who gives up on their goal first, right? I'm not sure that any of us are the kind of expert that can put ten pounds of flour in a five-pound flour sack, and that's the kind of expert we seem to be looking for... Spencer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 16 13:18:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ss3-0001UF-E1; Tue, 16 Jan 2007 13:17:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ss2-0001U5-2Y for sip@ietf.org; Tue, 16 Jan 2007 13:17:18 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6srz-0004QP-Jt for sip@ietf.org; Tue, 16 Jan 2007 13:17:18 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 16 Jan 2007 10:17:15 -0800 X-IronPort-AV: i="4.13,197,1167638400"; d="scan'208"; a="50921038:sNHT55615668" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0GIHFBk011239; Tue, 16 Jan 2007 13:17:15 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0GIHFVT018758; Tue, 16 Jan 2007 13:17:15 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 13:17:15 -0500 Received: from [161.44.182.244] ([161.44.182.244]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 13:17:14 -0500 Message-ID: <45AD16A9.6070000@cisco.com> Date: Tue, 16 Jan 2007 13:17:13 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Tom-PT Taylor Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF9423256701614C26@esealmw113.eemea.ericsson.se> <45A7CDFB.5080705@cisco.com> <45A7DA65.5090802@alcatel-lucent.com> <45A7FED7.90604@cisco.com> <45ABF9C4.3090305@lucent.com> <4C1596FBF66C67478BCFE7B3F81FC1E01781EAA5EC@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <45ACF3AB.2080703@cisco.com> <4C1596FBF66C67478BCFE7B3F81FC1E01781EAA7A7@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <45ACF9D7.1000304@cisco.com> <45AD0122.8000102@nortel.com> In-Reply-To: <45AD0122.8000102@nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2007 18:17:14.0483 (UTC) FILETIME=[8C4B2430:01C7399A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5595; t=1168971435; x=1169835435; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20TCP=20connection=20establishment=20[was=3A=20RE=3A=20 [Sip]=20Question=20aboutPoll=3A=0A=20Proposal=20relating=20to=20keepalive, =20TCP,=09and=20UDP=20usage=20indraft-ietf-sip-outbound] |Sender:=20 |To:=20Tom-PT=20Taylor=20; bh=m1sxANMeqOOWlWo4XPt82qUFfLqSou3ayGr2+ngzhrw=; b=KdxVtEtHVG6Ot6enqibmnVruJ9xG8gemhuY4gIicqddbhXqzXv3Er0vQpepp+saFnx9UFGVw L/vJk1XmWsEbhLJTNEDdAm/syDXwMcFUSFy4YLimmX4p4NidQ2kBsiGr; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: SIP LIST , Sean Olson X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Tom-PT Taylor wrote: > This isn't like provisioning a telephone trunk group (circuit group, in > European terminology), where you know each trunk will eventually be > freed when the call is complete. In the present case, you either provide > for every client to be connected or you need a disconnect policy. What I > suggest is a policy of disconnecting after some period of non-use, > rather than in response to incoming calls. That prevents "feeding a DOS > attack". Yes, some kind of disconnect policy. The connecting party has to play nice in that policy as well. If the connecting party always immediately reconnects then the policy doesn't work. Paul > Paul Kyzivat wrote: >> >> >> Sean Olson wrote: >>> My main point is that dropping prior connections to accept a new >>> connection is one possible policy, but hopefully not a commonly >>> implemented one. Every deployment will have some limit. Very few >>> deployments have absolutely no idea what their expected use will be >>> though. Proper provisioning based on intended usage and empirical >>> evidence is a reasonable assumption. There are other queuing/blocking >>> techniques that can help with overload situations. DoS attacks in >>> particular should not be responded to by dropping existing >>> connections in order to feed the attack. >> >> I certainly agree in the DOS case. And I am not knowledgeable in this >> area, so will defer to somebody that is. But at some point one must >> either drop an existing connection or reject a connection request. It >> seems pretty unfair if you end up rejecting connection requests that >> might be important in order to preserve a connection that hasn't been >> used in hours, days, or more. >> >> Unfortunately, what the connection request arrives there is generally >> no good way to tell how important it is. You might be able to decide >> based on what it does after you accept the connection. But that is too >> late. >> >> As I say, I am no expert here, so I will be happy if somebody can >> specify how this can be handled reasonably if every prospective client >> continually attempts to connect. >> >> Paul >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: Tuesday, January 16, 2007 7:48 AM >>> To: Sean Olson >>> Cc: Vijay K. Gurbani; SIP LIST >>> Subject: Re: TCP connection establishment [was: RE: [Sip] Question >>> aboutPoll: Proposal relating to keepalive, TCP, and UDP usage >>> indraft-ietf-sip-outbound] >>> >>> >>> >>> Sean Olson wrote: >>>> Wow.... that's one option, but certainly not the only one. >>>> This is where I like to introduce multiple servers >>> >>> Sean - I'm not sure exactly which point you are trying to make. >>> >>> Certainly one option is to attempt to over configure the system so that >>> there is enough capacity to accept every connection attempt. In certain >>> closed environments that may be workable. But it is certainly not a >>> solution for all environments. >>> >>> Presumably every deployment will have *some* limit. This limit could be >>> reached in normal operation if the operators don't have control over the >>> number of clients attempting to connect. That limit can support more >>> devices if they don't attempt to keep the connection up all the time >>> than it can if they do. >>> >>> The limit can also be reached as a result of devices that malfunction, >>> or because of a DOS attack. The impact of that may also be worth some >>> consideration. >>> >>> Paul >>> >>>> -----Original Message----- >>>> From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] >>>> Sent: Monday, January 15, 2007 2:02 PM >>>> To: Paul Kyzivat >>>> Cc: SIP LIST >>>> Subject: Re: TCP connection establishment [was: RE: [Sip] Question >>>> aboutPoll: Proposal relating to keepalive, TCP, and UDP usage >>>> indraft-ietf-sip-outbound] >>>> >>>> Paul Kyzivat wrote: >>>>> Suppose a server can support 1000 connections, and devices connect as >>>>> soon as turned on, and attempt to reconnect whenever their >>>>> connection is >>>>> dropped. Then when the device 1001 attempts to connect, the server >>>>> will >>>>> have to drop somebody - perhaps the one whose connection as been idle >>>>> for the longest. But that device will immediately try to reconnect, >>>>> forcing another device to be disconnected. This will continue >>>>> indefinitely. Doesn't seem like a very good strategy. >>>> Paul: Yes, you are right. I had forgotten about that insidious >>>> side-effect. >>>> >>>> - vijay >>>> -- >>>> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >>>> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >>>> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} >>>> WWW: http://www.alcatel-lucent.com/bell-labs >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>>> >>> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 16 14:15:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6tlt-0001uM-Tn; Tue, 16 Jan 2007 14:15:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6tlr-0001qu-PC for sip@ietf.org; Tue, 16 Jan 2007 14:14:59 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6tlq-0005VS-Fx for sip@ietf.org; Tue, 16 Jan 2007 14:14:59 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l0GJEfq6010168; Tue, 16 Jan 2007 13:14:41 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l0GJEdu01695; Tue, 16 Jan 2007 13:14:39 -0600 (CST) Message-ID: <45AD241E.7080901@alcatel-lucent.com> Date: Tue, 16 Jan 2007 13:14:38 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean Olson Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF9423256701614C26@esealmw113.eemea.ericsson.se> <45A7CDFB.5080705@cisco.com> <45A7DA65.5090802@alcatel-lucent.com> <45A7FED7.90604@cisco.com> <45ABF9C4.3090305@lucent.com> <4C1596FBF66C67478BCFE7B3F81FC1E01781EAA5EC@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <45ACF3AB.2080703@cisco.com> <4C1596FBF66C67478BCFE7B3F81FC1E01781EAA7A7@DF-MASTIFF-MSG.exchange.corp.microsoft.com> In-Reply-To: <4C1596FBF66C67478BCFE7B3F81FC1E01781EAA7A7@DF-MASTIFF-MSG.exchange.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: SIP LIST X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sean Olson wrote: > My main point is that dropping prior connections to accept a new > connection is one possible policy, but hopefully not a commonly > implemented one. [...] DoS attacks in particular should not be > responded to by dropping existing connections in order to > feed the attack. Hopefully, the SIP proxy will not be the only place where DoS attacks are detected. There are other places upstream of the proxy where such attacks can be detected, including edge routers. Indeed, DoS detection systems such as D-WARD detect the attack before or as the attack packets leave the network that the DoS agent resides on. Another system called NetBouncer can be positioned at the choke points of the network and allows packets from only "legitimate" clients. Yet another system, Secure Overlay Service, uses an overlay network; clients are authenticated to it before they reach servers. My point is that SIP proxy should not be the only one burdened with detecting a DoS attack. Having said that, dropping unused prior connections to accept a new connection is a fairly effective policy if DoS mechanisms are deployed elsewhere in the network. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 16 17:00:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6wL6-0007sy-VB; Tue, 16 Jan 2007 16:59:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6wL5-0007jw-83 for sip@ietf.org; Tue, 16 Jan 2007 16:59:31 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6wL2-0006Gg-VP for sip@ietf.org; Tue, 16 Jan 2007 16:59:31 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 16 Jan 2007 16:59:29 -0500 X-IronPort-AV: i="4.13,198,1167627600"; d="scan'208"; a="111820487:sNHT50021640" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0GLxSjg011468; Tue, 16 Jan 2007 16:59:28 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0GLxQVX025299; Tue, 16 Jan 2007 16:59:28 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 16:59:25 -0500 Received: from [161.44.182.244] ([161.44.182.244]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 16:59:25 -0500 Message-ID: <45AD4ABC.4080306@cisco.com> Date: Tue, 16 Jan 2007 16:59:24 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF9423256701614C26@esealmw113.eemea.ericsson.se> <45A7CDFB.5080705@cisco.com> <45A7DA65.5090802@alcatel-lucent.com> <45A7FED7.90604@cisco.com> <45ABF9C4.3090305@lucent.com> <4C1596FBF66C67478BCFE7B3F81FC1E01781EAA5EC@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <45ACF3AB.2080703@cisco.com> <4C1596FBF66C67478BCFE7B3F81FC1E01781EAA7A7@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <45AD241E.7080901@alcatel-lucent.com> In-Reply-To: <45AD241E.7080901@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2007 21:59:25.0050 (UTC) FILETIME=[95EE3DA0:01C739B9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1660; t=1168984768; x=1169848768; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20TCP=20connection=20establishment=20[was=3A=20RE=3A=20 [Sip]=20Question=20aboutPoll=3A=0A=20Proposal=20relating=20to=20keepalive, =20TCP,=09and=20UDP=20usage=20indraft-ietf-sip-outbound] |Sender:=20 |To:=20=22Vijay=20K.=20Gurbani=22=20; bh=qMqepkqGhJMSI7cJ3ARTKnTlNOjPdFzG4zcYzonu/nk=; b=lCbl1Hosxa7Z1f5mH8GIGKsCS3Vg6mUOkH3fqli+kGuem96sBWi8DK57BYF2uy2qDfb0Am5H f4tNzvfrcNaX7oIMywVfBjqpo5eUGD4TvFw/dXwORzPS3lNJYp+PUWUD; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: SIP LIST , Sean Olson X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vijay K. Gurbani wrote: > Sean Olson wrote: >> My main point is that dropping prior connections to accept a new >> connection is one possible policy, but hopefully not a commonly >> implemented one. [...] DoS attacks in particular should not be >> responded to by dropping existing connections in order to feed the >> attack. > > Hopefully, the SIP proxy will not be the only place where DoS attacks > are detected. There are other places upstream of the proxy where > such attacks can be detected, including edge routers. Indeed, > DoS detection systems such as D-WARD detect the attack before or > as the attack packets leave the network that the DoS agent resides > on. Another system called NetBouncer can be positioned at the choke > points of the network and allows packets from only "legitimate" > clients. Yet another system, Secure Overlay Service, uses an > overlay network; clients are authenticated to it before they > reach servers. My point is that SIP proxy should not be the only > one burdened with detecting a DoS attack. > > Having said that, dropping unused prior connections to accept a new > connection is a fairly effective policy if DoS mechanisms are > deployed elsewhere in the network. For connection reuse to work, I think there needs to be *some* way for the server to say "I'm disconnecting you, and I don't want you to reconnect for awhile unless you need to *use* the connection." A simple way is for that to be the case by default, all the time. If you feel you need to maintain a connection you aren't using, outbound is a way to do that. Paul > Thanks, > > - vijay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 16 17:18:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6wcn-0002hZ-Kw; Tue, 16 Jan 2007 17:17:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6wcl-0002hM-LD for sip@ietf.org; Tue, 16 Jan 2007 17:17:47 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6wck-0001X2-AG for sip@ietf.org; Tue, 16 Jan 2007 17:17:47 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l0GMHjAF004637; Tue, 16 Jan 2007 16:17:45 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l0GMHju04357; Tue, 16 Jan 2007 16:17:45 -0600 (CST) Message-ID: <45AD4F09.9010607@alcatel-lucent.com> Date: Tue, 16 Jan 2007 16:17:45 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF9423256701614C26@esealmw113.eemea.ericsson.se> <45A7CDFB.5080705@cisco.com> <45A7DA65.5090802@alcatel-lucent.com> <45A7FED7.90604@cisco.com> <45ABF9C4.3090305@lucent.com> <4C1596FBF66C67478BCFE7B3F81FC1E01781EAA5EC@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <45ACF3AB.2080703@cisco.com> <4C1596FBF66C67478BCFE7B3F81FC1E01781EAA7A7@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <45AD241E.7080901@alcatel-lucent.com> <45AD4ABC.4080306@cisco.com> In-Reply-To: <45AD4ABC.4080306@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: SIP LIST X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > For connection reuse to work, I think there needs to be *some* way for > the server to say "I'm disconnecting you, and I don't want you to > reconnect for awhile unless you need to *use* the connection." Hmm -- interesting. An orderly TCP (or TLS) disconnection can easily signify this intent. An unorderly, or abrupt TCP (or TLS) disconnection that did not result in the TCP (or TLS) shutdown handshake could conceivably mean that the server or some middlebox somewhere crashed, and the client may re-establish the connection with an alternate server (if any), or wait a bit before retrying. There are programmatical techniques that let an implementation figure out whether or not a socket was closed in an orderly fashion or abruptly. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 16 17:35:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6wtT-0002RZ-Bd; Tue, 16 Jan 2007 17:35:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6wtR-0002Pv-Kj for sip@ietf.org; Tue, 16 Jan 2007 17:35:01 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6wtO-0005fa-Ov for sip@ietf.org; Tue, 16 Jan 2007 17:35:01 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 16 Jan 2007 14:34:58 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l0GMYvHq019873; Tue, 16 Jan 2007 14:34:57 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0GMYjnR004909; Tue, 16 Jan 2007 14:34:57 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 17:34:45 -0500 Received: from [161.44.182.244] ([161.44.182.244]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 17:34:45 -0500 Message-ID: <45AD5304.8090006@cisco.com> Date: Tue, 16 Jan 2007 17:34:44 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] References: <7374777208BDC7449D5620EF9423256701614C26@esealmw113.eemea.ericsson.se> <45A7CDFB.5080705@cisco.com> <45A7DA65.5090802@alcatel-lucent.com> <45A7FED7.90604@cisco.com> <45ABF9C4.3090305@lucent.com> <4C1596FBF66C67478BCFE7B3F81FC1E01781EAA5EC@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <45ACF3AB.2080703@cisco.com> <4C1596FBF66C67478BCFE7B3F81FC1E01781EAA7A7@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <45AD241E.7080901@alcatel-lucent.com> <45AD4ABC.4080306@cisco.com> <45AD4F09.9010607@alcatel-lucent.com> In-Reply-To: <45AD4F09.9010607@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2007 22:34:45.0125 (UTC) FILETIME=[85980350:01C739BE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1406; t=1168986897; x=1169850897; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20TCP=20connection=20establishment=20[was=3A=20RE=3A=20 [Sip]=20Question=20aboutPoll=3A=0A=20Proposal=20relating=20to=20keepalive, =20TCP,=09and=20UDP=20usage=20indraft-ietf-sip-outbound] |Sender:=20; bh=flnoOktGjmtwULuVS2YNKqmfphA/QTl0FkL2gVTjNhE=; b=RN3OiGbbNGeKzQb/ZCU+kDLKGXDUpzbhphKzVUVZeDfwgPdnnMtGFIhhCVZTU8rViiKe0y/5 P7rLcgLIQBA5viRyfHxkpLrSxqWjVACdCLb/g5UJCmtBsSew5hCydUor; Authentication-Results: sj-dkim-7; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: SIP LIST X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vijay K. Gurbani wrote: > Paul Kyzivat wrote: >> For connection reuse to work, I think there needs to be *some* way for >> the server to say "I'm disconnecting you, and I don't want you to >> reconnect for awhile unless you need to *use* the connection." > > Hmm -- interesting. An orderly TCP (or TLS) disconnection can > easily signify this intent. > > An unorderly, or abrupt TCP (or TLS) disconnection that did not > result in the TCP (or TLS) shutdown handshake could conceivably > mean that the server or some middlebox somewhere crashed, and > the client may re-establish the connection with an alternate > server (if any), or wait a bit before retrying. > > There are programmatical techniques that let an implementation > figure out whether or not a socket was closed in an orderly > fashion or abruptly. Sounds good to me. Then there still has to be an understanding of what sort of circumstance justifies the establishment of a new connection. An obvious one is that you shouldn't reconnect until you need to send a SIP request. For instance and INVITE, or a REGISTER. This can still be abused by somebody who "needs" to send an OPTIONS message. So I think the notion of "need" needs to be sharpened. I think this is one of those things where it could be hard to define formally, but easy to distinguish real need from whim when you see it. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 16 17:43:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6x1A-0005aj-J2; Tue, 16 Jan 2007 17:43:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6x19-0005ac-IQ for sip@ietf.org; Tue, 16 Jan 2007 17:42:59 -0500 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6x18-0007fe-5k for sip@ietf.org; Tue, 16 Jan 2007 17:42:59 -0500 Received: from s73602 ([72.190.0.23]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20070116224251.EYDI16871.mta10.adelphia.net@s73602> for ; Tue, 16 Jan 2007 17:42:51 -0500 Message-ID: <095201c739bf$1115b300$6701a8c0@china.huawei.com> From: "Spencer Dawkins" To: "SIP LIST" References: <7374777208BDC7449D5620EF9423256701614C26@esealmw113.eemea.ericsson.se> <45A7CDFB.5080705@cisco.com> <45A7DA65.5090802@alcatel-lucent.com> <45A7FED7.90604@cisco.com> <45ABF9C4.3090305@lucent.com> <4C1596FBF66C67478BCFE7B3F81FC1E01781EAA5EC@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <45ACF3AB.2080703@cisco.com> <4C1596FBF66C67478BCFE7B3F81FC1E01781EAA7A7@DF-MASTIFF-MSG.exchange.corp.microsoft.com><45AD241E.7080901@alcatel-lucent.com> <45AD4ABC.4080306@cisco.com><45AD4F09.9010607@alcatel-lucent.com> <45AD5304.8090006@cisco.com> Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll:Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] Date: Tue, 16 Jan 2007 16:38:29 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Vijay, Are we talking TCP RESET here, or something else? Thanks, Spencer, who thinks it would be just ducky if we could use ICMP for ANYTHING on today's Internet :-( From: "Paul Kyzivat" > Vijay K. Gurbani wrote: >> Paul Kyzivat wrote: >>> For connection reuse to work, I think there needs to be *some* way for >>> the server to say "I'm disconnecting you, and I don't want you to >>> reconnect for awhile unless you need to *use* the connection." >> >> Hmm -- interesting. An orderly TCP (or TLS) disconnection can >> easily signify this intent. >> >> An unorderly, or abrupt TCP (or TLS) disconnection that did not >> result in the TCP (or TLS) shutdown handshake could conceivably >> mean that the server or some middlebox somewhere crashed, and >> the client may re-establish the connection with an alternate >> server (if any), or wait a bit before retrying. >> >> There are programmatical techniques that let an implementation >> figure out whether or not a socket was closed in an orderly >> fashion or abruptly. > > Sounds good to me. Then there still has to be an understanding of what > sort of circumstance justifies the establishment of a new connection. An > obvious one is that you shouldn't reconnect until you need to send a SIP > request. For instance and INVITE, or a REGISTER. This can still be abused > by somebody who "needs" to send an OPTIONS message. So I think the notion > of "need" needs to be sharpened. I think this is one of those things where > it could be hard to define formally, but easy to distinguish real need > from whim when you see it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 16 18:33:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6xmp-0003X6-5B; Tue, 16 Jan 2007 18:32:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6xmo-0003X1-2a for sip@ietf.org; Tue, 16 Jan 2007 18:32:14 -0500 Received: from out002.iad.hostedmail.net ([209.225.56.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6xmm-0007xI-RV for sip@ietf.org; Tue, 16 Jan 2007 18:32:14 -0500 Received: from ATL1VEXC020.usdom003.tco.tc ([10.158.7.31]) by out002.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 18:32:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jan 2007 18:32:10 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: streaming media without sending 18x containing sdp Thread-Index: Acc5xoswjrfNshhsRiitwk8leRGSWA== From: "Brett Tate" To: , , X-OriginalArrivalTime: 16 Jan 2007 23:32:10.0665 (UTC) FILETIME=[8B4BB190:01C739C6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [Sip] streaming media without sending 18x containing sdp X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Greetings, I'm trying to understand (or arrive at) the consensus concerning early media offer/answer within sip when no answer SDP or "preview" answer SDP is included within the 18x response. And since there was little activity on the related sipping and sip-implementors threads, I thought that I'd try the sip working group and the authors of some of the relevant RFCs. When not using early-session (rfc3959), is it appropriate to send early media to offerer without bothering to send an answer SDP or "preview" answer SDP within the 18x? (By "preview", I mean not sent reliably.) There are of course limitations in not sending the SDP. Some of the limitations are reflected in rfc3264, rfc3959, rfc3960, and the following posting. The following posting also presents potential reasons why some vendors might have chosen to act this way. http://www1.ietf.org/mail-archive/web/sipping/current/msg12640.html I think that part of my confusion stems from early versions of the early media drafts indicating things like 18x with sendonly SDP being sent followed by a 200 with sendrecv SDP. However after their incorporation into rfc3261, rfc3262, and rfc3264, I'm uncertain if an SDP needs to be sent within the 18x. Based upon rfc3666, the answer does not need to be sent reliably before acting as answerer. However if not sent reliably, does rfc3264 section 6.1 still apply? And if so, does rfc3264 section 6.1 still apply even when 18x sent without bothering to include the SDP (the SDP might eventually be sent within an INVITE 200 response)? Thanks in advance for a response, Brett P.S. Sorry about posting my question on yet another email list. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From cdavickstac@juanitovalderrama.com Tue Jan 16 19:00:02 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6yDi-0007kZ-L8 for sip-archive@lists.ietf.org; Tue, 16 Jan 2007 19:00:02 -0500 Received: from j39017.upc-j.chello.nl ([24.132.39.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H6yDh-0003ur-0n for sip-archive@lists.ietf.org; Tue, 16 Jan 2007 19:00:02 -0500 Reply-To: "Sherman Feldman" From: "Sherman" Message-ID: <1773723458.20070116185011@vuxcaikvmd> Date: Tue, 16 Jan 2007 18:50:11 -0500 To: Subject: Welcome, Tue, 16 Jan 2007 18:50:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.7 (++++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 hi (download), start playing most fair casino you don't know internet if don't know this casino US players are welcome http://mi0zoomshare.org From sip-bounces@ietf.org Wed Jan 17 02:18:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H752j-0003Nk-MG; Wed, 17 Jan 2007 02:17:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H752i-0003Mf-Eo for sip@ietf.org; Wed, 17 Jan 2007 02:17:08 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H752f-0005Ja-29 for sip@ietf.org; Wed, 17 Jan 2007 02:17:08 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 16 Jan 2007 23:17:04 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l0H7H4kK015108; Tue, 16 Jan 2007 23:17:04 -0800 Received: from dwingwxp ([10.32.240.196]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0H7H3ho008502; Tue, 16 Jan 2007 23:17:03 -0800 (PST) From: "Dan Wing" To: "'Paul Kyzivat'" , "'Vijay K. Gurbani'" Subject: RE: TCP connection establishment [was: RE: [Sip] Question aboutPoll:Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] Date: Tue, 16 Jan 2007 23:17:03 -0800 Message-ID: <056c01c73a07$7d039f80$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <45AD5304.8090006@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acc5vsCH2o7aPZQzScmSTelrtVgh1QASDjZg DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1975; t=1169018224; x=1169882224; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20TCP=20connection=20establishment=20[was=3A=20RE=3A=20 [Sip]=20Question=20aboutPoll=3AProposal=20relating=20to=20keepalive, =20TCP ,and=20UDP=20usage=20indraft-ietf-sip-outbound] |Sender:=20; bh=P2Im28hdsE6tKC8iJLZ+173qBYB/d63KSEMGR+wfbcE=; b=aLMFvtPs/S3s14zcS489URueKP/v6UErWGh1Qa8xFEsl742DHhmzl+6KHNq+8oNlKcvqIXf3 uxwn6SvCZKqmuWh+xiahYgMf66I0fbS+t60wzXsWejaMydM54ysRurVT; Authentication-Results: sj-dkim-7; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: 'SIP LIST' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ... > > Hmm -- interesting. An orderly TCP (or TLS) disconnection can > > easily signify this intent. > > > > An unorderly, or abrupt TCP (or TLS) disconnection that did not > > result in the TCP (or TLS) shutdown handshake could conceivably > > mean that the server or some middlebox somewhere crashed, and > > the client may re-establish the connection with an alternate > > server (if any), or wait a bit before retrying. > > > > There are programmatical techniques that let an implementation > > figure out whether or not a socket was closed in an orderly > > fashion or abruptly. > > Sounds good to me. Then there still has to be an > understanding of what sort of circumstance justifies the > establishment of a new connection. An obvious one is that > you shouldn't reconnect until you need to send a SIP > request. That doesn't seem like a good optimization -- how would you get an incoming call? > For instance and INVITE, or a REGISTER. This can still be > abused by somebody who "needs" to send an OPTIONS message. So I think > the notion of "need" needs to be sharpened. If the UA has already registered, and then the TCP connection is broken, it's going to need to re-register right away anyway, especially if its host stack or its NAT gave it a different ephemeral port than it had with its last registration. And even if it doesn't need to re-register, it needs to get a connection back up for incoming calls. -d > I think this is > one of those > things where it could be hard to define formally, but easy to > distinguish real need from whim when you see it. > > Paul > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 17 02:59:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H75hS-0005t1-28; Wed, 17 Jan 2007 02:59:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H75hQ-0005sw-Ux for sip@ietf.org; Wed, 17 Jan 2007 02:59:12 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H75hP-0003b9-FN for sip@ietf.org; Wed, 17 Jan 2007 02:59:12 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0H7vDPm032181; Wed, 17 Jan 2007 09:57:28 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 09:58:57 +0200 Received: from [10.162.252.245] ([10.162.252.245]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 17 Jan 2007 09:58:57 +0200 Subject: Re: [Sip] RE: TCP connection establishment From: Aki Niemi To: "ext Vijay K. Gurbani" In-Reply-To: <45ABFA1F.8060809@lucent.com> References: <000101c738d5$c0ca9580$f32915ac@NOE.Nokia.com> <45ABFA1F.8060809@lucent.com> Content-Type: text/plain Organization: Nokia-NRC/Helsinki Date: Wed, 17 Jan 2007 09:59:36 +0200 Message-Id: <1169020776.5210.8.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jan 2007 07:58:57.0316 (UTC) FILETIME=[57126E40:01C73A0D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: sip@ietf.org, Kai Vehmanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mon, 2007-01-15 at 16:03 -0600, ext Vijay K. Gurbani wrote: > Kai Vehmanen wrote: > > well, it's worth noting that in many real-life deployments the > > TCP registration does establish a reverse path (even though > > no IETF documents specify this yet -- waiting for sip-outbound). > > Just look at iptel.org SER for example ("tcp_alias" settings, > > other implementations use "persistent TCP", etc, etc). > > This leaves you open to the sort of attack described in > S9.3 of connect-reuse > (http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-07.txt). Hold on; let's clearly distinguish between the UA-to-proxy connection and connections between proxies. The latter clearly has this problem with authentication, since mere connection establishment and sending messages in no way means authority to receiving messages over that connection. The former case is different, since typically the first thing a UA sends over the connection is a REGISTER, which gets challenged and authenticated before the connection is "trusted". So where is the problem? Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From forwardetpi@solarpharm.com Wed Jan 17 05:00:31 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H77ap-0007fS-44; Wed, 17 Jan 2007 05:00:31 -0500 Received: from [203.128.124.112] (helo=solarpharm.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H77ae-0006ol-ML; Wed, 17 Jan 2007 05:00:31 -0500 Message-ID: <30fd01c73a0b$a6fe8da0$9b281664@forwardetpi> From: "Marguerite" To: "Kiesha Kim" Cc: "Bao Simpson" , "Wei" , "Ocie" , "Tawanda Williamson" , "Lilly Garrett" , "Eustolia Hansen" , "Melany" , "Lesa Owens" , "Willis Greene" , "Alejandra" , "Adella" Subject: Can you tell me Date: Wed, 17 Jan 2007 07:46:52 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_52C_1EB1_E1C809D2.333612FD" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express Macintosh Edition - 5.01 (1630) X-MimeOLE: Produced By Microsoft MimeOLE V5.01 X-Spam-Score: 0.7 (/) X-Scan-Signature: 00134749b78ab2213964fc53d03de937 This is a multi-part message in MIME format. ------=_NextPart_52C_1EB1_E1C809D2.333612FD Content-Type: multipart/alternative; boundary="----=_NextPart_AFF_3B05_B7661291.05DF9642" ------=_NextPart_AFF_3B05_B7661291.05DF9642 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =60What?' =60I, Mr forgo Fogg!' replied colourful chalk Aouda, board che= cking the pulsatio girl =60To attraction Liverpool? thrive ski Why not= to China?'=60Please let large me finish,' blindly returned speedily shut= Mr Fogg. =60When I He question followed the clown, and scatter soon limit tax found himself = once =60Perhaps I measure do, as imagine polish well teaching as anothe= r,' said Phileas F =60You have only to scare try, son harbor tickle of s= chool John Bull,' replied This was powerful the mark Honourable paste gleaming William Batulcar's e= stabli untidy =60That we might transport have made the tour depressed corporal o= f the world in=60I know it, spade leather tongue Mr mistook Fogg,' replie= d Aouda; =60and I ask yo=60I said Liverpool.'=60Madam, you could pause no= t remain in employ box name India, and your sa nail Passepartout serve entered and pen scared asked for Mr Batulcar, wh = mow Aouda thick turned pale, and bare her blood enormously ran cold. Sh= e sei done =60Mr alvine Fix,' said Mr sleepy Fogg, voice =60pardon me, = but this affai   fast =60What do you jam want?' said fortunately he grain to Passepartout,= whom parturient =60No doubt,' frightened returned view Mr shelter Fogg, =60by = not crossing Indaccount =60So, Mr Fogg,' resumed show Aouda, glass =60not= fruit content with re=60No!'play shown =60Yes, madam; pugilistic but cir= cumstances have delicious been against m addition growth =60Would you wriggle like a throughout servant, sir?' ask= ed Passepartou curtain =60When and encephalic where you float pack wil= l,' replied the American, =60 Aouda in satisfy vain offer attempted flow= to retain bit Mr Fogg; ash vai =60A servant!' sort cried Mr Batulcar, annoyed bid disease caressing the = thic =60No?' Mr laid young smoke Fogg save quietly shut the door.wring =60But what nup= tial will become gather of helpful you, Mr Fogg?'=60No. I am include sett= ing grow bled out sniff for Bordeaux, and shall go t=60As harbor for me, = madam,' greedily replied need comparison the gentleman, coldly, =60So I can be way crowded without stuck of no use to you?' =60Sir,' sa= id round Mr Fogg structure to his adversary, =60I ovine scissors am in a = g =60Well, what's that to me?' unripe ask enter obey replied Colonel = Proctor Phileas gold act faithfully Fogg had won his wager, stamp and had made hi= s jrang =60But how steam do you average look upon the pack fate, sir, whi= ch awasilky =60Money episcopal shot shirt is no object?'pontal =60As I am= drop in the damp sock habit of doing.' =60None.'=60Sir,' run said Mr song vanish shed Fogg, very politely; =60af= ter our mee =60Really!' =60The devil! commercial I butter window should overtake so like to cross= the Pacific Nothing, say star scorch you? Perhaps so; nothing steer post but a charmi= =60At least,' chain poison support said Aouda, =60want fill should not ov= ertake=60None.'smile =60I misspelled always have cooing no friends, madam= ' gold =60Ah!' said payment map the burst Honourable Mr Batulcar. =60You ar= e no =60Will you trick appoint a roof meeting amount pass for six mont= hs hence?' =60Why heap glorious not stupid knot ten years hence?' =   =60A end back man straight sticky dresses as he can.'=60Your relatives--'= ------=_NextPart_AFF_3B05_B7661291.05DF9642 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


=60What?'  =60I, Mr forgo Fogg!' replied colourful chalk Ao= uda, board checking the pulsatio    girl =60To attrac= tion Liverpool? thrive ski Why not to China?'=60Please let large me finis= h,' blindly returned speedily shut Mr Fogg. =60When I    He question followed the clown, and scatter soon limit tax found himself = once   =60Perhaps I measure do, as imagine polish well tea= ching as another,' said Phileas F  =60You have only to scare tr= y, son harbor tickle of school John Bull,' replied  
This was powerful the mark Honourable paste gleaming William Batulcar's e= stabli    

untidy =60That we might transport have made the tour depressed corpor= al of the world in=60I know it, spade leather tongue Mr mistook Fogg,' re= plied Aouda; =60and I ask yo=60I said Liverpool.'=60Madam, you could paus= e not remain in employ box name India, and your sa   
nail Passepartout serve entered and pen scared asked for Mr Batulcar, wh&= nbsp;  mow Aouda thick turned pale, and bare her blood enormous= ly ran cold. She sei   done =60Mr alvine Fix,' said Mr sle= epy Fogg, voice =60pardon me, but this affai    
fast =60What do you jam want?' said fortunately he grain to Passepartout,= whom 
parturient =60No doubt,' frightened returned view Mr shelter Fogg, =60= by not crossing Indaccount =60So, Mr Fogg,' resumed show Aouda, glass =60= not fruit content with re=60No!'play shown =60Yes, madam; pugilistic but = circumstances have delicious been against m     =    
addition growth =60Would you wriggle like a throughout servant, sir?' ask= ed Passepartou    curtain =60When and encephalic wher= e you float pack will,' replied the American, =60  Aouda in sat= isfy vain offer attempted flow to retain bit Mr Fogg; ash vai  =      
=60A servant!' sort cried Mr Batulcar, annoyed bid disease caressing the = thic      =60No?'    
Mr laid young smoke Fogg save quietly shut the door.wring =60But what= nuptial will become gather of helpful you, Mr Fogg?'=60No. I am include = setting grow bled out sniff for Bordeaux, and shall go t=60As harbor for = me, madam,' greedily replied need comparison the gentleman, coldly, =   =60So I can be way crowded without stuck of no use to you?'  &n= bsp;=60Sir,' said round Mr Fogg structure to his adversary, =60I ovine sc= issors am in a g     =60Well, what's that to me?= ' unripe ask enter obey replied Colonel Proctor   
Phileas gold act faithfully Fogg had won his wager, stamp and had made hi= s jrang =60But how steam do you average look upon the pack fate, sir, whi= ch awasilky =60Money episcopal shot shirt is no object?'pontal =60As I am= drop in the damp sock habit of doing.'     &nbs= p;
=60None.'=60Sir,' run said Mr song vanish shed Fogg, very politely; =60af= ter our mee  =60Really!'  
=60The devil! commercial I butter window should overtake so like to cross= the Pacific  
Nothing, say star scorch you? Perhaps so; nothing steer post but a ch= armi=60At least,' chain poison support said Aouda, =60want fill should no= t overtake=60None.'smile =60I misspelled always have cooing no friends, m= adam.'  gold =60Ah!' said payment map the burst Honourable Mr Batulcar. =60You ar= e no    =60Will you trick appoint a roof meeting amou= nt pass for six months hence?'     =60Why heap g= lorious not stupid knot ten years hence?'     &n= bsp;    
=60A end back man straight sticky dresses as he can.'=60Your relatives--'=       
------=_NextPart_AFF_3B05_B7661291.05DF9642-- ------=_NextPart_52C_1EB1_E1C809D2.333612FD Content-Type: image/gif; name="dsun.gif" Content-Transfer-Encoding: base64 Content-ID: <0463501c73a0b8a6cfb5706cd091d5@forwardetpi> R0lGODdhkQGTAaUAAP///wAAAGZmZrK1t4CAgCcnJ+bd1D09PfC1tf8zM/9YWP8HB/9/f+iLi+bm 5unPtABj/9TQyMincZSt3tacWlJSUrWMTkuPwipztZycnHt7e6FwPaampZxqMdxnHb1GD606EHlW PpRjLgAAgP//AIAAAOV7e9tKSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAkQGTAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4SFhoeIiYqL VAECaAMERgUBlZYDRgIBVwSUlY9oBAZqnpaOUaJFB6aVmEkEmwanjLRLs2YFoES5u7FclKkDlKNl sMRovFWakwW9rkfGtdK2umXJu9XCkludz0K3Y9Fp11PLqs3Yr77T7EXgQsKWkubaQrAAnZ/Emvql qtkFCMBa5ShWvFZCCJL7Vq3ItVmwLgHg5+ggwlKnIjoykO9Wx4ZWFtoztU3jI43eKBXpBsAipmWf WDLE50nAKIr8hlRqd+ed/ix0qyIFeDnLEaxHwg7gGzqRqUhywwa2NNcqKYACQJkOqYfkGi96OzWJ ijdSElZRsNDGStuygFK2VrOIhBv11ICMmxyi2xoQwKy6o05BLCBUktWjLXcGzsvTjMJjkxrKvPoI b6yh14QJhUyZmakDRF3dg+VNs85st1h1nnluKeeZw2bek6VLc2atSR7nZqV05dDJI40c2AvPKGPK 0U6t+tbs9madm3Y2xvU5yTtzCZsrLbiZVdUAaV09BelayDLSRDqaInJ3W6/VqyNRLA9PAL/tur5e 9m5RYhKMvR1xQID/eIJJTaDc49BxifVXiUABBKbWgaJ499s6O0k33RgO/npDxHXrLJdWhLnw4pM9 /FQIkkj0GYPeVusc8c5V2p22lH350AeMAFZ5dVKEfjVEWxGv8cWKh0OIdFcuAhEGT0SPDDcJg3cZ sJxvEgYmgIJzYRhdjBt+0WFXkuFm1yc0gffTElhdRSBrvrlyHm5LuQcNkL0Y4GOQ0C0FgAF3PRMA fjYmRxxzT4wp44p7vTgEadgNcWWhYCZXEpp+HUofjZyGOYZ31gkZQFbinQmkJqCoFFRbSok0Y1Ny 7reYX0yhykwqEU1Io1no5ASWJD8RKlutp1i5CWIArGqdamRmcmorL6okjqTEUYJJXC5eBspdG92Y XVN6gempFy79B2qy/pX0ZZ5WKo2Ubqn6pOkQeS+CJZGx8Torj6Cf2OXJAZoMgN1Hy+0Z7FL3qodk EdxusvA3b36TrgABcWSJTW2BtwuAzzSssaU6EecxUe5oOK4YAzx88jQpn2zJyjDHLPMv4s5s8804 l1xzzjz37PPPQAct9NBEF2300UgnrfTSTDft9NNQRy311FRXbfXVWGet9dZcd+3112CHLfbYZJdt 9tlop6322my37fbbcMdtBwIJ1G13AghAQXfdRihQd95W7J2AAksosMACDJCBwAKEy221AQskMEQD iet9OGeHA34F5JIrcTgAlIfhgBANRO7446YP0fkTkKcuhOELFCkF/udK0C6G30PIfrrTtjf+p98K jO5AAwowwMDqfzJw+RB+xz553Q0IgcDxdOfdQN2c2Z68A3WPrjziee/duAEMKICAAo0H73fe65Ne d+UJHM7A6AgAbgDwo0tf/+C7F9268QuQ3gKiFz8HcO9wuMsdAxbXueDFjxifYyAAFse4BBiAb58j gu3iV0HTwW5+hhvd51o3uPIhEHaDi6Dk4hc9w1mQgolbHAEX4AASwi56/RNa6wwAOSFkcHGEUx7y hEA+ACxvhc5bXOUyuDzOfS9/RExd6/5kOtulznB5i1/ljBhALvowgAYYXfyEoLzKldGLE2QcAJQX RMTlUIepw2EG/ml3RiLFMHIKGMUY1+hGADwQjWzkIRSj2DnaGbKKqTvjH7/ISEBGzo11POMcTXfG Or7xZ9prJB37qMElpu6PbBRCAR3pOyJJEZGSO2QXlTfDYzCxi58bYyX7KMkubjJxlrxkzzIJACym MW+5JGLlFge4Rb6ykQ443OhKScVCorKZjTScKJ3XyGN+znBtbNwZfUlMPuKSk7rMGQUZBxn5qbF1 AyQCBRvXwMPhLY11o6Ef3fm6wy1Ac2lE4AUzx0HYqTGZjLsn6Ow5ihuWDnHfa94j70nC7znPnIRD p0TDebQadiGMSrCoFnhoBWJAUaNGAClFR0rSkpr0pChNqUpX/srSlv4BAderm/mA14D8PcBvdmsA D+lmPpf69Ar27BwHE5A/gB4OhzeVxvHuBr023E9yQEQC3XCYhgyqoXpfC2o9jzqEcRJ1eOywJOy+ MMgj7DNxpRuiAAWaBoCu4aC6s5pW+Sg/InAQcTUNKzjjh88sJFAJddTdIplAzSyUFQ2DzYMBKMeA BjyAsTp9wAIh+1jjRXaylpWsZR0wvQcUAaYN0CkROAvaQZI2tGWdqz/xic4FeHYJoH2tZjFrv9CG j6psyKUEfze4w4KOfAnYIk6LKb+yDteb+mPe3+bJQ+P1tasIZOwCyZc4BzjQd9YNrhGKSDrgbjF5 xlsjA0YR/lMcTo9w550g9Yiqunv6jX7rDZ9Myehc4413eqPYG1WBB4DhFe94T6Cg5A7auTuajsBk pCvhYEc4sOaOhTBcq2QzJ2F74lOrD7AnM+mqxiQ8oIAMFOMJM1e6BUZOec9FQy5pJ8N5DpLATzSi 5AzXwshhbsZtHG9dZdxLwv0RnKa8Zw2ZaF0EIrC/sSuxXQ/szhi3F73+hCcfJSdEBXdxmvEM4Dot GEIvfm+gWoZqAJPpw/lF7oAVhAIHeUhQAxA3dhJ1MxWZfOBBOnSc02Tc94SKwD0TIah0Y9xrjXDX FHMxdfTk4PGOKj8KhvYNKzbdDzvc3izGznAQDGAwS5c3/s4i94yc7q+lu+m5K/P1fox0qxZdqMFP CjSxUxSzJ6GpSkILdHnL43Evbx1Ae/YSmP/kY/E+V+Uo3PB8R93vUZE9QKpy8AGBdi1u++vcg3ZR szelJwCwjcI/03Ocz3WAQ9lrBAQf+sPy+3DwGk1hSIMz1JMc4h8faExNAzmxs0xcYgu9BKsKOH/W hHP2XK3Hwn4Rd3V84CFT6br2FnwU8SajG2ncPOUNwcLz1CkxgtmEDEfOse6kqscTAPKPT86dMEVg X9GNN1+DTot+fjlCtf1F03m84aTb9ZGNEHMLK5oIZdytu797TGgu+eF8ZWQwkz6EfM8Tn/EbqxAM aASr/h764rDs9ZVNyeeHf5bCoXTxwo1+9HlqMoOsrDkXkfdlpkv8u09Y8zwNLne5T52eJBQgl9k9 Qgv7GZ3Tw3vNO2fPe2our621H18FXHM0fxem//WtGsQqz12Hj60OZ25UjZjNInx5gp+G5A+ZGz/C b72REtfc55Kp73PidoPOSyzqjznFL/OSuZyffRelOc1Rk5F+NDzo65ArhbRKfIjGn3IRDAe/Pir6 g+PkrIVRyObMUT/Tro4u6TQ3bu/Rk9WtmyEnS2zf8b7Bn/GEO0SLQOC8Y/OUNva2MtHpUIjbc3go d+c+OdPPi3sbm3dHc3kWWvongK+zRQw0SoVXev7E/kx3xU7aBlC+JEAU+Hb8c2g0hE7T1gSQg0Md aEoemE5EUDrEQIJ6ZwAsl3KMMzxRdz91dT3k9EETZG0D9ADoFjnQhmKjQD4LiAD7BDjXQzw9dYMK 8Fo0aE+Dlgci5QScsYRTJ3lFQHVKsDhmNVqlpExlhVFXoFZamDusE1dE9BofpUHZA4YyUz9lgGaF t2FNg3lHoFOnZ3VbEFps+FNcMDz1k4foIzWeNoVuOFReIId26AWPxX5JOIiIyAV5mIdmmIiO+IiQ GImSOImUWImWeImYmImauIl2AAGc+ImguDYQMIqkWIqmeIqomIqquIqs2Iqu+IqwGIuyOIu0WIu2 /niLuJiLuriLvHgFnliJvziIwWgFwyiJxehTxzgFyfiIy8hSzQgFz4iI0ZhS09gE1fhT12hS2agE 29hS3ThS33gE2+gAEVCOEQCFbxSNBsRDgoSOcROORnCN5HiOBjSP7ng6zegANriI9WODDyCFuwOP RTCN9liPBlmO9/iOSKCPeSgBDvmQeWiDjYg2AkkE0RgBE2COGrmRGUlRyciQCCABFEABD1mSEhCR /yg3FTkE+TgBLvmSMBmTLzmRbHOM+xiSJBmSJimSJokANtgEDiAAFZALvVGOZjUgU6cyQrOSQrCM DiCTUAmVNFk0DPIFx8hZDmkBJ/mQJMmVItmV/hDpjgcQAesyOhXwMHeBIkvDlACwjBNwAXB5ARgA lxhQl3Qpl3j5lhNwjwMwIKABABUwIJiQAT1RlSZDK1rwMtBRlYj5IYw5kEYQAQ45kjv5kFrZlWDp kIdYBBkQIA5AJ0eQlk7DlsloAHFZl3OJmhjwlnaZmnFJlkzgKGMJABEQMXLAIHnBGLmJBdHhF9+g E+7wm8L5mCwZmVm5k5RpASS5nMs5mRIAhQegAekBKBogGgdwlsVBmxpAmC0RnUo5CMRJjFnwkXiZ mqiJl3Kpmq4Jm0vwmRUwBO+5B8cxn74JnFbQm8KZn/X5m/SZBMcomRRgAco5kgFKkgIqAQJa/qBf GaADAIUBIJ1FEAEFIJ1CCS6J8SeBORUTYZtioJiNmQUeSiuMeZiH2ZTjiQQDkJ4qepetWZ4YkAHs uQSaMDoRIAkOoAEQGgECADD5QwAAowEVEAHV2ZnnuKMCEKNb0J/8+SG+KR0kip+OiQRK2qRM6p/G GaAbsAEWkKUEuqXKKaADGqAWAKNK8KACIp3bCQAZkBeiqQFK4aYDYAAQaga6WZ/h+QS9uZv6aaf2 WZWkuZApqp6Cqp4XkAEN6gQRoDEYc6OXEQGyIAlAOhEVE5hr6qME4ADX+QVTCqVNmpt6aqcjapjB CZxTGo8hxQFfCqYjCaZhuqpbSgCGio6Z/roVkhCd/SWUtZEXbkqbBEEeYDCfpToFULqpTFqqf7qQ EZABgzqosHqOUCAl8XmhBlABBmSrAHOhAKABm0CWQbqhmlqlS0qq9rmf4Fqs5aqfnBqeyRgBquqq rAqmWroBGcABA+CsSrCmx4Ax1notbKqrSgEaDiCaamAyu+mkuMmpEiOl5ZqukIkF0WgAHCAAy1qX WxKnUpAW7iGaA1ABFCOdibqj3LmrQqCjgcmhV0Cs9Fmnw3muK0uu40qlL2uqITUAWvqu8Bqv81qv ACmjB2CoAkCYSXEXPFIBAZABBqAJGlCbBdCZhCEwa8CwjemkfRqqRoCb5hqzx7qQgMIB/hkgseop ANvJAfYKBZ+JJ+DSlwlBodUJRSL7maMjsl1gtfuppyo7twl7tQhbpSp7p04ZCR3QAVm6AX8LuLBa r134BEKqAcQQASlTQ2k6ABkQsIabMuyYpgOLrvm5tywLs3tKrlBbnA6rtRo5AFxrH/ahAQRAr/Xq qAlJBDs6BEH5oKShAQVwlhRRAOU4HB4LHkz7ncJatQc7rnWLmIb5Mueim8G7BE75AJArEM4Lq4Y6 AA9wuNMxvJ+quTHbsiN6tXuatUTiqIZbjinDAeSbMhrJjlFglElZr2qquDdqAF2bMtEJKOzbEtWJ D74LB8O7uV2wjP7IvCkTwP/7v9Q7/g1yW7cIfLfiyrlVm7md672jVUPsyLrlGEY1tI4W3LpTUAHS GZRISgghOqpiUJoDXMIm7I8FvAjHq6TWm7frcbx9EqUy64tJYJA2fMM3HAZHCzAf3DSliYLTy44S KZEoWMTsiIIa7DLZ27knGrqGlcSieATriMMYfMFWbJBCE8L8S8NOTIkfScVgnMNuA8GRyJYB2cRe nIhkDIlmjI9oPIlt7DikyYt0XMd2fMd4nMd6vMd83Me52MVwrMZvbIyCDMiELI2DXMaFzMVpjMiG TAVQXJNMgMEWHE5rPAU7KzV3msiw+wALSqA5Ob2RTDaXLMX9JTxllclJULLv2ZeZ/qq+XBABJRup buqXA9LDMSzDuXyyBFui6yExJdqwIfXJoFzMJ5mSULCxwwG2QsCdRuCm3HmoNbyjAKMUrnwAmNqz ebDJysjJT2iQGYzF9XjKQOkWWxGf2NkFBTAKDmDOByAJD5qozqywetunvAmz1su9LivMo0XMxfzP lInMS7CxI3sKtZkbELrOSvCzQkC02fqeA4KpvtoEHhrMjdDLxashv2yR3nzKVEyP4VxDuPzMAQCb hhoGd5E/aJubamsLC+u5J2u3L5uyW9yWR/AAAJ3TI+kBoCwBm+kQzwC3CO0EWvGZyUKWSIm2vxuu 3MwEeerAMw3THP3IUxfS53jE/u1Yj/XLBEMyEfBwv/hwna4QlAADtgSgAQ7AsbRppIOUqEs7OpgA oWbKuC4d1TRtsCWzzxZ9sFK7xKA7Wjod2P+MAJInsP2F1jg6dUYKm7Z61uwslJHrmIrbEtmaEL0x p1AArDVN1DKNuQvcvR2NkDdswSFNuhrs0EE5shM6Ee9pDu+czSljHLLgqBrjuhcDGWZK0S+dsp4K 1cHsyyIMqhb910OA0wTqAR/A08e93Dv9zwJNBNoaUtGdLJc6q7YaKMlCjnSyppXwl5JislJAsPzZ 21FavPS8mJ/qsqVMmzobxuRIviMdmkV70mmbrYS5pt8Q1/H5oBJMrZiK2URE/gBEGwBQlNtOvdvc i71M/LlRvdk2SQE87QESPuEQrtwTTuHHvQHSXATTzTB50a2vmyxyjQnxnAqj1bUIYdmJKdV4LdO/ LaovLaLH4Ynrzd6sK8HtyLixGt7XKikdjKt50QluCpu4sbEdmx7OjN3fAODWgeCfreD7zKdRTqzK u10VLuE7LeEfkNxYTuET/gEgoOG+dRcx2sp5QbJIKeL5na3pwp46mjsGnuYxzeLC69nBGayl6qcd DbuMe+MGpONbHQW24uPJwq8J0TI64QpKbatDQLsFfgwGXtf2rL11PpxWW7Dn3dnceAQScOGertxX XuFbHgIiQAAW2yxEhBSb/uC22dobjD4UaCvLc0rmkuLMcl4F+dzZ6b29Uh7cwWrTVC3FjBvAkKuz VSALHeMWQruxRYuploDNR4EJs1u7QT0ohloB3Mmo2nzgea3LCdwnGf0lv+ypGu0E67oBXP7pF77l YE7qhTu2RyChPNK1BoS0iQqrw5Eyyn4Ua8ojRwoj4DEAGnASNLHauD6q3+7ilx6uDVzpMyyeTkCO pJuz8D4F8zzsjgu0hPmzsU3s+ZMB7jvZ8ECOOMqeknvqabC/fs0FyxgBGwACIMDuMg/zMO/uhsq6 QAny2W6+9ivt9dq4AWxAIA8ZBuCoZ10aPH/RLyzeUJ2w4S7jfb3RxFnj/t+Mw4JUBkwxraNsB1q8 8lvQjMkqAiFA8zVv8/SK80Sj8kwc7FGgju6IxSgTmAKw9T+TjzqeAQKRAXqvumh/NF2/9owM8VpA 92XjlDj+ABoZxFmtypLM9oscwePs0e4N940f+IcchU8Yhahsw5JP+FdD9XYYxyq5545cBaKfNaCP jY9v+n7c+q6fim35+rI/+7Rf+3lM+sK4+lRw+pfE+2+T+sio+938BJx/Ut0ohYwPN6kPxCVpg55P kcRvWlfvxo5PRJ5cmQ4Z39Q/ybALzincNjV+/dj/kBve+5P8UaNd8U6AumSbv3W/5wYw/jtZ/jmk jt1fkPVY9FMpBOa8/gRzSgBAIAAMiUXjEZlULpnNY8AZLUKkS2rSIdFuuQ+udlAVj8ll8xmNvCod Q8c7wom86Q5DxFAdHAKRpeEgTbAooHDwyXAoEXERoJFo7SzS6MFio6NjgwtBYsOTy68J8OBAA0CD 1NRo1C3s8BWWCCr2aNKoDYAubs6gDm4A10nAIEAIIEJjYE8o4qAgGTkDgEDDlBpY4EDAb0DDAJXg cNYxFspcFmmcfF19yJbsPVfCkoCDI2OL3n5gy7UpohgRAeGQDJhFwBgtJo8ctXtVSB3EdO0YqlmC C44cOwZ6vekVJxgTA0IqzDJQMkOGABlGHgB2MhCBlacqODhAwGaF/mMFXAoIkCdNxHLr0D0hRBQp gHhi4lWyYIHDx3kWOhAY0MuLFgshl/ARyJWIQYViKCqidW7WuLJE0zZZmisXnDm+cn3kADaJBgGo ArhCNaTUqUBD/gLQdipPBT/ZAKvqOzRdQ0UUzxl55BBpZbNTBDV9+hRoBAkiNgADYIDLhlBNVLoy NvBABVdiowHoFobanWR7cApQLO5o0Ydsg282K9TKxbhvsNjFi0SAMoM6BTeuTniwypFDIvgmZd2R v0GYJ5cnLhlRccsSMxt5KyXe1KcSWnXIEEo+1dVNAugcIA0A3wKcRSyYdjLFoKtK6iaAZA4bTz3y zEmLsqTQM0o4/nKQU+KtNnz5cCMHQHJiAIIGbKOwwP7SqTAAeArDgQBQHCyw8IZTQq2iNjwqxyXa ylCpzpLIz4JQDBhgDgCc+qyD/ZjwaSRcNJBGpSHEuq7GxwrTcjBBdpSQQuPCTM+yMtHZ0SI2lgNx I+ea2OMAabrrb4+VBnhRpm6aKQDAwgAiIANnlMGzP6CCWki4H40LTtHIFm3nvSji++wzjNowgNKn mpQCIL2IcMA3n6ycJUXHwtjy1C4PzVDCRB+NDM32YnVPOTruiADXXPFwk4kIlMnjyF9/9dU0AsIJ FigRw0pmGiSVcUA6CBEVU8eyfiQvqUbdERKJJT8TDwAiSXOS/gk+ADQsjCuvTFEIYlJV5F1pX3X0 vFmvpVdD9dLEIq5gpZOuF17HGtgJiNjD8LzyHDIYSG3NozWNeCLIdL4HLJ5qg89CYKkKlYIpZgCU RmpwT2kMKoVOc2WSzVx5N8O2x3qtPQ5Hai2spVYRr+KI517iGpHgoAmO2UxYInUiniwwycQTT57y RISoLRAhBNOkgLaIb0zOAFokkeXOD1+RBfhXlx+ml2hDFpbI4ETUqtCtnMVukyMPDbDnOaH19rKi RQ85Ou4kJhYhE9KW7oDwqDegmgBy935c3laD7vDWAe7ypSPL5YCc887/5hYJaDGJGnHEoyYckxBK y9vz1qM4/hjhgTvMFUldc71DGVxd3533wNF4K4LFEz+9dMRD2Njx3pVfHueLcM3d9uiTZ576xwFn 4q0HMtggBOJPp7qCEABlvfryPY9UF+l9md789mm5PrkkDLD4P+6Pv797QJV5wP3+XYefTcxRlv8I +D7Q3cJiD4jAAyyXEgfuQ4F3MFQBKSi7Q9ihghmMWGcg0EEPfhCEIRThCElYQhOeEIUpVOEKWdhC F74QhixUSgxpWEMb3jCEGwzdh9zAFbpoEIivgF8QiWi0A96CDkVIYuiK2EQzDNGJUSwDFPclRSvu jYpX1GL8frdFL1rwi2Gc4hHFWMYnmhGNSCNjGtnouza+/nFbOoTjHJOQRToW0Y6cueMeIcHH8mFL Ems8Qh1wtUQ/NjGPaXBAAaJQgQM4SXePuwwgydII2MkCbhDr4kVEJL1CHhKPTAjgKDv2mCbECFyy 4RxyKPm6fCXsZTpq3iax4MnokQ+U5lvKKHnJHCeUhDr8AZfn0naoYrKqPXqk5SBtGT2rRWEULkFF jXKpt6T1kpcTFBxCZJSLKUWgAkJAhSsCQIAK/OY2VtJGHqgBKpfA4pgTOptk1paELyWzj3K8RTOl 90wnAMQV76zmzWJxTVvZAaF1E1HAOgIH8glAROX0ZjmnMwABMNIROjFGBJ5hGyFkgJEVdQY8kYke t1Vr/iKxk5W+EhnHW0hnAsqI6QAmMIEI1PSmNkWSGDTQl//0r29jgd0l5xlUZSLRI3PAg1LnIiKE NhUPFylFTwdzpcBc6TGoNIwpCmAVg/jhMVcCzrxi1ijMaMZCQkFTS4N0BAPUdAIXqGkG4BrTmtJ0 psNsAh8ScoxsQHQaGnCnK7qjjTf0NAPdONeN9IYWm8kylmWw1VJxdSs8OHRX6VtCSpThE27M4qpp IWcYAlOMagjWRmKNHKNchU/W3kytLF1jTuta25naFa64NAJAgkkMPEhUpIz0LTF6Y6cKaNNsQ4Pl PWd11E8dFKEeUWhCGwot5BahS8QQglURlBZpEKMN/oHpKnfyENZWkuW1CevRZdhB0PZG1rljPAJt bTvX+k5At0VohilP8oYspQsK/bWJKnzSV5Ki120Vqie+YgukWSqxuthc31WwUGB2FqCcBb5TT4oR owJY1GQvUkliw7GyORkYDZlULyHQOhm1tU1MKs7nMolA37nKNa44rmsGODAGIfABFyG7qKlsQ6Bw djQXAThAfsdw3vWYZ71nXVjRXum3B+u3qRLWxbOwEC3b5A56wkKSzph1DC4r1krPyt3yiKavQbD1 HQ64R23lmoEL6HiujeNp2PpjGxoRWSx7AI8yAnKWJrfWXq59VXNnvAro8dN2DWQfH4nqYEEyRXAO /tS0pifgwAtYhcmgKsYdMDyQvmigALIxcYHzhGrZXHRkwWSsFMo6LzM5bKWWjm+NG7hpX2+aA2Me KO/grIQI2PkCv07JnTVwlyp0LQzB8kMGvOEAb0ina9OutgaI9eVJl8HJxan1hWhWZQyt142DpFvP 2N0zXw57d8U2NrUFcGd731kAA/HnF8Pd2sy0uCEvZhhbZFxHeHtR3l3OADX0ope96O+6Bxe3PYXG VokzL+HMfF6vUxJsXTE5l5W2sgEvbsWMK7GQcrEdIZNU8vJZ3OXEFqSWfxhzjNvciSd/Ls3fjfPe wdznndN50HNO9CAO3ehEBHrSrXlppmcQcEt//rp8aTx1IErd6gqBMw653nUYztDrYRf72MledrOb Pet+xHra2d52t78d7nGX+9zpXne73x3vedf73vned7//HfCBF/zgCV94wx8e8YlX/OIZ33jHPx7y kZf85ClfectfHvOZ1/zmOd95zxce0qEX/ehJX3rTnx71qY/eCFTfete/Hvaxh735cDUC298e97nX /e5533vf/x74wRf+8IlffOMfH/nJV/7ymd9849M+Ark31vSpTwDnXx/72df+9rnffe9/f/nQl34S SgR+858f/elX//rZ/3vx495ERsBN++lff/vfH//2f//tTWR7TBYC+YYg/86PCAYQ+wTQABOw/vn2 b/cAYASKwCD8zwEfcAIRUPcsMP0wkAI3cPsQUAMp8AMlMPs+0AiGLwQVEAVNsHxqD/c6gARwT/4C QAQ58ARP8PsKUAInsPs8UAdhsAdzzwYD8Ac5kPiCMAWPkPcY0AWJEAJlkAYrEAp5MAejkAodEAdB cAgbsACL4AkF0Aun8Pa4EAtzcAx9cAqpEAw30ArFsAzZkAifEAuhMA2/sA2tEAnxb/+W8ALDwgnV cA1n0Av/MAzlUAr9cAZ9bw0D0RAHUREXERAFMQQLsRHhkAul0BKHsAQvUQQbMRA5MRGz8A7V7/06 YAAY8Qgi8Axx8AgckRLl0A/dEBYfkRUt/vASJRESs9AWmTATdbAWtxATf1AMNVETU/ENQ5H+RrED bk8ZTBEVQZAMi3ESW1EWjRAI93AWedEVK5EQXREIs1EQoREbNxEYf7Ebc9ETdbEbjfH+RnEE+tAU i8wM0dEMMXAYh1H4yDEaaZEbF/EcrVEaD/EQ7REgAbIe/9AeNZAa1fEGVzD6cM9g4m9U4pEetXEO VdEbzxD48BENJ5IH9bEQndEU4RAkd3EQH9Eie5AkX9EWPzIOi1EhRZEhx08JmvElazIBE9Im75AB RwAiYzAnfzL/cBIoUXAnvepfjtIdh1Ipl5IpF7J6WPD22kYqAbApq9Iqr1L5dpL5GhIr/rvSK5sS +mRPLMeSLMvSLF2vcc5SLddSLKGv+t4SLuNSLueSLuvSLu8yAu5SL/eSL/vSL/8SMANTMKdvGgbT MOPSLT9PMXsHV8KBLR8TMiNTMieTMiuz9BLTMjNTMzeTMzvTM20HMz9TNEeTNEvTNEMvNE9TNVeT NVsTMlPTNWNTNmeTNlGTIR1z9PqgLHWzNnsTINSSN30zMmFTV9rmN4Pz9IyzOI8zOXOlD5AT9pQz 9Z5zLKWzmaCT9IITO7FTONWSOJ1TergzN22JN8XzOsFzN8XSPFVvPZdzOt3TdtqzO9vyNo8hPOPz NwGiEEwPOg3mOPczO8FTNyECVwa0/kBLrz8BtDwLVEGZk0D1szwBFEGLU0IfdEAlVPS0k0EN1D/n 8yy/c0P3kzoXNDstVEDzkz/zkzoP1EBRNEM79ERZVEA5FD2Z8z0PVEZlVD7D0zgXdEVd1EPp8ynz 0j6jBzlHFEYzFD91FPVW9Dn9c0SBFNIStEFb1EavtEd39D5xFEv/szlnlEB/VEuD9DLr05OO9EpT FD6jtDlpdDnZdDzXNEd9NEalVD+/FEXFNE/H1EV/NEftlExdD0SBFE75FE2ZtEnr1Er5lFBrlES7 9FE1VE3zlFIlNU7/tFADdSwHFU0vlFGVE0oZFE891VEn1TkftE8bFEcVlFUZlUsh/vRUORRDlRQ9 TTRJNXX2zBRXd7U3XZVX+YlTrZM9hbX1pPIxjXUzkdUsp/JMf1VIqacxi9RZp5Vaq3VQqxVbs7U7 r1Vbu9VbW5Nbv1Vcx/Uzw5VczxVdJ9Nc05Vd27UsE/Mw41Ve55Ve69Ve7/Ut8xJf91VeE3Mx/9Vz otVdB5ZgvVNXCxZhE1ZQD1ZhYxM3G5Y01/VclZWfphJVy/JhyfNWIfZDGZZgC+EtZzU87clVW9WT MtZIoQDARJZjN9Vj3bWc5HI9W2UELiA7Ce1PuBNli3NlfUomRJNYeTVcfbVZzzIto7MuzbMdCGJj ydMg+gJkdVZaebbIfEo6frY6/pPTMqz1ZSm0Yi+WPNXSWGIvZudSaY3AWAghQ7HKILA2enaWQRPk KEvkSMF2QhHUYm81aAOUaBd2SOH2VL+WZY1UbI/W9cpWZq8TbeNvR6EWXspJas8UaueWbuPTbgMU b/P2Yvd2PPu29a7VHCq2RsPWaKfh9RB3CNK2MI1FPMeh+mQh9BxXFp72ZKe2QAlNOh6ycl+VPfmz YEb3dC2TU13MOkkUVcOUd01vLo/BcJv0dYmg+lo3dVOXcadUtR63dsMTKb1KJqziUWMVfG00TC/3 TFXKEYAXVik1faPUQit0cP0WWolUejqgBHCEQkXWT/2UR8nXD3oSbJrXdqrv/kzfknqpT3qnYXrV 9jqvd3axE26fltBMhG7ddn2B90lf9XsV90wyI1ZnVU991E0r1WD/1nYjgH7tt1QhNH/lk38FNntt iTBLGHHjL3rJM4GhVxGm1EdeOD6LLEGsxIe3U4U9VU9TWIdZjCLQt0OdVFH3dHw7loTLN+CKt4k1 lIWbaS4bM2ywGGyMlPqot4ApuIeLgCCY9oinGHalB27NK6y+DHLv81C71Igr9v8CLo0bdVVVtIrR 907JEnTP9zwxtU+T1/SSoMS2GFjJ8y4PGIwRGJA1ODzECoZLGKCKzCpsYxoG94ObeI4h2cW2lncj tVTplEst9VmZx4UlV3Aj/tRkPRfSxpaSETRpIfl5H9mG4UWsIld7AYx7Q7eDw1eFU7WIzzhfIkKJ j/d+S1lU1/d94ReV5TeQW5MgkJYuzxZ6IbI91YLQ7jiAY9mnoPZgXPl0zVecR1NiXTOWk9Ns6ZiM QRmSv5mbdQVw49YqvFctkvV3NfWcvxVkozebF2JKNVeXr3OJc1gzBbppt7VrB5ZiCVqgMTadr7N+ W9aPF5qiR3OeL5oy91k0AdgzPVqjO/oxOTqkS1pc4ZVfU1qlV5qlW9qlX3ow/RVyvo0M+q2MbBpg DyGVKxOme9qnfxqo/TKizZKkxVImEBqpk1qpl5qpm9qpnxqqo1qqpxqh/hFZMota9mQip5dnPIf6 XS36MbX6muFyq4WGpn/Wq+U5V6M4M8X6hiHQf8v6Faz6ZPsgrXNFjFEPq2PPrR1Z/vxarmOBrtXY rksvHFz5nONY9fq6/yhw4AIbFgb7bQtb9Ajzq1TvO1lWsVOvr6uRD6nMDNrM8yQ7gCmbn1T3yy77 lyEts4UYPhd7HEZAD6fwetfCvRAGp+EpnHUN50hbnk17klP7ajOYtT12UdtXRFXUfUn1twVwCT2y tosm3EQbctBt5Hxui5m1MYFbjb/MWIabj8mXOFuUlINZhPk4L2dhtn2wyNYjwSYEvsftvdriXu7F vev4k1dMyuibeDnn/gEQIOJcB5GtE61Pm9AgYneTl7hpunN2WlXLW0yhNEIJGwBI8R0/e+Lkm7+t m7/by77xJVuWC21Mircv6AEawARO4AQWYAFO4CmlFWwLfJJV+43dE3kJGTaNFcLV13IDt7kxQRlL MQeju9xWTLppxrGSvJgZgULeO75Bm1rk+xUMAAFQfMVZHMtZ3MWhdWqhU8ZPVrX7+LWHWVdy/E33 WJlHFzm1OhmTEguJvMqk3GaUnM6XPMM3uNwa7M4fKw0eQAFUPMsDPcsTQMUL3dAP/dARYAHGwrfx mrsDOMy5c8ejx8xrFblXmLntVqwf8CFj8Mg1/LFAPdQhK86Jw7rn/hvPYQkNHqDQBd3VCR3RY13F FcAEGsABFl0hGn27G917X9RkpWevYc+teXImbXtMBO7UN0TU1Ys9Bo5h9FxRmh2Jc1sUqhzQXX3L xwDXaUHX05vX8/r1hpZzOVsdjJJycxtmSryIqP3ZqjzFE0DLy2DbBXuov3yAy7nMwZot+xqha7pm rpuIRI5gqDzAmWDeI7veHz1l8T2S2Noy+1qKGBzeDn6uF7nbv9rheZrdOQXyKF4clPriKzrjKROk Tbo7F6Az7/qUuRqahReyncDjA3ajbzOoa97mbx6mFwDnXRr6Xr6AYt7ng54MgF7oiz4KiN7ok14J kF7pm74ImN7p/p0e6qNe6aee6o3e6q9e6LNe632e67sesr8e7OVa7Md+q8ve7AEW7dP+4Bqgidae 7T8P7vmOyhvA7u8e7/Ne7/ee7/ve7/8e8ANf8Aef8Avf8A8f8RNf8Ref8fcewNkIAVJcxWu98Svf 8i8f8wEfAAR/8zPf8z8f9AX/3RPABBBAjBBAxRug4OPejwygAVTc9LWI1U+Af1jf5lCf9q2oARIg 9m3f51C/94vo9Vff9w/OABLA7YsoxYm/+A/OARQg+YEI9Zv/6Y4/+CmI1Wuf+pPOAHI/g07g+ref 6Ka/gshf/JnOAcC/gtT//J/O/P3n/ds/6bzff2pd/qcOxQvo/gSY//4ljtUJCAgMJwCxaDwik8ol s+l8QqPSKbVqvWKz2q0zYeCCkwhTuGw+o9PqNbvtPCHc2EZDbr/j8/p93lTnP9EBDhIWGh7a+SEm mZAtPkJGSkI2OEoKTmZqbnKeVWZidoqODjoknKJaIiQMEa22khZ9TobmFQTg4g6cZThFBBAVECgJ PwVESDnsHg04xGYZLEhPSxdJO1Y/y1pG1uIVVESIVwQsgxEU+AIDOBMP+04VHx1rX0UnGEn/OUg7 nCzA0jbr0h898ogIWMeOwDskyDI0JDKAgDlyyI5EINALwC8i7YgwbCfPwUeHHo1cBABxmYMAFUr+ 6pWSI5GH/hEBTDRXxESCOAB4/uF5yuNQdqlcsULKDQG1j/+u7ZzW6p4REwssWZ22hAxUIjyZLjAq bRW+PAO7FbR1cx25W+Uw4nLrMS4uAARyHWmLy0FHAMUG5Hpb7G7Jecjk9aUrwG9cI7kIHFiME9gv twHa0VXoCiARrQCa/hwLoMGCBNk8//MJINrVp0RMn8gax2qCrENYG8gN9os1fUqe2n4t9TPArGHN cqOU9tvaCC2XJYS7McCwA+mIBOiF7khLkQL6FssOEpgwcoUN+33XsW+ECsFuAqAHmEiFAxypEzlg /4D7YBt7AwBWWGBZxRVUY4k2TRzZyNJONggEdRU7jjCF/g9r1EhohGtJ8HMccc7AtllZYOlxlnJ8 HIRdRprRU0Rf6cVnjgDpbGfEXXC992IRbumUBD2IrYNLBeakqCJ2u7z14nxxFXDLdUWk9k9qVjXQ 4WemhVUNaSYwJWWXRwhBjSxYZojAU6Wtds1TvBVxYVlHFBgVGab5FGdnHt5h4iPe3JFiS3Y9Gd9M L4aX0nY1FoFoTesIo2MwARygmY+HqacQOXXBiB4A/M13n4vAuMQQQz122Q9Ap121QAP/WNWKNP90 mJoRYMGBamsSZtUImlSNxuCdsiFhZ2hzLsCbsL7aoecifNqRYnSdeoqSQuE1BA6gzCjUHnjDXFaE feFJ/qbEj+90yhJ+RQoqkUv23ddOBqA21AwSw4kZWj8C+iTmmUfISlyax8X54K5oEvHPm1kFiGzC b9IJgGm8kZgwnskmt+dyfYYzTosBFBABYIFGC+NdGUSQEDJ3zRTfAR67tC1jA0RwC4y/XHQePeQM ABhl1LG8SwEHFIYfdm/dVw5g2vF8V48APBXHU/t45lmvnNGaJj5ShhlWhwgQSFwDYFlI8J1xdNiO lFb/agDCDhfbW2xS51nxshc3G1gB5jjgVn/S7vjOXbrM1W0ReQsZrTyXFuCMPNEpaiRjBbw7Hi7k YloEOeyS86nODf0t9BERR3ynq5z1lu8CcVDVYWkN/p+JsIAI87pZlhmOzasp0zDcNlGmTiyHsogw W0+fSLQIBn+fSmLAeaslweYZznOYT+9u/H5I8MK74TFK0YFRsuAhY7/H1mEGRDEodIefxwB3h5G3 TnmnD4hx/ZQoN/Dox5+//oTktnwbdVTPENfbHwELaEAkBLAQAzwgAxuYvgQSYoEOnCAFRQHBQUiw ghrc4J7sZz38cTCEIoygBwUIwhGiMIW+K6ECTwgFdFWhcZkqg6O4EClJmaGGhfAbyM6RDh2CDwv/ ScMFAZFBJ/iPCjKEoRaAiIVfyEsNTuRDX2TIhRqlDHlasGIZisiHIzbhI87QiBIcMCojTCQjT5rI /gwH8B+IzGQlRpAjjjIwRJWQEY13XEhD3pWyQRUhJ4NDSU3sMihg2JEZGzFjQ1KSkZMQgY4eYYgR SAKfSNLjUHeEo4twQoAsSoQiILlOSgQZMlBOZIhj/I9FisDJQn5yDiyMoAufMJjMIEFnt+iPXjg2 NLcMo3M5o0t/FPPLAIRrUYFxRks4hilhGqGXMHuMY6ADjGbKJVOJ4VigfrFMu+RiANKMz6Le8RZj gpNHRStAMpV5jL9lU5cuGVo4iedMYGxnm3LpSEv2tqN7jhGXnZuMM4vJTVmebwu3ZGbxsEM5dgjO l5GDaDAVQrT48GUd7YnWRqX1Dv0AYEZFyCQO/p+DkJ0hoT7Y6YV1RtoLIGGnnff5qH1uBFFrxgdp 6fgTe64puPlAcQlV7FZLkHHRbkEqPyCbaIzyiUiLTrOfSGCqAGpK1Exe56jOQKYWvLgHMDJhME9q qIvQgU+FiJSdIw0mKbnZJPwIyRxxdYhCoBWBDLRShjZVUQ3n86cYFSGtlXIc39R1LXA65q7kiU5V hzak8TTpreLAYWERdYzKRBauF2mcWm30w8XCpXJGcNJb8TnWk302srfgFiin4NUS1dIJYh1pyhAX qcNe6yCznamoYgmAS1kKL4X1lC7z2kNFXZay5eBe8bYD03ThaFGHRa5RMXqMiwIXnL0dxhSr/nja X2zXqJsFWZGcOsNFRWppTdoubrHKW1GJt6uzxGBsm7Bb6M6lHfOBVktV6tD2llIicxmGuSLyohuJ x0gytCtKkVDVBHvOWvLoFFlDdqMaMTimwOBPXQcMLZwEMbqWja+Aods4/6oEIp/9LbtS3BGmWu5J ygDwYYu3jApT4bVmqW9Y2UrbSvLsXUFa2V0++8lI+fhRMLsteHvWZMDoxJvD5NbKdIZaH3XsYyGG qEJG5j1k4ExnhP2U0fBj2Sz7MqRJ/Vs5exafMjeYJnDZxYhfFoHbmhhkTX7XRFa853KAR8+QYpl7 6owyO+MZx66drxF5vIT7klWYbyEcO6+j/rMZJZk+9QTn5CTnuUVtTl264KoVCTfPLavMRpt+3EQr DMVO49bUe2sJdxPMaaE54IZAC1mFcaHiH/920y1aMDXNS1D8vMjWoj51nZvpDODeuLVS0DEewKrC K1w0fL69thWonSdHc1sKA8Bz/GQa7ih4O1ngPvcT1pdEdlcw3b5bN7zrbe+dMPqL9L43v8+tiEmM od8CH3gSFLBvOZiJ4Aon+AkekAl/LDzi/D7Buw1xAuhJPOMpTLgm/q3xj6PQ2nvgOMhLzsGGcwIO Jl85BUmuCZezPOYEVHknTnBwmeMcEghQwCgegPKcA70ePsf4y8sX9KNvQgiqGcWqiI70kacjwh9L J0XToW71RTxAVdhjytSv7nU8OGBVXX+GEGj+9bO7wUwKcLo2zGRzh6M97mV4AE/Mvj+6nyDvjaAD 3/vud0H8PfCCHzzhCT+awiM+8YpfPOMb7/jHQz7ykp984htxAlaYAO4NdMADIET5z4M+9KIfPelL b/rTQx4BFZc761vv+tfDPvaynz3ta6+FIAAAOw== ------=_NextPart_52C_1EB1_E1C809D2.333612FD-- From sip-bounces@ietf.org Wed Jan 17 09:13:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7BWh-0002v0-P0; Wed, 17 Jan 2007 09:12:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7BWg-0002uq-2f for sip@ietf.org; Wed, 17 Jan 2007 09:12:30 -0500 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7BWe-0007rX-Jz for sip@ietf.org; Wed, 17 Jan 2007 09:12:30 -0500 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id B4E81210090; Wed, 17 Jan 2007 15:12:25 +0100 (CET) Message-ID: <45AE2ED7.9070002@pernau.at> Date: Wed, 17 Jan 2007 15:12:39 +0100 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] Re: TCP connection establishment References: <45A689D2.4010402@cisco.com> <000101c738d5$c0ca9580$f32915ac@NOE.Nokia.com> <7.0.1.0.0.20070116141404.01fdb658@iptel.org> <45ACF6EB.7030903@cisco.com> In-Reply-To: <45ACF6EB.7030903@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: sip@ietf.org, "Isomaki Markus \(Nokia-SIR/Espoo\)" , "Niemi Aki \(Nokia-NRC/Helsinki\)" , christer.holmberg@ericsson.com, Kai Vehmanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > comment at end. > > Jiri Kuthan wrote: >> At 19:48 15/01/2007, Kai Vehmanen wrote: >>> Hello, >>> >>> On 11 Jan 2007, Paul Kyzivat wrote: >>>> If the server cannot establish a connection to the client, but the >>>> client can establish a TLS connection with mutual authentication, >>>> then that could qualify the client as *needing* a connection. I'm >>>> talking about other cases. In particular, if we are talking about >>>> TCP rather than TLS, then the client establishing a TCP connection >>>> doesn't establish a reverse path, unless outbound is used. >>> well, it's worth noting that in many real-life deployments the >>> TCP registration does establish a reverse path (even though >>> no IETF documents specify this yet -- waiting for sip-outbound). >>> Just look at iptel.org SER for example ("tcp_alias" settings, other >>> implementations use "persistent TCP", etc, etc). >>> >>> These ain't pretty, that's for sure, but allow to use TCP as the >>> transport with some of the already existing clients. >>> >>>> You can register with a server in order to receive outbound calls >>>> without maintaining a connection, as long as the server can >>>> establish a connection when it is needed. >>> But how can a client possibly know which is the case? With >>> NATs on path, this is still doable, but with stateful firewalls, neither >>> the client nor the server can possibly know whether TCP connections >>> can be established towards the client. Deciding-by-trial is way too >>> slow as the FWs can drop packets silently, and the default timeouts >>> are long. So except in cases where the access network characteristics >>> are known, client will have to assume that _it_, the client, >>> >>> is the party responsible for initiating connections. >> >> Absolutely. In addition to the client-server-oriented NAT/firewall >> friendliness, >> one can argue even more generally using e2e principiles or Murphy laws: >> network can always fail somehow and the more robust approach for the >> client is >> just to rely on itself. > > What point are you making? Vijay responded as I would have - the single > TCP connection has major security concerns if used bidirectionally. You As Aki said there is no problem in User Agent - Proxy scenario: Challenge the client, do not trust the Location and Via header (especially alias parameter) but only the trust the source socket. Use the source socket of the REGISTER as contact and you will be fine - no security issues. That's how it is done currently. > should only use TCP if you know you don't have NAT/FW issues, so that a > separate TCP connection can be made in the other direction. There are firewalls which block all UDP traffic - thus you ahve to use TCP/TLS. regards klaus > Otherwise, if you have your own cert you can use TLS and avoid the need > for connection establishment in the reverse direction, or else you can > use outbound. > > Practically speaking, a UA will typically not have a cert, and will need > to use outbound. Connection reuse, via TCP or TLS, will typically only > be useful between proxies. > > Paul > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Klaus Darilion nic.at _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 17 09:13:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7BVw-0002Ol-OY; Wed, 17 Jan 2007 09:11:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7BVu-0002Oa-H4 for sip@ietf.org; Wed, 17 Jan 2007 09:11:42 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7BVs-0007gk-5a for sip@ietf.org; Wed, 17 Jan 2007 09:11:42 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 17 Jan 2007 06:11:40 -0800 X-IronPort-AV: i="4.13,199,1167638400"; d="scan'208"; a="50986573:sNHT49956736" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0HEBeSU000489; Wed, 17 Jan 2007 09:11:40 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0HEBdVT025832; Wed, 17 Jan 2007 09:11:39 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 09:11:39 -0500 Received: from [161.44.182.244] ([161.44.182.244]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 09:11:39 -0500 Message-ID: <45AE2E9A.7030206@cisco.com> Date: Wed, 17 Jan 2007 09:11:38 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Dan Wing Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll:Proposal relating to keepalive, TCP,and UDP usage indraft-ietf-sip-outbound] References: <056c01c73a07$7d039f80$c4f0200a@amer.cisco.com> In-Reply-To: <056c01c73a07$7d039f80$c4f0200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jan 2007 14:11:39.0292 (UTC) FILETIME=[67D92DC0:01C73A41] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2775; t=1169043100; x=1169907100; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20TCP=20connection=20establishment=20[was=3A=20RE=3A=20 [Sip]=20Question=20aboutPoll=3AProposal=0A=20relating=20to=20keepalive, =20 TCP,and=20UDP=20usage=20indraft-ietf-sip-outbound] |Sender:=20 |To:=20Dan=20Wing=20; bh=Qbp3QdmK9eRVd4CH9wnAXFwCKtzzuRS0/EQnzy6qJRk=; b=fLov/ukCUtgjYsMqNLVX/midlyRoCCyGfoPCw/VI6ATjw6PHLhvYKOiktEf1MPa473TPNsvd Oovs9Idn1lCfIr/i1erh9d5qlloZjCC0sYTNwMbAGXqnnBX4WEKJ3RGH; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: 'SIP LIST' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline Dan Wing wrote: > ... >>> Hmm -- interesting. An orderly TCP (or TLS) disconnection can >>> easily signify this intent. >>> >>> An unorderly, or abrupt TCP (or TLS) disconnection that did not >>> result in the TCP (or TLS) shutdown handshake could conceivably >>> mean that the server or some middlebox somewhere crashed, and >>> the client may re-establish the connection with an alternate >>> server (if any), or wait a bit before retrying. >>> >>> There are programmatical techniques that let an implementation >>> figure out whether or not a socket was closed in an orderly >>> fashion or abruptly. >> Sounds good to me. Then there still has to be an >> understanding of what sort of circumstance justifies the >> establishment of a new connection. An obvious one is that >> you shouldn't reconnect until you need to send a SIP >> request. > > That doesn't seem like a good optimization -- how would > you get an incoming call? Dan - everybody is getting this mixed up with outbound. Outbound has its own rules. This discussion came about relative to the connection reuse draft which is independent of outbound. Connection reuse has different rules for TCP and TLS. In the case of TCP, there is no way to verify the identity of the source of a connection, so it isn't used for requests in the reverse direction. Instead, a separate connection in the other direction is required for those. That of course means the technique can only be used when it is possible to establish connections in both directions. If that isn't possible, then TCP connection reuse isn't a sufficient answer, and either TLS or outbound is required. Paul >> For instance and INVITE, or a REGISTER. This can still be >> abused by somebody who "needs" to send an OPTIONS message. So I think >> the notion of "need" needs to be sharpened. > > If the UA has already registered, and then the TCP connection > is broken, it's going to need to re-register right away > anyway, especially if its host stack or its NAT gave it a > different ephemeral port than it had with its last > registration. > > And even if it doesn't need to re-register, it needs to get > a connection back up for incoming calls. > > -d > >> I think this is >> one of those >> things where it could be hard to define formally, but easy to >> distinguish real need from whim when you see it. >> >> Paul >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 17 09:20:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Be7-0007D5-TQ; Wed, 17 Jan 2007 09:20:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Be6-0007D0-GB for sip@ietf.org; Wed, 17 Jan 2007 09:20:10 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Be5-00019Q-4L for sip@ietf.org; Wed, 17 Jan 2007 09:20:10 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 17 Jan 2007 06:20:08 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l0HEK8kR010710; Wed, 17 Jan 2007 06:20:08 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0HEK5nF005118; Wed, 17 Jan 2007 06:20:05 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 09:20:05 -0500 Received: from [161.44.182.244] ([161.44.182.244]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 09:20:04 -0500 Message-ID: <45AE3094.4070903@cisco.com> Date: Wed, 17 Jan 2007 09:20:04 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Sip] RE: TCP connection establishment References: <000101c738d5$c0ca9580$f32915ac@NOE.Nokia.com> <45ABFA1F.8060809@lucent.com> <1169020776.5210.8.camel@macbuster.research.nokia.com> In-Reply-To: <1169020776.5210.8.camel@macbuster.research.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jan 2007 14:20:04.0835 (UTC) FILETIME=[952CEB30:01C73A42] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2078; t=1169043608; x=1169907608; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20RE=3A=20TCP=20connection=20establishment |Sender:=20; bh=GbRpDO4xTdcyJZ9pUBj7Oy40YJ9GLCkSO7UiYCrYwYg=; b=PFrSYAbDPqH9WPv0pZ4r6agt+Uyynt7+SykmWMlLPZ5kPUVlokzFJeqmpRzluWnRhp7WusBZ SwLUWxiIRyZLHZhmcxnQ6I8GxnuaO+dkcxnRPlNV9kRImLIeubILnP+6; Authentication-Results: sj-dkim-8; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip@ietf.org, Kai Vehmanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline Aki Niemi wrote: > On Mon, 2007-01-15 at 16:03 -0600, ext Vijay K. Gurbani wrote: >> Kai Vehmanen wrote: >>> well, it's worth noting that in many real-life deployments the >>> TCP registration does establish a reverse path (even though >>> no IETF documents specify this yet -- waiting for sip-outbound). >>> Just look at iptel.org SER for example ("tcp_alias" settings, >>> other implementations use "persistent TCP", etc, etc). >> This leaves you open to the sort of attack described in >> S9.3 of connect-reuse >> (http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-07.txt). > > Hold on; let's clearly distinguish between the UA-to-proxy connection > and connections between proxies. The latter clearly has this problem > with authentication, since mere connection establishment and sending > messages in no way means authority to receiving messages over that > connection. > > The former case is different, since typically the first thing a UA sends > over the connection is a REGISTER, which gets challenged and > authenticated before the connection is "trusted". > > So where is the problem? If the connection is direct from UA to registrar, then perhaps the registration is sufficient to authenticate the connection for reverse traffic. If the connection is from UA to proxy then the proxy has to make leaps of faith to trust the identity of the connection. I don't recall all the details at the moment, but I know Rohan attempted to incorporate this kind of feature into connection reuse a long time ago. It was shot down. People went to a lot of trouble to develop outbound for this case. AFAIK the current version of connection reuse is primarily of interest for proxy-proxy connections. People keep wanting to apply it to UAs, apparently as a poor-man's-outbound. There may be a *few* cases where that can work. But attempting to do so is likely to just get people confused. I think we would be better off clearly partitioning the applicability of these two things. Thanks, Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 17 10:13:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7CSt-0001LS-Qs; Wed, 17 Jan 2007 10:12:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7CSr-0001LB-FU for sip@ietf.org; Wed, 17 Jan 2007 10:12:37 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7CSq-0002WJ-0N for sip@ietf.org; Wed, 17 Jan 2007 10:12:37 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 17 Jan 2007 10:12:36 -0500 X-IronPort-AV: i="4.13,199,1167627600"; d="scan'208"; a="111870071:sNHT735012540" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0HFCZGY026289 for ; Wed, 17 Jan 2007 10:12:35 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0HFCZOA024361 for ; Wed, 17 Jan 2007 10:12:35 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 10:12:35 -0500 Received: from [161.44.182.244] ([161.44.182.244]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 10:12:35 -0500 Message-ID: <45AE3CE2.3080804@cisco.com> Date: Wed, 17 Jan 2007 10:12:34 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll:Proposal relating to keepalive, TCP,and UDP usage indraft-ietf-sip-outbound] References: <056c01c73a07$7d039f80$c4f0200a@amer.cisco.com> <45AE2E9A.7030206@cisco.com> In-Reply-To: <45AE2E9A.7030206@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jan 2007 15:12:35.0081 (UTC) FILETIME=[EADE4F90:01C73A49] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4591; t=1169046755; x=1169910755; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20TCP=20connection=20establishment=20[was=3A=20RE=3A=20 [Sip]=20Question=09aboutPoll=3AProposal=0A=20relating=20to=20keepalive, =20 TCP,and=20UDP=20usage=20indraft-ietf-sip-outbound] |Sender:=20 |To:=20Paul=20Kyzivat=20; bh=5FX/SSayV7HAokYY10jZaLx9YUgs0608clCk+8vsySw=; b=Y6VHFNfCsauR0SGhMM9yytpZUsRej63fKLotZUxqZDyMBv5Bvhxi6480VcjFtckHhXvSg7nZ 9TwWbud9izemJnyFP1FGR9YumjHKqPQ5ZRosVrfhQtqZLqJrzGGRZulr; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: 'SIP LIST' , Dan Wing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A further thought... I think outbound is in some sense an enhancement to connection reuse, with different criteria for when connections should be established as well as different criteria for reuse. But while the criteria for establishing connections are different, this discussion has identified a need for a policy to deal with overload in outbound too - when there are more candidates wanting to connect than can be accommodated. It is a more serious issue in that case, since when somebody is prevented from connecting they also won't be able to receive calls. A server that uses outbound should probably just refuse connections when it has maxed out the number it can support. The UAs that attempt to connect will just be out of luck, but then in this case *somebody* has to be out of luck. A server that uses connection reuse without outbound should probably attempt to keep some headroom for new connections, by disconnecting some connections that haven't been used in a long time. That will allow those that need a connection to make one, as long as everybody plays nice and doesn't establish connections they don't need. A server that supports both outbound and connection reuse, and has a mixture of peers using one or the other may have some difficulty providing equitable service to both types. I'm not sure I want to think about that right now. Paul Paul Kyzivat wrote: > inline > > Dan Wing wrote: >> ... >>>> Hmm -- interesting. An orderly TCP (or TLS) disconnection can >>>> easily signify this intent. >>>> >>>> An unorderly, or abrupt TCP (or TLS) disconnection that did not >>>> result in the TCP (or TLS) shutdown handshake could conceivably >>>> mean that the server or some middlebox somewhere crashed, and >>>> the client may re-establish the connection with an alternate >>>> server (if any), or wait a bit before retrying. >>>> >>>> There are programmatical techniques that let an implementation >>>> figure out whether or not a socket was closed in an orderly >>>> fashion or abruptly. >>> Sounds good to me. Then there still has to be an understanding of >>> what sort of circumstance justifies the establishment of a new >>> connection. An obvious one is that you shouldn't reconnect until you >>> need to send a SIP request. >> >> That doesn't seem like a good optimization -- how would >> you get an incoming call? > > Dan - everybody is getting this mixed up with outbound. Outbound has its > own rules. This discussion came about relative to the connection reuse > draft which is independent of outbound. Connection reuse has different > rules for TCP and TLS. In the case of TCP, there is no way to verify the > identity of the source of a connection, so it isn't used for requests in > the reverse direction. Instead, a separate connection in the other > direction is required for those. That of course means the technique can > only be used when it is possible to establish connections in both > directions. If that isn't possible, then TCP connection reuse isn't a > sufficient answer, and either TLS or outbound is required. > > Paul > >>> For instance and INVITE, or a REGISTER. This can still be abused by >>> somebody who "needs" to send an OPTIONS message. So I think the >>> notion of "need" needs to be sharpened. >> >> If the UA has already registered, and then the TCP connection >> is broken, it's going to need to re-register right away anyway, >> especially if its host stack or its NAT gave it a >> different ephemeral port than it had with its last registration. >> And even if it doesn't need to re-register, it needs to get a >> connection back up for incoming calls. >> >> -d >> >>> I think this is one of those things where it could be hard to define >>> formally, but easy to distinguish real need from whim when you see it. >>> >>> Paul >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 17 11:40:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7DpX-0008JD-VE; Wed, 17 Jan 2007 11:40:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7DpW-0008J8-OI for sip@ietf.org; Wed, 17 Jan 2007 11:40:06 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7DpV-0003Pb-DP for sip@ietf.org; Wed, 17 Jan 2007 11:40:06 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 17 Jan 2007 08:40:05 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l0HGe4ZJ029614; Wed, 17 Jan 2007 08:40:04 -0800 Received: from dwingwxp ([10.32.240.196]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0HGe3ho025252; Wed, 17 Jan 2007 08:40:03 -0800 (PST) From: "Dan Wing" To: "'Paul Kyzivat'" Subject: RE: TCP connection establishment [was: RE: [Sip] Question aboutPoll:Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] Date: Wed, 17 Jan 2007 08:40:03 -0800 Keywords: direct-to-dwing Message-ID: <062501c73a56$23d57a60$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <45AE2E9A.7030206@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acc6QWhFHSJ+GR6eQUyqWt8CKjKaPQAFKbLg DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2071; t=1169052004; x=1169916004; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20TCP=20connection=20establishment=20[was=3A=20RE=3A=20 [Sip]=20Question=20aboutPoll=3AProposal=20relating=20to=20keepalive, =20TCP ,and=20UDP=20usage=20indraft-ietf-sip-outbound] |Sender:=20; bh=LcdSHoL3KsI6WvZgSios5VvwKz9QDnsb0vktFM+aWDY=; b=ax2JVIKVCbfEq41eG9BACCICF16p14QYyixj0wPK4xt1/0dCXAZwN389e85x3i9BkBK50V9v aCsUH3Eo/E3RuBHf0O3klCoSTqy6MA+3Rdl1yCLZCLYaItT1xABUuM3S; Authentication-Results: sj-dkim-6; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: 'SIP LIST' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > That doesn't seem like a good optimization -- how would > > you get an incoming call? > > Dan - everybody is getting this mixed up with outbound. Not surprising given the subject. My bad. Sorry. -d > Outbound has its > own rules. This discussion came about relative to the > connection reuse > draft which is independent of outbound. Connection reuse has > different > rules for TCP and TLS. In the case of TCP, there is no way to > verify the > identity of the source of a connection, so it isn't used for > requests in > the reverse direction. Instead, a separate connection in the other > direction is required for those. That of course means the > technique can > only be used when it is possible to establish connections in both > directions. If that isn't possible, then TCP connection reuse isn't a > sufficient answer, and either TLS or outbound is required. > > Paul > > >> For instance and INVITE, or a REGISTER. This can still be > >> abused by somebody who "needs" to send an OPTIONS message. > So I think > >> the notion of "need" needs to be sharpened. > > > > If the UA has already registered, and then the TCP connection > > is broken, it's going to need to re-register right away > > anyway, especially if its host stack or its NAT gave it a > > different ephemeral port than it had with its last > > registration. > > > > And even if it doesn't need to re-register, it needs to get > > a connection back up for incoming calls. > > > > -d > > > >> I think this is > >> one of those > >> things where it could be hard to define formally, but easy to > >> distinguish real need from whim when you see it. > >> > >> Paul > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 17 15:52:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7HkE-0005Mc-4U; Wed, 17 Jan 2007 15:50:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Hjt-00051C-Mv; Wed, 17 Jan 2007 15:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H7Hjs-0004rQ-VN; Wed, 17 Jan 2007 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id A75A9176B6; Wed, 17 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H7HjO-0004HI-8S; Wed, 17 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 17 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-connected-identity-04.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Connected Identity in the Session Initiation Protocol (SIP) Author(s) : J. Elwell Filename : draft-ietf-sip-connected-identity-04.txt Pages : 24 Date : 2007-1-17 Because of retargeting of a Session Initiation Protocol (SIP) dialog- forming request (changing the value of the Request-URI), the User Agent Server (UAS) can have a different identity from that in the To header field. This document provides a means for that User Agent (UA) to supply its identity to the peer UA by means of a request in the reverse direction and for that identity to be signed by an Authentication Service. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in the Public Switched Telephone Network (PSTN) behind a gateway. This document normatively updates RFC 3261 (SIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-identity-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-connected-identity-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-connected-identity-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-17143153.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-connected-identity-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-connected-identity-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-17143153.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From rgranja@sbc.net Wed Jan 17 19:44:53 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7LOf-0003fz-UB for sip-archive@lists.ietf.org; Wed, 17 Jan 2007 19:44:53 -0500 Received: from [203.213.192.82] (helo=82-192-213.203.adsl-pool.digitelone.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7LOd-0008Qz-AR for sip-archive@lists.ietf.org; Wed, 17 Jan 2007 19:44:53 -0500 Received: from 66.88.101.67 (HELO mail.sbc.net) by lists.ietf.org with esmtp (M3+R(:D,K4J W7(3) id 7K>(.I-0HX+R4->@ for sip-archive@lists.ietf.org; Thu, 18 Jan 2007 00:44:59 -0480 Date: Thu, 18 Jan 2007 00:44:59 -0480 From: Otcbb Alert! X-Mailer: The Bat! (v3.81.14 Beta) Business X-Priority: 3 (Normal) Message-ID: <775416911.03188409624156@thebat.net> To: sip-archive@lists.ietf.org Subject: MHII.OB(MARSHALL HOLDINGS INTERNATIONAL INC.) this special for you MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: quoted-printable X-Spam: Not detected X-Spam-Score: 0.9 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 shows all major networks kill at least 89 in BaghdadTwin attacks.and you'll= discover that this man isn't just a smart-ass, but one really smart guy.I'= d love to be involved, but I just find it hard to be motivated to do anothe= r screenplay right nowwhen you find yourself cracking up uncontrollably.I h= ad no These exciting stocks right for your business! It will aid you to feel the edge of market!!! No more doubts like =93and w= hat if I lose my=94 money=85=94 MARSHAL HOLDINGS INC(MHII.OB) APPROVED stock!!! Exactly 300% of your success on markets of shares Look at this chart that we included and don=92t losetime!!! DATE INITIAL COST VOLUME 01/18/2007 0.078 8,394,800 01/17/2007 0.064 5,394,800 01/12/2007 0.034 2,094,800 01/11/2007 0.035 3,091,232 01/10/2007 0.016 511,475 01/09/2007 0.015 481,693 You can get more news using your broker web-site! WARNING: INVEST YOUR MONEY EXACTLY IN OUR COMPANY!!! kill at least 89 in BaghdadTwin attacks.Reality From sip-bounces@ietf.org Wed Jan 17 22:46:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7OD3-0006JY-3A; Wed, 17 Jan 2007 22:45:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7OD1-0006JQ-PP for sip@ietf.org; Wed, 17 Jan 2007 22:45:03 -0500 Received: from oes.aircom.com ([66.194.150.35] helo=ams1.aircom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7OD0-0006hZ-DS for sip@ietf.org; Wed, 17 Jan 2007 22:45:03 -0500 Received: by ams1 with Internet Mail Service (5.5.2650.21) id ; Wed, 17 Jan 2007 22:44:57 -0500 Message-ID: <07BB842D3E28D411804900508BAC02BD06FDA948@ams1> From: Charles Kristofek To: sip@ietf.org Date: Wed, 17 Jan 2007 22:44:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-Spam-Score: 1.4 (+) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Subject: [Sip] proxy redirected? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1171074063==" Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1171074063== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73AB3.05EF0FFE" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C73AB3.05EF0FFE Content-Type: text/plain Hi. Can anyone explain how an RFC3261 compliant proxy determines when a "302 Moved Temporarily" is received by the proxy whether to a. Redirect immediately to the new contact, or b. Pass the 302 backwards, allowing the originating UA to retry. It would seem that a proxy making use of a Redirect Server would always perform choice (a). Subsequently, the "new contact" may also reply with a 302... Thanks, Chuck K. THIS E-MAIL MAY CONTAIN PRIVILEGED, CONFIDENTIAL, COPYRIGHTED, OR OTHER LEGALLY PROTECTED INFORMATION. IF YOU ARE NOT THE INTENDED RECIPIENT (EVEN IF THE E-MAIL ADDRESS ABOVE IS YOURS), YOU MAY NOT USE, COPY OR RETRANSMIT IT. IF YOU HAVE RECEIVED THIS BY MISTAKE, OR WISH TO BE REMOVED FROM A MAILING LIST, PLEASE NOTIFY US BY RETURN E-MAIL AT POSTMASTER@AIRNETCOM.COM, THEN DELETE. THANK YOU. ------_=_NextPart_001_01C73AB3.05EF0FFE Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Hi.

Can anyone explain how an RFC3261 compliant proxy = determines when a 

"302 Moved =
Temporarily" is received by the proxy whether to
a.    =
Redirect immediately to =
the new contact, or
b.    =
Pass the 302 backwards, =
allowing the originating UA to retry.
It would =
seem that a proxy making use of a Redirect =
Server
would =
always perform choice (a).
Subsequently, the "new contact" may also =
reply with a 302...
 
Thanks,
Chuck =
K.

 

=

 



THIS E-MAIL MAY CONTAIN PRIVILEGED, = CONFIDENTIAL, COPYRIGHTED, OR OTHER

LEGALLY PROTECTED INFORMATION. IF YOU = ARE NOT THE INTENDED RECIPIENT

(EVEN IF THE E-MAIL ADDRESS ABOVE IS = YOURS), YOU MAY NOT USE, COPY

OR RETRANSMIT IT. IF YOU HAVE = RECEIVED THIS BY MISTAKE, OR WISH TO BE

REMOVED FROM A MAILING LIST, PLEASE = NOTIFY US BY RETURN E-MAIL AT

POSTMASTER@AIRNETCOM.COM, THEN = DELETE. THANK YOU.

------_=_NextPart_001_01C73AB3.05EF0FFE-- --===============1171074063== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1171074063==-- From sip-bounces@ietf.org Wed Jan 17 23:35:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7OzG-0003ck-GU; Wed, 17 Jan 2007 23:34:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7OzE-0003ZK-Tm for sip@ietf.org; Wed, 17 Jan 2007 23:34:52 -0500 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7OzD-0005Lu-NJ for sip@ietf.org; Wed, 17 Jan 2007 23:34:52 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc11) with ESMTP id <20070118043436b110049snde>; Thu, 18 Jan 2007 04:34:51 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l0I3uLbM006850 for ; Wed, 17 Jan 2007 22:56:21 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0I3uLnw006846; Wed, 17 Jan 2007 22:56:21 -0500 Date: Wed, 17 Jan 2007 22:56:21 -0500 Message-Id: <200701180356.l0I3uLnw006846@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <07BB842D3E28D411804900508BAC02BD06FDA948@ams1> (ckristofek@airnetcom.com) Subject: Re: [Sip] proxy redirected? References: <07BB842D3E28D411804900508BAC02BD06FDA948@ams1> X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Charles Kristofek Can anyone explain how an RFC3261 compliant proxy determines when a "302 Moved Temporarily" is received by the proxy whether to a. Redirect immediately to the new contact, or b. Pass the 302 backwards, allowing the originating UA to retry. It would seem that a proxy making use of a Redirect Server would always perform choice (a). Subsequently, the "new contact" may also reply with a 302... It can choose to do either, "based on local policy". Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 18 03:27:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Sac-0004yZ-QH; Thu, 18 Jan 2007 03:25:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Sac-0004yU-30 for sip@ietf.org; Thu, 18 Jan 2007 03:25:42 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Saa-0000f7-Ky for sip@ietf.org; Thu, 18 Jan 2007 03:25:42 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0I8NnI8027377; Thu, 18 Jan 2007 10:23:57 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 10:25:33 +0200 Received: from esebe106.NOE.Nokia.com ([172.21.143.51]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 10:25:33 +0200 Received: from 172.21.42.183 ([172.21.42.183]) by esebe106.NOE.Nokia.com ([172.21.143.51]) with Microsoft Exchange Server HTTP-DAV ; Thu, 18 Jan 2007 08:25:32 +0000 Received: from macbuster by ESEBE106.noe.nokia.com; 18 Jan 2007 10:26:12 +0200 Subject: Re: [Sip] RE: TCP connection establishment From: Aki Niemi To: ext Paul Kyzivat In-Reply-To: <45AE3094.4070903@cisco.com> References: <000101c738d5$c0ca9580$f32915ac@NOE.Nokia.com> <45ABFA1F.8060809@lucent.com> <1169020776.5210.8.camel@macbuster.research.nokia.com> <45AE3094.4070903@cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Nokia-NRC/Helsinki Date: Thu, 18 Jan 2007 10:26:12 +0200 Message-Id: <1169108772.5732.33.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 X-OriginalArrivalTime: 18 Jan 2007 08:25:33.0135 (UTC) FILETIME=[38AAD5F0:01C73ADA] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070118102357-6AD0DBB0-79BC719B/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip@ietf.org, Kai Vehmanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Wed, 2007-01-17 at 09:20 -0500, ext Paul Kyzivat wrote: > If the connection is direct from UA to registrar, then perhaps the > registration is sufficient to authenticate the connection for reverse > traffic. If the connection is from UA to proxy then the proxy has to > make leaps of faith to trust the identity of the connection. I can't see this being any different with UDP, where the proxy in between can effectively be an open relay, and has to trust the flows it relays. But I also can't see how this problem is any different for, say, HTTP proxies. That's why many HTTP proxies are configured to do proxy-authentication, limit the ports to which clients can CONNECT, etc. Similar logic can be added to a SIP proxy to ascertain that they not become a totally open relay. The rule of thumb in doing this is that you don't commit expensive resources, or allow all possible actions to be taken until the connection, or flow, is considered trusted. > AFAIK the current version of connection reuse is primarily of interest > for proxy-proxy connections. People keep wanting to apply it to UAs, > apparently as a poor-man's-outbound. There may be a *few* cases where > that can work. But attempting to do so is likely to just get people > confused. I think we would be better off clearly partitioning the > applicability of these two things. Yes, I agree. As I said in the past, we in practice have two very different interfaces to a proxy: the client-to-server, and the server-to-server. Outbound is for the former; conn-reuse for the latter. Neither one has a problem with TCP, although the way one determines when to trust a connection is very different for each. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 18 03:49:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Swx-0002An-D6; Thu, 18 Jan 2007 03:48:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Swv-0002Af-Us for sip@ietf.org; Thu, 18 Jan 2007 03:48:45 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Swt-0003cY-Jp for sip@ietf.org; Thu, 18 Jan 2007 03:48:45 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JC20002C356RX@siemenscomms.co.uk> for sip@ietf.org; Thu, 18 Jan 2007 08:48:42 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 18 Jan 2007 08:48:40 +0000 Content-return: allowed Date: Thu, 18 Jan 2007 08:48:39 +0000 From: "Elwell, John" Subject: RE: [Sip] proxy redirected? To: Dale.Worley@comcast.net, sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670ACD99C0@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org However, RFC 3261 places restrictions depending on whether the proxy is responsible for the domain of the existing Request-URI. It can recurse only if it is responsible for that domain - see 16.5. John > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > Sent: 18 January 2007 03:56 > To: sip@ietf.org > Subject: Re: [Sip] proxy redirected? > > From: Charles Kristofek > > Can anyone explain how an RFC3261 compliant proxy > determines when a > > "302 Moved Temporarily" is received by the proxy whether to > a. Redirect immediately to the new contact, or > b. Pass the 302 backwards, allowing the originating UA to retry. > It would seem that a proxy making use of a Redirect Server > would always perform choice (a). > Subsequently, the "new contact" may also reply with a 302... > > It can choose to do either, "based on local policy". > > Dale > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 18 05:36:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Ubr-0000OY-Bp; Thu, 18 Jan 2007 05:35:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Ubp-0000DA-AZ for sip@ietf.org; Thu, 18 Jan 2007 05:35:05 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Ubo-0001Ty-PG for sip@ietf.org; Thu, 18 Jan 2007 05:35:05 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l0IAZ2kp028252 for ; Thu, 18 Jan 2007 04:35:04 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 04:35:03 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 11:35:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Jan 2007 11:34:58 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180B396E1@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Publication request for draft-ietf-sip-connected-identity-04 Thread-Index: Acc67E1WoYsFDU0OTAuu5WyQwmyhmw== From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 18 Jan 2007 10:35:01.0480 (UTC) FILETIME=[4EF63680:01C73AEC] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 1.1 (+) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Subject: [Sip] Publication request for draft-ietf-sip-connected-identity-04 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) Draft-ietf-sip-identity-04 has just been submitted to the archive with one very small punctuation change over the previous version. There were no comments received on the previous version in regard to resolution of the last open issue (where we agreed the intent at IETF#67). I have requested the IESG to publish this document as a proposed standard, which means that at some point in the future it will go through IESG review and IESG last call. The submitted PROTO writeup is as follows: PROTO writeup for http://www.ietf.org/internet-drafts/draft-ietf-sip- connected-identity-04.txt: "Connected Identity in the Session Initiation Protocol (SIP)" (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Keith Drage The document has been reviewed and is ready for forwarding to IESG for=20 publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Document history: * draft-elwell-sip-connected-identity-00 was submitted October 2005 and=20 expired April 2005. * draft-elwell-sip-connected-identity-01 was submitted 19th February=20 2006 and expired 23rd August 2006. * draft-ietf-sip-connected-identity-00 was submitted 26th April 2006 and=20 expired 26th October 2006. * draft-ietf-sip-connected-identity-01 was submitted 8th August 2006 and=20 expires 8th February 2007. * draft-ietf-sip-connected-identity-02 was submitted 6th October 2006=20 and expires 6th April 2007. * draft-ietf-sip-connected-identity-03 was submitted 9th January 2007=20 and expires 9th July 2007. * draft-ietf-sip-connected-identity-04 was submitted 17th January 2007=20 and expires 21st July 1007. WGLC was initiated in the SIP WG on draft-ietf-sip-connected-identity-01 on=20 4th September 2006 with comments requested by 18th September 2006. Review was made and comments were received from: Cullen Jennings, Shida=20 Schubert, Francois Audet, Paul Kyzivat, Sietse van der Gaast (with an=20 indication that all had performed a full review of the draft. During the course of the work comments have also been made by: Denis Alexeitsev, Ilan=20 Avner, Christer Holmberg, Frank Derks, Hans Person, Jonathan Rosenberg,=20 Rocky Wang, Shida Schubert, Roland Jesske, Georg Mayer, Fredrik Thulin, Bob=20 Penfield, Mike Hammer, Jeroen van Bemmel, Jon Peterson, Hisham Khartabil,=20 Martin Dolly, Cullen Jennings, Paul Kyzivat, David Oran, Feng Cao, Henry Sinnreich, Lavis Zhou, Dan Wing, Eric Rescorla. There have been two key issues in the discussion that have been resolved to=20 the satisfaction of the SIP working group, but which are worth mentioning=20 here: * There was early discussion about whether the scope of the work should=20 be a complete solution to response identity, or whether it should just=20 cover connected identity. During the discussions, it was identified=20 that the complete solution to response identity was a near impossible=20 problem to solve. There is no general solution to authenticating a=20 response except in specific circumstances, i.e. when a TLS connection=20 exists to the UAS. There is also an issue of whether the response is=20 coming from a legitimate location, i.e. if the request had been=20 retargetted. There was a draft-cao-sip-response-identity which was=20 therefore not proceeded with. * The document allows the changing of the From header field in a mid- dialog request from that given in the initial request. There was=20 discussion on whether changing the value was allowed and whether the=20 lack of compatibility with the now obsoleted RFC 2543 was an issue. It=20 was agreed that this compatibility issue had been adequately addressed=20 when RFC 3261 was published. This has a corresponding impact on the To=20 header field in the other direction. This does not relate to changing=20 the To header field in a retargeted request. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? As a security related document, the document has been reviewed by Eric=20 Rescorla (the security adviser to the SIP working group), and there are no=20 remaining unresolved issues. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The document defines a new SIP protocol extension for a particular purpose=20 in a form that has been used for many other extensions. The document=20 shepherd has no concerns with the document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has been well discussed by a significant number of members of=20 the working group (see answer in 1(b)). (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) None indicated. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The document has been reviewed against the guidelines in RFC 4485 and it is=20 believed that the document is conformant with those guidelines. While the document defines a new SIP option tag, these have been performed=20 as a SIP working group item, and therefore this draft is in conformance with=20 RFC 3427. The document passes ID-NITS (idnits 1.123). (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has split its references into normative and informative=20 references. All the normative and informative references are published RFCs.=20 All the normative references are standards track documents. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? Section 6 of the document registers a new option-tag; the new option-tag is=20 defined elsewhere in the document. This registration is consistent with RFC=20 3261 which defines the registry and is also consistent with the current=20 format of the registry. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document contains no entries written in formal language. Section 5 of=20 the document makes use of encoded keys within a SIP message body, and these=20 have been automatically generated using the same tools as for RFC 4474. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Because of retargeting of a Session Initiation Protocol (SIP) dialog-forming=20 request (changing the value of the Request-URI), the User Agent Server (UAS)=20 can have a different identity from that in the To header field. This=20 document provides a means for that User Agent (UA) to supply its identity to=20 the peer UA by means of a request in the reverse direction and for that=20 identity to be signed by an Authentication Service. The same mechanism can=20 be used to indicate a change of identity during a dialog, e.g., because of=20 some action in the Public Switched Telephone Network (PSTN) behind a gateway. =20 This document normatively updates RFC 3261 (SIP). Working Group Summary The document complements work already performed in RFC 4474 for=20 authenticated request identity, and forms an integral part of the chartered=20 work in this area. There is consensus in the working group to publish this=20 document. Document Quality The document has been well discussed by a significant number of members of=20 the working group. Personnel Keith Drage is the document shepherd for this document. Cullen Jennings is=20 the responsible Area Director. Regards Keith Keith Drage drage@alcatel-lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 18 09:09:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Xwa-0003Q1-RN; Thu, 18 Jan 2007 09:08:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7XwY-0003Pv-Od for sip@ietf.org; Thu, 18 Jan 2007 09:08:42 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7XwX-0002Uf-DX for sip@ietf.org; Thu, 18 Jan 2007 09:08:42 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Jan 2007 06:08:41 -0800 X-IronPort-AV: i="4.13,204,1167638400"; d="scan'208"; a="51077578:sNHT50746956" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0IE8fg8002117; Thu, 18 Jan 2007 09:08:41 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0IE8eOA020443; Thu, 18 Jan 2007 09:08:41 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 09:08:40 -0500 Received: from [161.44.182.244] ([161.44.182.244]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 09:08:40 -0500 Message-ID: <45AF7F68.3000908@cisco.com> Date: Thu, 18 Jan 2007 09:08:40 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Sip] RE: TCP connection establishment References: <000101c738d5$c0ca9580$f32915ac@NOE.Nokia.com> <45ABFA1F.8060809@lucent.com> <1169020776.5210.8.camel@macbuster.research.nokia.com> <45AE3094.4070903@cisco.com> <1169108772.5732.33.camel@macbuster.research.nokia.com> In-Reply-To: <1169108772.5732.33.camel@macbuster.research.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jan 2007 14:08:40.0568 (UTC) FILETIME=[27BBCF80:01C73B0A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3442; t=1169129321; x=1169993321; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20RE=3A=20TCP=20connection=20establishment |Sender:=20 |To:=20Aki=20Niemi=20; bh=0dRpdjihWn3OaND411gumDw8uc2zXeKhAUeJtf1eqB4=; b=BBXgZ3Xixp1ebezGBCrhD3ThmRltWltOUwDvN4BhUotnTVsAueabuGFJCNhUChVcRr1Jz72t GX+Nq1CtOh8KvGbOWDddLhprdpA7Tl7VWVUdnv/G+M0MdTp6vUOU8zwB; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: sip@ietf.org, Kai Vehmanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Aki Niemi wrote: > On Wed, 2007-01-17 at 09:20 -0500, ext Paul Kyzivat wrote: >> If the connection is direct from UA to registrar, then perhaps the >> registration is sufficient to authenticate the connection for reverse >> traffic. If the connection is from UA to proxy then the proxy has to >> make leaps of faith to trust the identity of the connection. > > I can't see this being any different with UDP, where the proxy in > between can effectively be an open relay, and has to trust the flows it > relays. In UDP, outbound requests from the registrar go to the registered contact address. It has to be resolved by the last proxy, and (in the absence of -outbound-) is independent of how the register was delivered. If you try to reuse a tcp connection for requests in the reverse direction, then the destination is the source port for the tcp connection, which has no direct relationship to the registered contact. There are various exploits for this, that permit somebody to hijack requests. For instance: suppose good UA GUA uses a proxy P and registers to registrar R, using AOR sip:gua@r. Then an evil UA - EUA could collude with an evil server ES to hijack requests outbound from R and intended for GUA. It could establish a TCP connection to P, and then send a REGISTER To: sip:gua@r, but with a Route header that takes it to ES, and with a copy of the contact used by GUA. ES then colludes by accepting that registration. At this point, P will think that the TCP connection from EUA is a valid path to gua. The details of this are all tied up in how you decide which requests can reuse the tcp connection. You can probably tighten things up to solve the above problem. If you work at it enough, I think you will end up with something like sip outbound. Rohan attempted, and was shot down. You can't just naively say that the connection can be reused for requests in the reverse direction. > But I also can't see how this problem is any different for, say, HTTP > proxies. That's why many HTTP proxies are configured to do > proxy-authentication, limit the ports to which clients can CONNECT, etc. > Similar logic can be added to a SIP proxy to ascertain that they not > become a totally open relay. I don't know much about HTTP implementation, but afaik there is nothing like the reverser routing that we are talking about here. So I don't see the analogy. Paul > The rule of thumb in doing this is that you don't commit expensive > resources, or allow all possible actions to be taken until the > connection, or flow, is considered trusted. > > > >> AFAIK the current version of connection reuse is primarily of interest >> for proxy-proxy connections. People keep wanting to apply it to UAs, >> apparently as a poor-man's-outbound. There may be a *few* cases where >> that can work. But attempting to do so is likely to just get people >> confused. I think we would be better off clearly partitioning the >> applicability of these two things. > > Yes, I agree. As I said in the past, we in practice have two very > different interfaces to a proxy: the client-to-server, and the > server-to-server. Outbound is for the former; conn-reuse for the latter. > Neither one has a problem with TCP, although the way one determines when > to trust a connection is very different for each. > > Cheers, > Aki > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 18 09:56:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7YfS-0002yw-Lw; Thu, 18 Jan 2007 09:55:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7YfQ-0002yh-To for sip@ietf.org; Thu, 18 Jan 2007 09:55:04 -0500 Received: from alnrmhc13.comcast.net ([204.127.225.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7YfM-0003Vc-5E for sip@ietf.org; Thu, 18 Jan 2007 09:55:04 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc13) with ESMTP id <20070118145459b130033st9e>; Thu, 18 Jan 2007 14:54:59 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l0IEswbM022938 for ; Thu, 18 Jan 2007 09:54:58 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0IEswgE022934; Thu, 18 Jan 2007 09:54:58 -0500 Date: Thu, 18 Jan 2007 09:54:58 -0500 Message-Id: <200701181454.l0IEswgE022934@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <50B1CBA96870A34799A506B2313F26670ACD99C0@ntht201e.siemenscomms.co.uk> (john.elwell@siemens.com) Subject: Re: [Sip] proxy redirected? References: <50B1CBA96870A34799A506B2313F26670ACD99C0@ntht201e.siemenscomms.co.uk> X-Spam-Score: 0.2 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Elwell, John" However, RFC 3261 places restrictions depending on whether the proxy is responsible for the domain of the existing Request-URI. It can recurse only if it is responsible for that domain - see 16.5. Interesting -- so other 302's have to be passed back upstream. And I suppose the UAC has blanket permission to act on any 3xx. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 18 15:04:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7dTj-0003iP-Ak; Thu, 18 Jan 2007 15:03:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7dTh-0003ho-7B for sip@ietf.org; Thu, 18 Jan 2007 15:03:17 -0500 Received: from sip.tutpro.com ([192.98.100.10] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7dTb-00053K-Nb for sip@ietf.org; Thu, 18 Jan 2007 15:03:17 -0500 Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id 51A4D1EC692; Thu, 18 Jan 2007 22:03:04 +0200 (EET) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3psiDyskO0li; Thu, 18 Jan 2007 22:02:55 +0200 (EET) Received: from rautu (unknown [124.6.202.180]) by tutpro.com (Postfix) with ESMTP; Thu, 18 Jan 2007 22:02:54 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 55148F1228; Thu, 18 Jan 2007 22:02:42 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17839.53858.283519.585845@rautu.test.fi> Date: Thu, 18 Jan 2007 22:02:42 +0200 From: Juha Heinanen To: Paul Kyzivat Subject: Re: [Sip] RE: TCP connection establishment In-Reply-To: <45AF7F68.3000908@cisco.com> References: <000101c738d5$c0ca9580$f32915ac@NOE.Nokia.com> <45ABFA1F.8060809@lucent.com> <1169020776.5210.8.camel@macbuster.research.nokia.com> <45AE3094.4070903@cisco.com> <1169108772.5732.33.camel@macbuster.research.nokia.com> <45AF7F68.3000908@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: sip@ietf.org, Kai Vehmanen , Aki Niemi X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul Kyzivat writes: > Then an evil UA - EUA could collude with an evil server ES to hijack > requests outbound from R and intended for GUA. It could establish a TCP > connection to P, and then send a REGISTER To: sip:gua@r, but with a > Route header that takes it to ES, and with a copy of the contact used by > GUA. my proxy does not allow pre-loaded route headers unless there is only one route header that points to the proxy/registrar itself. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 18 16:53:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7fAp-0004so-Dz; Thu, 18 Jan 2007 16:51:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7fAn-0004sj-N4 for sip@ietf.org; Thu, 18 Jan 2007 16:51:53 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7fAm-0008S7-Ac for sip@ietf.org; Thu, 18 Jan 2007 16:51:53 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 18 Jan 2007 13:51:49 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l0ILpmSo002056; Thu, 18 Jan 2007 13:51:48 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0ILpRi4008704; Thu, 18 Jan 2007 13:51:39 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 16:51:36 -0500 Received: from [161.44.182.244] ([161.44.182.244]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 16:51:35 -0500 Message-ID: <45AFEBE5.5090304@cisco.com> Date: Thu, 18 Jan 2007 16:51:33 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] RE: TCP connection establishment References: <000101c738d5$c0ca9580$f32915ac@NOE.Nokia.com> <45ABFA1F.8060809@lucent.com> <1169020776.5210.8.camel@macbuster.research.nokia.com> <45AE3094.4070903@cisco.com> <1169108772.5732.33.camel@macbuster.research.nokia.com> <45AF7F68.3000908@cisco.com> <17839.53858.283519.585845@rautu.test.fi> In-Reply-To: <17839.53858.283519.585845@rautu.test.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jan 2007 21:51:35.0843 (UTC) FILETIME=[D3166F30:01C73B4A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1334; t=1169157108; x=1170021108; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20RE=3A=20TCP=20connection=20establishment |Sender:=20; bh=3dAcjL3tVAematz4lQR852l8UTi5jNMJ3AmkweOe7wc=; b=kRPkL8Nq+iv4eQ28GdqTqwWVJNfOq6PIMzVVIlOqH+bmnCgytXGVqsp1sC/Z80d7raWqZVni F3TaygKkkgMkiZ61T0qNnl/e7yZqpS/HAcSHRsE+xlES4dcGlY9aWEhC; Authentication-Results: sj-dkim-5; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: sip@ietf.org, Kai Vehmanen , Aki Niemi X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Juha Heinanen wrote: > Paul Kyzivat writes: > > > Then an evil UA - EUA could collude with an evil server ES to hijack > > requests outbound from R and intended for GUA. It could establish a TCP > > connection to P, and then send a REGISTER To: sip:gua@r, but with a > > Route header that takes it to ES, and with a copy of the contact used by > > GUA. > > my proxy does not allow pre-loaded route headers unless there is only > one route header that points to the proxy/registrar itself. That is fine for you. And if you do that, and perhaps impose some other restrictions, then you can probably make the connection reuse in the reverse direction safe. But for us to specify in an RFC how to do connection reuse in the reverse direction with TCP will require writing down a whole set of restrictions like that. I see that being done - in the outbound draft - but not otherwise. If somebody wants to specify yet another way then I guess they can do so. Establishing a connection in one direction in order for it to be used in the other direction doesn't belong in the existing connection reuse draft because that doesn't do what is needed for it. In the absence of something that does, we must assume that independent connections will be established in each direction. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 19 08:03:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7tNw-0003qY-I9; Fri, 19 Jan 2007 08:02:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7tNv-0003qS-BC for sip@ietf.org; Fri, 19 Jan 2007 08:02:23 -0500 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7tNt-0003WB-LS for sip@ietf.org; Fri, 19 Jan 2007 08:02:23 -0500 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 0991820A306; Fri, 19 Jan 2007 14:02:18 +0100 (CET) Message-Id: <7.0.1.0.0.20070119085944.0271b438@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 19 Jan 2007 09:19:00 +0100 To: Paul Kyzivat , Tom-PT Taylor From: Jiri Kuthan Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] In-Reply-To: <45AD16A9.6070000@cisco.com> References: <7374777208BDC7449D5620EF9423256701614C26@esealmw113.eemea.ericsson.se> <45A7CDFB.5080705@cisco.com> <45A7DA65.5090802@alcatel-lucent.com> <45A7FED7.90604@cisco.com> <45ABF9C4.3090305@lucent.com> <4C1596FBF66C67478BCFE7B3F81FC1E01781EAA5EC@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <45ACF3AB.2080703@cisco.com> <4C1596FBF66C67478BCFE7B3F81FC1E01781EAA7A7@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <45ACF9D7.1000304@cisco.com> <45AD0122.8000102@nortel.com> <45AD16A9.6070000@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: SIP LIST , Sean Olson X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 19:17 16/01/2007, Paul Kyzivat wrote: >Tom-PT Taylor wrote: >>This isn't like provisioning a telephone trunk group (circuit group, in European terminology), where you know each trunk will eventually be freed when the call is complete. In the present case, you either provide for every client to be connected or you need a disconnect policy. What I suggest is a policy of disconnecting after some period of non-use, rather than in response to incoming calls. That prevents "feeding a DOS attack". > >Yes, some kind of disconnect policy. The connecting party has to play nice in that policy as well. If the connecting party always immediately reconnects then the policy doesn't work. Is this something we wish to debate in the IETF? I mean if an implementation's maximum of TCP connections is insufficient to serve given number of clients and given traffic, then a policy will not generate the missing resources, overprovisioning with more boxes will. Reminds me of the old QoS dilemma: QoS policies don't generate bandwidth, they do create unfairness rules. Which in this particular case leads to less preferred clients being disconnected and unreachable. Not sure if thats what we are striving for. The tough case is DoS-driven overload, however the assumption of being better off using a cooperative client respecting a policy doesnt help much either. -jiri > Paul > >>Paul Kyzivat wrote: >>> >>> >>>Sean Olson wrote: >>>>My main point is that dropping prior connections to accept a new connection is one possible policy, but hopefully not a commonly implemented one. Every deployment will have some limit. Very few deployments have absolutely no idea what their expected use will be though. Proper provisioning based on intended usage and empirical evidence is a reasonable assumption. There are other queuing/blocking techniques that can help with overload situations. DoS attacks in particular should not be responded to by dropping existing connections in order to feed the attack. >>> >>>I certainly agree in the DOS case. And I am not knowledgeable in this area, so will defer to somebody that is. But at some point one must either drop an existing connection or reject a connection request. It seems pretty unfair if you end up rejecting connection requests that might be important in order to preserve a connection that hasn't been used in hours, days, or more. >>> >>>Unfortunately, what the connection request arrives there is generally no good way to tell how important it is. You might be able to decide based on what it does after you accept the connection. But that is too late. >>> >>>As I say, I am no expert here, so I will be happy if somebody can specify how this can be handled reasonably if every prospective client continually attempts to connect. >>> >>> Paul >>> >>>>-----Original Message----- >>>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>Sent: Tuesday, January 16, 2007 7:48 AM >>>>To: Sean Olson >>>>Cc: Vijay K. Gurbani; SIP LIST >>>>Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] >>>> >>>> >>>> >>>>Sean Olson wrote: >>>>>Wow.... that's one option, but certainly not the only one. This is where I like to introduce multiple servers >>>> >>>>Sean - I'm not sure exactly which point you are trying to make. >>>> >>>>Certainly one option is to attempt to over configure the system so that >>>>there is enough capacity to accept every connection attempt. In certain >>>>closed environments that may be workable. But it is certainly not a >>>>solution for all environments. >>>> >>>>Presumably every deployment will have *some* limit. This limit could be >>>>reached in normal operation if the operators don't have control over the >>>>number of clients attempting to connect. That limit can support more >>>>devices if they don't attempt to keep the connection up all the time >>>>than it can if they do. >>>> >>>>The limit can also be reached as a result of devices that malfunction, >>>>or because of a DOS attack. The impact of that may also be worth some >>>>consideration. >>>> >>>> Paul >>>> >>>>>-----Original Message----- >>>>>From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] >>>>>Sent: Monday, January 15, 2007 2:02 PM >>>>>To: Paul Kyzivat >>>>>Cc: SIP LIST >>>>>Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] >>>>> >>>>>Paul Kyzivat wrote: >>>>>>Suppose a server can support 1000 connections, and devices connect as >>>>>>soon as turned on, and attempt to reconnect whenever their connection is >>>>>>dropped. Then when the device 1001 attempts to connect, the server will >>>>>>have to drop somebody - perhaps the one whose connection as been idle >>>>>>for the longest. But that device will immediately try to reconnect, >>>>>>forcing another device to be disconnected. This will continue >>>>>>indefinitely. Doesn't seem like a very good strategy. >>>>>Paul: Yes, you are right. I had forgotten about that insidious >>>>>side-effect. >>>>> >>>>>- vijay >>>>>-- >>>>>Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >>>>>2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >>>>>Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} >>>>>WWW: http://www.alcatel-lucent.com/bell-labs >>>>> >>>>>_______________________________________________ >>>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>This list is for NEW development of the core SIP Protocol >>>>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>>>Use sipping@ietf.org for new developments on the application of sip >>> >>>_______________________________________________ >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sipping@ietf.org for new developments on the application of sip > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 19 10:26:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7vbV-0004WX-UW; Fri, 19 Jan 2007 10:24:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7vbU-0004WS-Me for sip@ietf.org; Fri, 19 Jan 2007 10:24:32 -0500 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7vbS-0000Ji-1d for sip@ietf.org; Fri, 19 Jan 2007 10:24:32 -0500 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 779BF20A6CD; Fri, 19 Jan 2007 16:24:28 +0100 (CET) Message-Id: <7.0.1.0.0.20070119092641.027205b0@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 19 Jan 2007 16:24:03 +0100 To: Paul Kyzivat , Aki Niemi From: Jiri Kuthan Subject: Re: [Sip] RE: TCP connection establishment In-Reply-To: <45AF7F68.3000908@cisco.com> References: <000101c738d5$c0ca9580$f32915ac@NOE.Nokia.com> <45ABFA1F.8060809@lucent.com> <1169020776.5210.8.camel@macbuster.research.nokia.com> <45AE3094.4070903@cisco.com> <1169108772.5732.33.camel@macbuster.research.nokia.com> <45AF7F68.3000908@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: sip@ietf.org, Kai Vehmanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 15:08 18/01/2007, Paul Kyzivat wrote: >Aki Niemi wrote: >>On Wed, 2007-01-17 at 09:20 -0500, ext Paul Kyzivat wrote: >>>If the connection is direct from UA to registrar, then perhaps the registration is sufficient to authenticate the connection for reverse traffic. If the connection is from UA to proxy then the proxy has to make leaps of faith to trust the identity of the connection. >>I can't see this being any different with UDP, where the proxy in >>between can effectively be an open relay, and has to trust the flows it >>relays. > >In UDP, outbound requests from the registrar go to the registered contact address. It has to be resolved by the last proxy, and (in the absence of -outbound-) is independent of how the register was delivered. I'm worried that in interest of accomodating some overcomplicated scenarios we would be tempted to make the key mainstream cases difficult too. Running code (not SIP specifically, BTW) works as follows for sake of being able to deal with NATs and firewalls: - clients makes itself known. This registration request creates TCP or UDP bindings underway in NATs, firewalls, middleboxes, what-have-you - when a message comes back (reply or subsequent requests), it travels symmetrically so that bindings underway allow the message to pass through. - client keeps the "connection" alive periodically This is implemented this way because it is known to work over NATs and firewalls (mostly). >If you try to reuse a tcp connection for requests in the reverse direction, then the destination is the source port for the tcp connection, which has no direct relationship to the registered contact. If an implementation is done this way, I would label it suboptimal because of its lowered capability to deal with NATs/firewalls. I think a well behaving client implementation has direct relationship between contact and transport source. That's very important to get over NATs/firewalls. There are use-cases in which this doesn't hold but let's for now speak the UA maintstream case. >There are various exploits for this, that permit somebody to hijack requests. > >For instance: suppose good UA GUA uses a proxy P and registers to registrar R, using AOR sip:gua@r. > >Then an evil UA - EUA could collude with an evil server ES to hijack requests outbound from R and intended for GUA. It could establish a TCP connection to P, and then send a REGISTER To: sip:gua@r, but with a Route header that takes it to ES, and with a copy of the contact used by GUA. ES then colludes by accepting that registration. At this point, P will think that the TCP connection from EUA is a valid path to gua. I think that in this scenario the problem is blind trust (no authentication between elements, unreasonable trust in preloaded Route header fields). I dont think we should consider such unwise scenarios as a driver for whatever we may wish to do. I think that we should test against "running code" scenarios. Such as that GUA authenticates with R over P, R authenticates, and P only considers 200s from R as indication of success. I mean with the protocol as is, the network design space is quite huge but I don't think that we shall try to accomodate every allowable design, and we shall particularly avoid considering suboptimal (even though valid, protocol-wise) network designs as driver for our work. -jiri >The details of this are all tied up in how you decide which requests can reuse the tcp connection. You can probably tighten things up to solve the above problem. If you work at it enough, I think you will end up with something like sip outbound. Rohan attempted, and was shot down. You can't just naively say that the connection can be reused for requests in the reverse direction. > >>But I also can't see how this problem is any different for, say, HTTP >>proxies. That's why many HTTP proxies are configured to do >>proxy-authentication, limit the ports to which clients can CONNECT, etc. >>Similar logic can be added to a SIP proxy to ascertain that they not >>become a totally open relay. > >I don't know much about HTTP implementation, but afaik there is nothing like the reverser routing that we are talking about here. So I don't see the analogy. > > Paul > >>The rule of thumb in doing this is that you don't commit expensive >>resources, or allow all possible actions to be taken until the >>connection, or flow, is considered trusted. >> >> >>>AFAIK the current version of connection reuse is primarily of interest for proxy-proxy connections. People keep wanting to apply it to UAs, apparently as a poor-man's-outbound. There may be a *few* cases where that can work. But attempting to do so is likely to just get people confused. I think we would be better off clearly partitioning the applicability of these two things. >>Yes, I agree. As I said in the past, we in practice have two very >>different interfaces to a proxy: the client-to-server, and the >>server-to-server. Outbound is for the former; conn-reuse for the latter. >>Neither one has a problem with TCP, although the way one determines when >>to trust a connection is very different for each. >>Cheers, >>Aki > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 19 10:35:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7vlb-0001Tm-ND; Fri, 19 Jan 2007 10:34:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7vla-0001R7-0j for sip@ietf.org; Fri, 19 Jan 2007 10:34:58 -0500 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7vlY-0001Iu-GF for sip@ietf.org; Fri, 19 Jan 2007 10:34:58 -0500 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 0AB3B20A6CD; Fri, 19 Jan 2007 16:34:55 +0100 (CET) Message-Id: <7.0.1.0.0.20070119084541.058ed600@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 19 Jan 2007 16:34:54 +0100 To: Paul Kyzivat From: Jiri Kuthan In-Reply-To: <45ACF6EB.7030903@cisco.com> References: <45A689D2.4010402@cisco.com> <000101c738d5$c0ca9580$f32915ac@NOE.Nokia.com> <7.0.1.0.0.20070116141404.01fdb658@iptel.org> <45ACF6EB.7030903@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: sip@ietf.org, Kai Vehmanen , "Isomaki Markus \(Nokia-SIR/Espoo\)" , "Niemi Aki \(Nokia-NRC/Helsinki\)" , christer.holmberg@ericsson.com Subject: [Sip] Re: TCP connection establishment X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 17:01 16/01/2007, Paul Kyzivat wrote: >comment at end. > >Jiri Kuthan wrote: >>At 19:48 15/01/2007, Kai Vehmanen wrote: >>>Hello, >>> >>>On 11 Jan 2007, Paul Kyzivat wrote: >>>>If the server cannot establish a connection to the client, but the client can establish a TLS connection with mutual authentication, then that could qualify the client as *needing* a connection. I'm talking about other cases. In particular, if we are talking about TCP rather than TLS, then the client establishing a TCP connection doesn't establish a reverse path, unless outbound is used. >>>well, it's worth noting that in many real-life deployments the >>>TCP registration does establish a reverse path (even though >>>no IETF documents specify this yet -- waiting for sip-outbound). >>>Just look at iptel.org SER for example ("tcp_alias" settings, other implementations use "persistent TCP", etc, etc). >>> >>>These ain't pretty, that's for sure, but allow to use TCP as the >>>transport with some of the already existing clients. >>> >>>>You can register with a server in order to receive outbound calls without maintaining a connection, as long as the server can establish a connection when it is needed. >>>But how can a client possibly know which is the case? With >>>NATs on path, this is still doable, but with stateful firewalls, neither >>>the client nor the server can possibly know whether TCP connections can be established towards the client. Deciding-by-trial is way too slow as the FWs can drop packets silently, and the default timeouts are long. So except in cases where the access network characteristics are known, client will have to assume that _it_, the client, >>> >>>is the party responsible for initiating connections. >>Absolutely. In addition to the client-server-oriented NAT/firewall friendliness, >>one can argue even more generally using e2e principiles or Murphy laws: >>network can always fail somehow and the more robust approach for the client is >>just to rely on itself. > >What point are you making? I'm concurring with the point, it is client's responsibility to keep connections open, over which incoming requests will be coming. (Which is logical also for the reason, that if the client is behind a NAT, the server can't even open it, not speaking of keeping it alive.) >Vijay responded as I would have - the single TCP connection has major security concerns if used bidirectionally. You should only use TCP if you know you don't have NAT/FW issues, so that a separate TCP connection can be made in the other direction. here the initial email from Vijay re: connection_reuse: "For TCP, it is a connection-in-each direction because of the security properties associated with the TCP transport when used in SIP (so, you should not open up a TCP connection for REGISTER and expect to receive requests in the backwards direction over it.)" Isn't the security concern caused just by the fact that 'alias' is accepted as part of unathenticated request? -jiri >Otherwise, if you have your own cert you can use TLS and avoid the need for connection establishment in the reverse direction, or else you can use outbound. > >Practically speaking, a UA will typically not have a cert, and will need to use outbound. Connection reuse, via TCP or TLS, will typically only be useful between proxies. > > Paul -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 19 10:53:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7w3V-0003Ez-MY; Fri, 19 Jan 2007 10:53:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7w3U-0003Ep-GD for sip@ietf.org; Fri, 19 Jan 2007 10:53:28 -0500 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7w3T-0003pN-15 for sip@ietf.org; Fri, 19 Jan 2007 10:53:28 -0500 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 8414A20A6CD; Fri, 19 Jan 2007 16:53:25 +0100 (CET) Message-Id: <7.0.1.0.0.20070119165111.04ae7eb0@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 19 Jan 2007 16:53:24 +0100 To: "Kai Vehmanen" , "'ext Paul Kyzivat'" From: Jiri Kuthan In-Reply-To: <000101c738d5$c0ca9580$f32915ac@NOE.Nokia.com> References: <45A689D2.4010402@cisco.com> <000101c738d5$c0ca9580$f32915ac@NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: sip@ietf.org, "Isomaki Markus \(Nokia-SIR/Espoo\)" , "Niemi Aki \(Nokia-NRC/Helsinki\)" , christer.holmberg@ericsson.com Subject: [Sip] RE: TCP connection establishment X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 19:48 15/01/2007, Kai Vehmanen wrote: >Hello, > >On 11 Jan 2007, Paul Kyzivat wrote: >>If the server cannot establish a connection to the client, but >>the client can establish a TLS connection with mutual >>authentication, then that could qualify the client as >>*needing* a connection. I'm talking about other cases. In >>particular, if we are talking about TCP rather than TLS, then >>the client establishing a TCP connection doesn't establish a >>reverse path, unless outbound is used. > >well, it's worth noting that in many real-life deployments the >TCP registration does establish a reverse path (even though >no IETF documents specify this yet -- waiting for sip-outbound). >Just look at iptel.org SER for example ("tcp_alias" settings, >other implementations use "persistent TCP", etc, etc). > >These ain't pretty, that's for sure, but allow to use TCP as the >transport with some of the already existing clients. > >>You can register with a server in order to receive outbound >>calls without maintaining a connection, as long as the server >>can establish a connection when it is needed. > >But how can a client possibly know which is the case? With >NATs on path, this is still doable, but with stateful firewalls, neither >the client nor the server can possibly know whether TCP >connections can be established towards the client. Deciding-by-trial is way >too slow as the FWs can drop packets silently, and the default >timeouts are long. So except in cases where the access network >characteristics are known, client will have to assume that _it_, the client, > >is the party responsible for initiating connections. Yes, that's how running code works :-) It shall be noted that vast majority of other Internet applications is using this model for clients behind NATs/firewalls to be able to receive incoming traffic. The transport!=contact capability of SIP is IMO of problematic value and shall only be used as exception. -jiri -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 19 12:37:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7xfZ-0007SS-VK; Fri, 19 Jan 2007 12:36:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7xfW-0007Rz-Vw for sip@ietf.org; Fri, 19 Jan 2007 12:36:50 -0500 Received: from web52908.mail.yahoo.com ([206.190.49.18]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7xfT-0001U8-DJ for sip@ietf.org; Fri, 19 Jan 2007 12:36:50 -0500 Received: (qmail 80196 invoked by uid 60001); 19 Jan 2007 17:36:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Z+BRMF6Duri6R6JoKF1rSGKposNGcQvXE9McLZDFfAKxJ/jVeVlXI72uPDgTgu89+Pmu9QNExJTJRGeb4Qcjxr9YrOd261nvBrytxEi9vkdEs5RgQooDNAxscjQhz8nz4UTxB2kdVI9Kn2SlNZ3/RgaANAVfSWUy31zuGOUlm4Y=; X-YMail-OSG: _3nSygoVM1kt8_XynQMOFMIBQa9IlhdDpfKdcfcVctC.1D3Cx1NFTUp68KCAsP2EdxQbgk8m_ltm3uG6BkYYG6BXe2gdA2quAtFSPMx41ts8bVnRU9iP3q_D3Sd3c5MgN1gBzKWE_AY1_A-- Received: from [217.33.106.234] by web52908.mail.yahoo.com via HTTP; Fri, 19 Jan 2007 09:36:47 PST Date: Fri, 19 Jan 2007 09:36:47 -0800 (PST) From: Raj To: SIP forum MIME-Version: 1.0 Message-ID: <164841.78915.qm@web52908.mail.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Sip] To find size of a SIP message X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2042517122==" Errors-To: sip-bounces@ietf.org --===============2042517122== Content-Type: multipart/alternative; boundary="0-1660391067-1169228207=:78915" Content-Transfer-Encoding: 8bit --0-1660391067-1169228207=:78915 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello, I want to find a size of a SIP message. Can anyone help me to find out the size of a SIP message? thanks in advance with regards Raj. --------------------------------- Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. --0-1660391067-1169228207=:78915 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hello,
 
          I want to find a size of a SIP message. Can anyone help me to find out the size of a SIP message?
 
thanks in advance
 
with regards
Raj.
 
           

Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. --0-1660391067-1169228207=:78915-- --===============2042517122== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2042517122==-- From sip-bounces@ietf.org Fri Jan 19 12:42:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7xkH-0001rs-OO; Fri, 19 Jan 2007 12:41:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7xkF-0001oz-Qv for sip@ietf.org; Fri, 19 Jan 2007 12:41:43 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7xkE-0002Kp-5E for sip@ietf.org; Fri, 19 Jan 2007 12:41:43 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l0JHfeBm028328 for ; Fri, 19 Jan 2007 10:41:41 -0700 (MST) Received: from srvxchg.cablelabs.com (10.5.0.20) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com); Fri, 19 Jan 2007 10:41:40 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 Jan 2007 10:41:39 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Outbound-07 comments Thread-Index: Acc78RK+tCZJabLuTO+J/cnCMOVHUA== From: "Kevin Johns" To: X-Approved: ondar X-Spam-Score: 0.1 (/) X-Scan-Signature: 872695ea777a517bf5717e5acc69f8be Subject: [Sip] Outbound-07 comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1259472243==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1259472243== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73BF1.1340500C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73BF1.1340500C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I did a read of Outbound-07 and have a few comments for consideration. Overall this is a solid draft.=20 =20 Regards, Kevin =20 Introduction, First paragraph, Second to last sentence has a typo - Similarly there a NAT could be present,... I think if you remove 'there' the sentence would read correctly. =20 4.2. Initial Registrations This section seems to cover both initial registration and re-registration procedures. It might be helpful to break out the re-registration requirements into a separate section. =20 4.4.2. Keepalive with STUN Can you make the text normative? Specifically, if no other keepalive mechanism is being used and the keepalive parameter is present in the URI, the UA MUST periodically perform keepalive checks by sending STUN binding requests... =20 5.3. Forwarding Requests The second sentence states,=20 "If the Edge Proxy receives a request where the edge proxy is the host in the topmost Route header field value, and the Route header contains a flow token, the proxy compares the flow in the flow token with the source of the request. If these refer to the same flow, the Edge Proxy removes the Route header and continues processing the request." =20 When would this ever occur? This seems to imply that the UA is originating a dialog initiating request and inserts a route header with a flow token which identifies the flow the UAC sent the request on. There are no requirements in the draft indicating the UAC must do so, further RFC 3327 does not indicate the UAC should include the Path header received in the response to the REGISTER as a route header in a dialog initiating response. =20 Additionally, This section talks about 'if the Edge Proxy determines the Route header contains a flow token'. How does it determine this? I assume based on the presence of the 'ob' parameter which was in the Path header. If this is the case, it might be clearer to indicate if the Route header contains the 'ob' parameter the Edge Proxy must do xyz... =20 6. Registrar Mechanisms: Processing REGISTER Requests First paragraph, suggest restructuring to cover, no sip.instance, sip.instance only, sip.instance with reg-id and reg-id only. Also, none of this text is normative. Given it is updating the binding procedures defined in RFC 3261 it might be useful to make this normative. =20 Sixth paragraph, why is the registrar required to store the reg-id if the rules above are invoked and the registrar ignores this parameter? While this is the simplest thing to do, it affects the re-registration procedures as the registrar has to remember that it previously ignored the reg-id and cannot use it to determine which contact to update on re-registration. I think the intended operation is clear given the text on initail registration (if the ob parameter in the first path header entry is absent ignore the reg-id), but the one sentence on re-registration (same paragraph) does not call out these rules. =20 Finally, there are no requirements on how the registrar manages the contacts for a given AOR-instance-id combination. Would it be possible to add a paragarph to cover registrar contact management in the case it does not have a direct flow with the UAC? =20 9. Example Message Flow The 200 OK responses to the REGISTER requests do not contain the Path header. Given the UAC is required to support this and can optionally inspect the value returned in the REGISTER response, its should be included for completeness. =20 Message 8 - Why would the Edge Proxy record-route with a flow token? This is a mid-dialog issue and given it is out of scope of outbound should not be covered in the message flow, or indicated that the secondary edge proxy may record-route and optionally include a flow token with a disclaimer that this may affect mid-dialog failover capabilities. =20 ~~~~~~~~~~~~~~~~~~~~~~ Kevin C. Johns Project Director - PacketCable Communications Protocols CableLabs(r) 858 Coal Creek Circle Louisville, CO 80027-9750 Phone: 303.661.9100 Direct: 303.661.3303 HTTP://www.CableLabs.com =20 =20 ------_=_NextPart_001_01C73BF1.1340500C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I did a=20 read of Outbound-07 and have a few comments for consideration.=20 Overall this is a solid draft.=20

 

Regards,

Kevin

 

Introduction,

First=20 paragraph, Second to last sentence has a typo - Similarly there a = NAT=20 could be present,… I think if you remove 'there' the sentence = would read=20 correctly.

 

4.2. Initial Registrations

This section seems to cover both initial registration and = re-registration=20 procedures. It might be helpful = to break=20 out the re-registration requirements into a separate section.

 

4.4.2. Keepalive with STUN

Can you make the text normative? Specifically, if no other = keepalive=20 mechanism is being used and the keepalive parameter is present in the = URI, the=20 UA MUST periodically perform keepalive checks by sending STUN binding=20 requests…

 

5.3. Forwarding Requests

The second sentence states,

"If the Edge Proxy receives a request where the edge proxy is = the host in=20 the topmost Route header field value, and the Route header contains a = flow=20 token, the proxy compares the flow in the flow token with the source of = the=20 request. If these refer to the same flow, the Edge Proxy removes the = Route=20 header and continues processing the request."

 

When would this ever occur? This seems to imply that the UA is=20 originating a dialog initiating request and inserts a route header with = a flow=20 token which identifies the flow the UAC = sent the=20 request on. There are no requirements in the draft indicating the = UAC=20 must do so, further RFC 3327 does not indicate the UAC should include = the Path=20 header received in the response to the REGISTER as a route header in a = dialog=20 initiating response.

 

Additionally, This section talks about 'if the Edge Proxy = determines the=20 Route header contains a flow token'. How does it determine this? I = assume based=20 on the presence of the 'ob' parameter which was in the Path header. If = this is=20 the case, it might be clearer to = indicate=20 if the Route header contains the 'ob' parameter the Edge Proxy must do=20 xyz…

 

6. Registrar Mechanisms: Processing REGISTER = Requests

First paragraph, suggest restructuring to cover, no = sip.instance,=20 sip.instance only, sip.instance with reg-id and reg-id only. Also, none = of this=20 text is normative. Given it is updating the binding procedures defined = in RFC=20 3261 it might be useful to make this normative.

 

Sixth paragraph, why is the = registrar=20 required to store the reg-id if the rules above are invoked and the = registrar=20 ignores this parameter? While this is the simplest thing to do, it = affects the=20 re-registration procedures as the registrar has to remember that it = previously=20 ignored the reg-id and cannot use it to determine which contact to = update on=20 re-registration. I think the intended = operation=20 is clear given the text on initail registration (if the ob parameter in = the=20 first path header entry is absent ignore the reg-id), but the one = sentence on=20 re-registration (same paragraph) does not call out these=20 rules.

 

Finally,=20 there are no requirements on how the registrar manages the contacts for = a given=20 AOR-instance-id combination. Would it be possible to add a paragarph to = cover=20 registrar contact management in the case it does not have a direct flow = with the=20 UAC?

 

9. Example Message Flow

The 200 OK responses to the REGISTER requests do not contain = the Path=20 header. Given the UAC is required to support this and can optionally = inspect the=20 value returned in the REGISTER response, its should be included for=20 completeness.

 

Message 8 – Why would the = Edge Proxy=20 record-route with a flow token? This is a mid-dialog issue and given it = is out=20 of scope of outbound should not be covered in the message flow, or = indicated=20 that the secondary edge proxy may record-route and optionally include a = flow=20 token with a disclaimer that this may = affect=20 mid-dialog failover capabilities.

 

~~~~~~~~~~~~~~~~~~~~~~
Kevin C.=20 Johns
Project Director - PacketCable Communications=20 Protocols
CableLabs®
858 Coal Creek Circle
Louisville, CO=20 80027-9750
Phone:  303.661.9100
Direct: = 303.661.3303
HTTP://www.CableLabs.com =

 
------_=_NextPart_001_01C73BF1.1340500C-- --===============1259472243== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1259472243==-- From sip-bounces@ietf.org Fri Jan 19 13:03:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7y57-0006W1-7b; Fri, 19 Jan 2007 13:03:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7y55-0006Vv-So for sip@ietf.org; Fri, 19 Jan 2007 13:03:15 -0500 Received: from alnrmhc12.comcast.net ([206.18.177.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7y53-0006Kp-MD for sip@ietf.org; Fri, 19 Jan 2007 13:03:15 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc12) with ESMTP id <20070119180312b1200jq2gje>; Fri, 19 Jan 2007 18:03:13 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l0JI3CbM012440 for ; Fri, 19 Jan 2007 13:03:12 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0JI3CTu012436; Fri, 19 Jan 2007 13:03:12 -0500 Date: Fri, 19 Jan 2007 13:03:12 -0500 Message-Id: <200701191803.l0JI3CTu012436@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <164841.78915.qm@web52908.mail.yahoo.com> (ponrajit@yahoo.com) Subject: Re: [Sip] To find size of a SIP message References: <164841.78915.qm@web52908.mail.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Raj I want to find a size of a SIP message. Can anyone help me to find out the size of a SIP message? See sections 7.4, 18.3, and 20.14 of RFC 3261. Or just search for "Content-Length" in the RFC. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From hesse@aboutface2.com Fri Jan 19 15:56:37 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H80mr-0001v9-Ba for sip-archive@lists.ietf.org; Fri, 19 Jan 2007 15:56:37 -0500 Received: from 216.red-83-59-218.dynamicip.rima-tde.net ([83.59.218.216]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H80mY-0008P3-QS for sip-archive@lists.ietf.org; Fri, 19 Jan 2007 15:56:37 -0500 Received: from 64.74.223.15 (HELO mxin.name-services.com) by lists.ietf.org with esmtp (Y+1KX37E+ C2189) id Q)99S9-/,1I-O-AC for sip-archive@lists.ietf.org; Fri, 19 Jan 2007 20:56:26 -0060 Message-ID: <01c73c0c$49066b20$6c822ecf@hesse> From: "Ivy Arias" To: Subject: Microsoft Office 2007 Enterprise ready to download Date: Fri, 19 Jan 2007 20:56:26 -0060 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.2300 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Office 2007 is available for enterprise users from November 30, 2006. The end user version is available from the beginning of 2007. The 2007 Microsoft Office System, also known as Microsoft Office 2007, is the most recent version of Microsoft's productivity suite. Formerly known as Office 12 in the initial stages of its beta cycle, it was scheduled to be made available to volume license customers on November 30, 2006, with general availability following in early 2007. Office 2007 contains a number of new features, the most notable of which is the entirely new graphical user interface called the Ribbon, replacing the menus and toolbars that have been the cornerstone of Office since its inception. Office 2007 also includes new applications and server-side tools. Chief amongst these is Groove, a collaboration and communication suite for smaller businesses which was originally developed by Groove Networks before being acquired by Microsoft in 2005. Also included is Office Sharepoint Server 2007, a major revision to the server platform for Office applications, which supports "Excel Services", a client-server architecture for supporting Excel workbooks that are shared in real time between multiple machines, and are also viewable and editable through a web page. While Office 2007 includes many new features, one has been removed entirely: Microsoft FrontPage is no longer being developed; its successor is the Microsoft Expression line of products. Microsoft Office 2007 Enterprise Retail Price $899.00 Our Price $79.95 You save $819.05 http://blanchdonline.org Please note, that there will be more special offers available for our constant customers. Every effort has been made to ensure the accuracy of all information contained herein. DS Team makes no warranty expressed or implied with respect to accuracy of the information, including price, product editorials or product specifications. Product and manufacturer names are used only for the purpose of identification. We appreciate your cooperation with us and we'll be glad to see you as our clients in the future. From sip-bounces@ietf.org Fri Jan 19 17:08:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H81tS-0000DC-Un; Fri, 19 Jan 2007 17:07:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H81tR-0000Cv-GJ for sip@ietf.org; Fri, 19 Jan 2007 17:07:29 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H81tN-0008L8-Fz for sip@ietf.org; Fri, 19 Jan 2007 17:07:29 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l0JM7OLb010333; Fri, 19 Jan 2007 16:07:25 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l0JM7Ou08142; Fri, 19 Jan 2007 16:07:24 -0600 (CST) Message-ID: <45B1411C.4060505@alcatel-lucent.com> Date: Fri, 19 Jan 2007 16:07:24 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jiri@iptel.org Subject: Re: [Sip] Re: TCP connection establishment References: <45A689D2.4010402@cisco.com> <000101c738d5$c0ca9580$f32915ac@NOE.Nokia.com> <7.0.1.0.0.20070116141404.01fdb658@iptel.org> <45ACF6EB.7030903@cisco.com> <7.0.1.0.0.20070119084541.058ed600@iptel.org> In-Reply-To: <7.0.1.0.0.20070119084541.058ed600@iptel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jiri Kuthan wrote: > here the initial email from Vijay re: connection_reuse: > "For TCP, it is a connection-in-each direction because of the security > properties associated with the TCP transport when used in SIP > (so, you should not open up a TCP connection for REGISTER and > expect to receive requests in the backwards direction over it.)" > > Isn't the security concern caused just by the fact that 'alias' is accepted > as part of unathenticated request? Yes, and section 9.3 of connect-reuse indicates that HTTP Digest may mitigate a subset of the problems of TCP connection reuse. But HTTP Digest cannot be used for proxy-proxy communications. So what is the answer for reusing TCP connections between proxies in the face of NATs and firewalls? The canonical answer is to use the same connection in the backwards direction because the NATs will allow data packets through that connection. But sending a request through that connection open the proxy to hijacking... - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From whitbypru@telewest.co.uk Sun Jan 21 21:13:57 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8oh3-0006K6-AT for sip-archive@lists.ietf.org; Sun, 21 Jan 2007 21:13:57 -0500 Received: from [61.5.65.73] (helo=meteor01) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H8oh0-0005nO-Tk for sip-archive@lists.ietf.org; Sun, 21 Jan 2007 21:13:57 -0500 Content-Class: urn:content-classes:message To: "nataline angie" From: "sholom linoel" Date: Mon, 22 Jan 2007 09:13:11 +0700 Sender: "sholom linoel" Subject: Hi MIME-Version: 1.0 Message-ID: <204301c73dca$ddddb090$0b0a0a0a@meteor01> Content-Type: multipart/alternative; boundary="----=_NextPart_000_165B_01C73E05.4002EA80" X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d This is a multi-part message in MIME format. ------=_NextPart_000_165B_01C73E05.4002EA80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Manzilla! Size does matter! You seen this on TV! http://gagadomen.com/ex/ quasi-living ------=_NextPart_000_165B_01C73E05.4002EA80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Manzilla! Size does matter! You seen this on TV!
http://gagadomen.com/ex/
quasi-living ------=_NextPart_000_165B_01C73E05.4002EA80-- From sip-bounces@ietf.org Mon Jan 22 01:26:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8saa-0007SU-DZ; Mon, 22 Jan 2007 01:23:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8saY-0007PQ-TG for sip@ietf.org; Mon, 22 Jan 2007 01:23:30 -0500 Received: from wx-out-0506.google.com ([66.249.82.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8saX-0000bn-JD for sip@ietf.org; Mon, 22 Jan 2007 01:23:30 -0500 Received: by wx-out-0506.google.com with SMTP id h31so1233221wxd for ; Sun, 21 Jan 2007 22:23:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ieiqC/KUNLwcQTVFEEMPFla5iZTcLlp+mosM2Pdwy315qJYsnNItP9Ui0wqNYqD26tMNQpaXw/R2F4dTnlnK03bXLG8dqalzdllGzmaY54DDPZy4NqOSkx4zITqG72huvKejW6MDs8CZnzABpeQQx/HmjrX4LlHw8/htQKG4GSI= Received: by 10.90.72.10 with SMTP id u10mr5636117aga.1169447007197; Sun, 21 Jan 2007 22:23:27 -0800 (PST) Received: by 10.90.69.20 with HTTP; Sun, 21 Jan 2007 22:23:27 -0800 (PST) Message-ID: <91d266200701212223q3fcd5d9dg155e454b120af87a@mail.gmail.com> Date: Mon, 22 Jan 2007 11:53:27 +0530 From: "NC Reddy" To: "Dale.Worley@comcast.net" Subject: Re: [Sip] To find size of a SIP message In-Reply-To: <200701191803.l0JI3CTu012436@dragon.ariadne.com> MIME-Version: 1.0 References: <164841.78915.qm@web52908.mail.yahoo.com> <200701191803.l0JI3CTu012436@dragon.ariadne.com> X-Spam-Score: 1.1 (+) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1753294830==" Errors-To: sip-bounces@ietf.org --===============1753294830== Content-Type: multipart/alternative; boundary="----=_Part_145911_28755154.1169447007062" ------=_Part_145911_28755154.1169447007062 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline content-length field gives only size of the SIP msg body/payload not the complete sip msg size. On 1/19/07, Dale.Worley@comcast.net wrote: > > From: Raj > > I want to find a size of a SIP message. Can anyone help me to find > out the size of a SIP message? > > See sections 7.4, 18.3, and 20.14 of RFC 3261. Or just search for > "Content-Length" in the RFC. > > Dale > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------=_Part_145911_28755154.1169447007062 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
content-length field gives only size of the SIP msg body/payload not the complete sip msg size.

On 1/19/07, Dale.Worley@comcast.net <Dale.Worley@comcast.net> wrote:
   From: Raj <ponrajit@yahoo.com>

   I want to find a size of a SIP message. Can anyone help me to find
   out the size of a SIP message?

See sections 7.4, 18.3 , and 20.14 of RFC 3261.  Or just search for
"Content-Length" in the RFC.

Dale

_______________________________________________
Sip mailing list   https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip

------=_Part_145911_28755154.1169447007062-- --===============1753294830== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1753294830==-- From sip-bounces@ietf.org Mon Jan 22 03:31:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8uZ9-0001ML-50; Mon, 22 Jan 2007 03:30:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8uZ7-0001MG-VY for sip@ietf.org; Mon, 22 Jan 2007 03:30:09 -0500 Received: from maildialog.com ([195.159.98.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8uZ6-0008U6-K7 for sip@ietf.org; Mon, 22 Jan 2007 03:30:09 -0500 Received: from cm-84.209.226.067.chello.no ([84.209.226.67] helo=[10.0.0.4]) by maildialog.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51-maildialog) id 1H8uZ0-00060q-8B for sip@ietf.org; Mon, 22 Jan 2007 08:30:03 +0000 Message-ID: <45B4756A.3000000@db.org> Date: Mon, 22 Jan 2007 09:27:22 +0100 From: "Alfred E. Heggestad" User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: [Sip] Comments on draft-ietf-sip-outbound-07 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Comments on draft-ietf-sip-outbound-07 > 3.5. Keepalive Technique > > For connection-less transports, a flow definition could change > because a NAT device in the network path reboots and the resulting > public IP address or port mapping for the UA changes. To detect > this, requests are sent over the same flow that is being used for the > ^^^^^^^^^^^^^^^^^ suggest renaming to "STUN Binding Requests are periodically sent ..." > 4.1. Instance ID Creation > > Each UA MUST have an Instance Identifier URN that uniquely identifies > > ... > > The UA SHOULD include a "sip.instance" media feature tag as a UA > Why should the UA have a URN if it cannot use it in the signalling ? Maybe change SHOULD to MUST ? > 4.4. Detecting Flow Failure > > The time between keepalive requests when using UDP-based transports > SHOULD be a random number between 24 and 29 seconds while for TCP- > based transports it SHOULD be a random number between 95 and 120 > seconds. perhaps a silly questions, but should this interval change for each keepalive request? I.e. should the UA re-calculate a new random value for each keepalive request, or should it only calculate it once and then re-use the same value for all subsequent keepalive requests. in any case this is implementation specific but might be clarified. > 8. STUN Keepalive Processing > it seems to me that the logic of detecting if the SIP server supports STUN multiplex is too complex and might lead to buggy implementations or operational problems. would it not be better for the client to check the Supported: sip-stun option tag in the 200 OK response for the REGISTER message? the behaviour of the SIP server can also change over time, i.e. moving from old-style SIP server w/o STUN to support sip-stun, and vice versa. the client will check the sip-stun option tag for each 200 OK and either enable or disable STUN Binding Discovery. General comments: could we also include some example message flows between the Edge Proxy and the registrar? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 22 03:46:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8uoJ-0007lq-3v; Mon, 22 Jan 2007 03:45:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8uoH-0007lS-4e for sip@ietf.org; Mon, 22 Jan 2007 03:45:49 -0500 Received: from spark.hss.co.in ([203.145.155.21] helo=tapal.aricent.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8uoD-0005Dc-Ln for sip@ietf.org; Mon, 22 Jan 2007 03:45:49 -0500 Received: from tapal.aricent.com (localhost [127.0.0.1]) by tapal.aricent.com (8.13.8/8.13.8) with ESMTP id l0M8jlNl009559 for ; Mon, 22 Jan 2007 14:15:47 +0530 Received: from chemail01.che.flextronics.com (chemail01.che.flextronics.com [10.203.112.151])by tapal.aricent.com (8.13.8/8.13.8) with ESMTP id l0M8jkjb009548;Mon, 22 Jan 2007 14:15:46 +0530 In-Reply-To: <164841.78915.qm@web52908.mail.yahoo.com> To: Raj MIME-Version: 1.0 X-Mailer: Lotus Notes Build V655_10312005 October 31, 2005 Message-ID: From: Balaji Murlitharan Date: Mon, 22 Jan 2007 14:13:28 +0530 X-MIMETrack: Serialize by Router on Chemail01/CHE/HSS(Release 6.5.5|November 30, 2005) at01/22/2007 02:13:01 PM,Serialize complete at 01/22/2007 02:13:01 PM X-imss-version: 2.045 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-19.9515 TC:02 TRN:55 TV:3.6.1039(14946.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:2 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.2 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: SIP forum , sip-implementors-bounces@cs.columbia.edu Subject: [Sip] Re: [Sip-implementors] To find size of a SIP message X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1286520249==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1286520249== Content-Type: multipart/alternative; boundary="=_alternative 00304AB76525726B_=" This is a multipart message in MIME format. --=_alternative 00304AB76525726B_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SGkgUmFqLA0KDQpUaGUgc2l6ZSBvZiAgU0lQIE1lc3NhZ2UgaXMgbm90IGEgY29uc3RhbnQgb25l LCBJdCB2YXJpZXMgZGVwZW5kcyB1cG9uIHRoZSANCkhlYWRlcnMgaW5jbHVkZWQgYnkgdGhlIFNJ UCBFbnRpdHkuIElmIHlvdSB3YW50IHRvIGdldCB0aGUgTWVzc2FnZSBCb2R5IA0Kc2l6ZSBpbiBh IFNJUCBNZXNzYWdlLCB5b3UgY2FuIGdldCBpdCBmcm9tIHRoZSAiQ29udGVudC1MZW5ndGggIiBo ZWFkZXIuIA0KDQpSZWdkcywNCkJhbGFqaSBNdXJsaXRoYXJhbi5DDQpBcmljZW50IA0KDQoNCg0K DQpSYWogPHBvbnJhaml0QHlhaG9vLmNvbT4gDQpTZW50IGJ5OiBzaXAtaW1wbGVtZW50b3JzLWJv dW5jZXNAY3MuY29sdW1iaWEuZWR1DQowMS8xOS8yMDA3IDExOjA2IFBNDQoNCg0KVG8NClNJUCBm b3J1bSA8c2lwQGlldGYub3JnPg0KY2MNCg0KU3ViamVjdA0KW1NpcC1pbXBsZW1lbnRvcnNdIFRv IGZpbmQgc2l6ZSBvZiBhIFNJUCBtZXNzYWdlDQoNCg0KDQoNCg0KDQpIZWxsbywNCiANCiAgICAg ICAgICAgIEkgd2FudCB0byBmaW5kIGEgc2l6ZSBvZiBhIFNJUCBtZXNzYWdlLiBDYW4gYW55b25l IGhlbHAgbWUgdG8gDQpmaW5kIG91dCB0aGUgc2l6ZSBvZiBhIFNJUCBtZXNzYWdlPw0KIA0KICB0 aGFua3MgaW4gYWR2YW5jZQ0KIA0KICB3aXRoIHJlZ2FyZHMNCiAgUmFqLg0KIA0KIA0KDQogDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNoZWFwIFRhbGs/IENoZWNrIG91dCBZ YWhvbyEgTWVzc2VuZ2VyJ3MgbG93IFBDLXRvLVBob25lIGNhbGwgcmF0ZXMuDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU2lwLWltcGxlbWVudG9ycyBt YWlsaW5nIGxpc3QNClNpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1DQpodHRwczovL2xp c3RzLmNzLmNvbHVtYmlhLmVkdS9jdWNzbGlzdHMvbGlzdGluZm8vc2lwLWltcGxlbWVudG9ycw0K DQoNCg0KKioqKioqKioqKioqKioqKioqKioqKiogIEFyaWNlbnQtUHJpdmF0ZSAgICoqKioqKioq KioqKioqKioqKioqKioqDQoiRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHByb3ByaWV0YXJ5 IHRvIEFyaWNlbnQgYW5kIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiAKdGhlIGlu ZGl2aWR1YWwgdG8gd2hvbSBpdCBpcyBhZGRyZXNzZWQuIEl0IG1heSBjb250YWluIHByaXZpbGVn ZWQgb3IgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGFuZCBzaG91bGQgbm90IGJlIApjaXJjdWxh dGVkIG9yIHVzZWQgZm9yIGFueSBwdXJwb3NlIG90aGVyIHRoYW4gZm9yIHdoYXQgaXQgaXMgaW50 ZW5kZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgCnBsZWFz ZSBub3RpZnkgdGhlIG9yaWdpbmF0b3IgaW1tZWRpYXRlbHkuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgbm90aWZpZWQgdGhhdCB5b3UgYXJlIHN0cmljdGx5 CnByb2hpYml0ZWQgZnJvbSB1c2luZywgY29weWluZywgYWx0ZXJpbmcsIG9yIGRpc2Nsb3Npbmcg dGhlIGNvbnRlbnRzIG9mIHRoaXMgbWVzc2FnZS4gQXJpY2VudCBhY2NlcHRzIG5vIHJlc3BvbnNp YmlsaXR5IGZvciAKbG9zcyBvciBkYW1hZ2UgYXJpc2luZyBmcm9tIHRoZSB1c2Ugb2YgdGhlIGlu Zm9ybWF0aW9uIHRyYW5zbWl0dGVkIGJ5IHRoaXMgZW1haWwgaW5jbHVkaW5nIGRhbWFnZSBmcm9t IHZpcnVzLiIK --=_alternative 00304AB76525726B_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFJhaiw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZSBzaXplIG9mICZuYnNwO1NJ UCBNZXNzYWdlIGlzIG5vdA0KYSBjb25zdGFudCBvbmUsIEl0IHZhcmllcyBkZXBlbmRzIHVwb24g dGhlIEhlYWRlcnMgaW5jbHVkZWQgYnkgdGhlIFNJUA0KRW50aXR5LiBJZiB5b3Ugd2FudCB0byBn ZXQgdGhlIE1lc3NhZ2UgQm9keSBzaXplIGluIGEgU0lQIE1lc3NhZ2UsIHlvdQ0KY2FuIGdldCBp dCBmcm9tIHRoZSAmcXVvdDtDb250ZW50LUxlbmd0aCAmcXVvdDsgaGVhZGVyLiA8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPjxiPlJlZ2RzLDxicj4NCkJhbGFqaSBNdXJsaXRoYXJhbi5D PGJyPg0KQXJpY2VudCA8L2I+PGJyPg0KPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxl IHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD00MCU+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPjxiPlJhaiAmbHQ7cG9ucmFqaXRAeWFob28uY29tJmd0OzwvYj4N CjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+U2VudCBieTogc2lw LWltcGxlbWVudG9ycy1ib3VuY2VzQGNzLmNvbHVtYmlhLmVkdTwvZm9udD4NCjxwPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj4wMS8xOS8yMDA3IDExOjA2IFBNPC9mb250Pg0KPGJyPg0K PHRkIHdpZHRoPTU5JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyPg0KPHRkPg0KPGRpdiBhbGln bj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+VG88L2ZvbnQ+PC9kaXY+DQo8 dGQgdmFsaWduPXRvcD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+U0lQIGZvcnVtICZs dDtzaXBAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Y2M8L2ZvbnQ+PC9kaXY+DQo8dGQgdmFsaWdu PXRvcD4NCjx0cj4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPlN1YmplY3Q8L2ZvbnQ+PC9kaXY+DQo8dGQgdmFsaWduPXRvcD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+W1NpcC1pbXBsZW1lbnRvcnNdIFRvIGZpbmQNCnNpemUgb2Yg YSBTSVAgbWVzc2FnZTwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+SGVsbG8sPGJyPg0KICZuYnNwOyA8YnI+DQogJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJIHdhbnQgdG8gZmluZCBhIHNpemUgb2YgYSBTSVAN Cm1lc3NhZ2UuIENhbiBhbnlvbmUgaGVscCBtZSB0byBmaW5kIG91dCB0aGUgc2l6ZSBvZiBhIFNJ UCBtZXNzYWdlPzxicj4NCiAmbmJzcDsgPGJyPg0KICZuYnNwO3RoYW5rcyBpbiBhZHZhbmNlPGJy Pg0KICZuYnNwOyA8YnI+DQogJm5ic3A7d2l0aCByZWdhcmRzPGJyPg0KICZuYnNwO1Jhai48YnI+ DQogJm5ic3A7IDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDs8YnI+DQo8YnI+DQogPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPGJyPg0KQ2hlYXAgVGFsaz8gQ2hlY2sgb3V0IFlhaG9vISBNZXNzZW5nZXIncyBsb3cgUEMt dG8tUGhvbmUgY2FsbCByYXRlcy48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NClNpcC1pbXBsZW1lbnRvcnMgbWFpbGluZyBsaXN0PGJyPg0K U2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHU8YnI+DQpodHRwczovL2xpc3RzLmNzLmNv bHVtYmlhLmVkdS9jdWNzbGlzdHMvbGlzdGluZm8vc2lwLWltcGxlbWVudG9yczxicj4NCjwvZm9u dD48L3R0Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQoq KioqKioqKioqKioqKioqKioqKioqKiAmbmJzcDtBcmljZW50LVByaXZhdGUgJm5ic3A7ICoqKioq KioqKioqKioqKioqKioqKioqPC9mb250Pg0KPHRhYmxlPjx0cj48dGQgYmdjb2xvcj0jZmZmZmZm Pjxmb250IGNvbG9yPSMwMDAwMDA+PHByZT4iRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHBy b3ByaWV0YXJ5IHRvIEFyaWNlbnQgYW5kIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBv ZiAKdGhlIGluZGl2aWR1YWwgdG8gd2hvbSBpdCBpcyBhZGRyZXNzZWQuIEl0IG1heSBjb250YWlu IHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGFuZCBzaG91bGQgbm90IGJl IApjaXJjdWxhdGVkIG9yIHVzZWQgZm9yIGFueSBwdXJwb3NlIG90aGVyIHRoYW4gZm9yIHdoYXQg aXQgaXMgaW50ZW5kZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJv ciwgCnBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3IgaW1tZWRpYXRlbHkuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgbm90aWZpZWQgdGhhdCB5b3UgYXJl IHN0cmljdGx5CnByb2hpYml0ZWQgZnJvbSB1c2luZywgY29weWluZywgYWx0ZXJpbmcsIG9yIGRp c2Nsb3NpbmcgdGhlIGNvbnRlbnRzIG9mIHRoaXMgbWVzc2FnZS4gQXJpY2VudCBhY2NlcHRzIG5v IHJlc3BvbnNpYmlsaXR5IGZvciAKbG9zcyBvciBkYW1hZ2UgYXJpc2luZyBmcm9tIHRoZSB1c2Ug b2YgdGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkIGJ5IHRoaXMgZW1haWwgaW5jbHVkaW5nIGRh bWFnZSBmcm9tIHZpcnVzLiIKPC9wcmU+PC9mb250PjwvdGQ+PC90cj48L3RhYmxlPg== --=_alternative 00304AB76525726B_=-- --===============1286520249== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1286520249==-- From jaymelorrie@netservicesplc.com Mon Jan 22 04:05:08 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8v6y-0007Bu-Ru for sip-archive@lists.ietf.org; Mon, 22 Jan 2007 04:05:08 -0500 Received: from n19z179l253.broadband.ctm.net ([202.175.179.253] helo=Vergil) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H8v6x-0001Pv-2j for sip-archive@lists.ietf.org; Mon, 22 Jan 2007 04:05:08 -0500 To: "ketti mycah" Date: Mon, 22 Jan 2007 17:05:16 +0800 From: "alfons daisy" Sender: "alfons daisy" Subject: Hi MIME-Version: 1.0 Message-ID: <080f01c73e04$6f34c8b0$ba01a8c0@Vergil> Content-Type: multipart/alternative; boundary="----=_NextPart_000_0103_01C73E47.44479310" X-Mailer: Microsoft Outlook Express 6.00.2900.2527 Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d This is a multi-part message in MIME format. ------=_NextPart_000_0103_01C73E47.44479310 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit Manzilla! Size does matter! You seen this on TV! http://kolonkasad.com/ex/ hospital light ------=_NextPart_000_0103_01C73E47.44479310 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: 7bit Manzilla! Size does matter! You seen this on TV!
http://kolonkasad.com/ex/
hospital light ------=_NextPart_000_0103_01C73E47.44479310-- From sip-bounces@ietf.org Mon Jan 22 05:34:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8wU1-0005uT-TU; Mon, 22 Jan 2007 05:33:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8wU0-0005rY-JL for sip@ietf.org; Mon, 22 Jan 2007 05:33:00 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H8wTz-0007zq-8j for sip@ietf.org; Mon, 22 Jan 2007 05:33:00 -0500 X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-10.tower-153.messagelabs.com!1169461976!361179!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 10577 invoked from network); 22 Jan 2007 10:32:56 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-153.messagelabs.com with SMTP; 22 Jan 2007 10:32:56 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0MAWtoY001778 for ; Mon, 22 Jan 2007 03:32:55 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l0MAWrsO012118 for ; Mon, 22 Jan 2007 04:32:54 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] To find size of a SIP message Date: Mon, 22 Jan 2007 18:32:51 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B03D4F497@ZMY16EXM66.ds.mot.com> In-reply-to: <200701191803.l0JI3CTu012436@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] To find size of a SIP message Thread-Index: Acc79Ey/msEVHzrAQ7ynqclJTRqPuACHA12A X-Priority: 1 Priority: Urgent Importance: high References: <164841.78915.qm@web52908.mail.yahoo.com> <200701191803.l0JI3CTu012436@dragon.ariadne.com> From: "Avasarala Ranjit-A20990" To: , X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Content length gives only size of the SIP message body like size of SDP body, but not size of entire SIP message. May be u could calculate the size of SIP message from UDP/TCP packet level=20 Regards Ranjit -----Original Message----- From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]=20 Sent: Friday, January 19, 2007 11:33 PM To: sip@ietf.org Subject: Re: [Sip] To find size of a SIP message From: Raj I want to find a size of a SIP message. Can anyone help me to find out the size of a SIP message? See sections 7.4, 18.3, and 20.14 of RFC 3261. Or just search for "Content-Length" in the RFC. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 22 11:00:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H91Zp-0004kL-FD; Mon, 22 Jan 2007 10:59:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H91Zn-0004kG-Fm for sip@ietf.org; Mon, 22 Jan 2007 10:59:19 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H91Zk-0007lf-MY for sip@ietf.org; Mon, 22 Jan 2007 10:59:19 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 22 Jan 2007 10:59:16 -0500 X-IronPort-AV: i="4.13,221,1167627600"; d="scan'208"; a="112217005:sNHT47703540" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0MFxGBs025239; Mon, 22 Jan 2007 10:59:16 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0MFxAVh001841; Mon, 22 Jan 2007 10:59:16 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Jan 2007 10:59:11 -0500 Received: from [161.44.174.190] ([161.44.174.190]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Jan 2007 10:59:11 -0500 Message-ID: <45B4DF4E.20508@cisco.com> Date: Mon, 22 Jan 2007 10:59:10 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Avasarala Ranjit-A20990 Subject: Re: [Sip] To find size of a SIP message References: <164841.78915.qm@web52908.mail.yahoo.com> <200701191803.l0JI3CTu012436@dragon.ariadne.com> <750BBC72E178114F9DC4872EBFF29A5B03D4F497@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B03D4F497@ZMY16EXM66.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jan 2007 15:59:11.0086 (UTC) FILETIME=[417B90E0:01C73E3E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2208; t=1169481556; x=1170345556; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20To=20find=20size=20of=20a=20SIP=20message |Sender:=20 |To:=20Avasarala=20Ranjit-A20990=20; bh=6NpmXtscC9E9FNZskA81nHFNpnMNXo0eF49ewR+kJhg=; b=C43LWw3RlCTubySZSDrCA8U0l65wiFQ89OLOLLwIrUbRVuWsCLo5R7YWIP5DQV79796UUgYw 1TmB1naTVZOeG3HerAuxJqRKQftE8E6PMFQbLEnfLQ31tQA/BxcGMd+Y; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Come on guys - this is not rocket science! Starting with the first line of the message, you look until you find to determine the end of the headers for the message, after which the body will begin. Within those headers you look for the Content-Length header. It gives the size of the body. So that many more bytes are also part of the message. In the case of UDP, the message always starts at the beginning of a packet, and any extra bytes after the message are to be ignored. In the case of TCP, immediately after the message you should find the beginning of another message. There may be extra pairs that you should ignore between messages. Of course there are a variety of ways to optimize this processing and make it more robust. Paul Avasarala Ranjit-A20990 wrote: > Hi > > Content length gives only size of the SIP message body like size of SDP > body, but not size of entire SIP message. May be u could calculate the > size of SIP message from UDP/TCP packet level > > > Regards > Ranjit > > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > Sent: Friday, January 19, 2007 11:33 PM > To: sip@ietf.org > Subject: Re: [Sip] To find size of a SIP message > > > From: Raj > > I want to find a size of a SIP message. Can anyone help me to find > out the size of a SIP message? > > See sections 7.4, 18.3, and 20.14 of RFC 3261. Or just search for > "Content-Length" in the RFC. > > Dale > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 22 16:20:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H96ZS-0001xO-RO; Mon, 22 Jan 2007 16:19:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H96ZR-0001xB-Nb for sip@ietf.org; Mon, 22 Jan 2007 16:19:17 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H96ZK-00017S-NA for sip@ietf.org; Mon, 22 Jan 2007 16:19:17 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCA00B2CGI50X@usaga01-in.huawei.com> for sip@ietf.org; Mon, 22 Jan 2007 13:18:06 -0800 (PST) Received: from huawei.com ([172.18.4.47]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCA00F4MGI5CP@usaga01-in.huawei.com> for sip@ietf.org; Mon, 22 Jan 2007 13:18:05 -0800 (PST) Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by usaml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCA00F8YH08HF@usaml03-in.huawei.com> for sip@ietf.org; Mon, 22 Jan 2007 13:28:59 -0800 (PST) Date: Mon, 22 Jan 2007 14:17:31 -0600 From: Spencer Dawkins Subject: Re: [Sip] Comments on draft-ietf-sip-outbound-07 To: sip@ietf.org Message-id: <051101c73e6a$d045cf80$6501a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <45B4756A.3000000@db.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Alfred, > > 4.4. Detecting Flow Failure > > > > The time between keepalive requests when using UDP-based transports > > SHOULD be a random number between 24 and 29 seconds while for TCP- > > based transports it SHOULD be a random number between 95 and 120 > > seconds. > > perhaps a silly questions, but should this interval change for each > keepalive request? I.e. should the UA re-calculate a new random value > for each keepalive request, or should it only calculate it once and > then re-use the same value for all subsequent keepalive requests. > > in any case this is implementation specific but might be clarified. The reason we introduce these randomized delays is typically to prevent synchronization effects causing/resulting from high congestion. It is certainly possible to re-caculate the random value for each keepalive request, but do people think this is necessary? Thanks, Spencer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From ordoneziahine@mth.nakayama-miho.net Tue Jan 23 02:36:15 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9GCV-0003yl-A6; Tue, 23 Jan 2007 02:36:15 -0500 Received: from [221.168.73.185] (helo=mth.nakayama-miho.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1H9GCR-0003Y7-Sa; Tue, 23 Jan 2007 02:36:15 -0500 Message-ID: From: "Tamika Smith" To: "Laurette Berry" Cc: "Jocelyn Boyd" , "Antonietta" , "Patricia" , "Elda" , "Gertrud" , "Sondra Russell" , "Gertha Reynolds" , "Matilde" Subject: Busy Date: Tue, 23 Jan 2007 05:33:38 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_36C_A8E3_D0B4227A.F607BE68" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.7 (/) X-Scan-Signature: dadeebe491e67c033a493fd3c7d6792b This is a multi-part message in MIME format. ------=_NextPart_36C_A8E3_D0B4227A.F607BE68 Content-Type: multipart/alternative; boundary="----=_NextPart_BD4_BE2D_A207E651.FD0548CC" ------=_NextPart_BD4_BE2D_A207E651.FD0548CC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hearing carriage The anxiety in ran which, for three learning days, Londo= n socie harass night =60Do not glove let the fires go down,' heart replie= d Mr Fogg. =60 saw comfort The distance vesical between Fort Kearney regr= et and Omaha, as thallow spread unit Towards press noon Phileas Fogg, hav= ing ascertained thei paste =60Why thrive not?' returned fly the pilot. elated =60The San Franc= isco The train tie entered the State grieving list of wove Nevada thro= ugh the music relieved From this point sea the through road, running al= ong Humboldt R shiny belong =60You are branch claim sure of that?' A injure great crowd was screw collected in Pall brake Mail payment and t= he nIn concerned a lupine few moments, with cries and agree oaths, gentle= a bomb appchew What coil consider thank a journey! The travellers, huddl= ed close togearmy =60Where jealous are we?' milk average he repeated, wit= h purple face. =60Se =60Perfectly.' boiling Having forbade breakfasted, Mr vivacious Fogg sca= ry and his companions res level wash This happened, indeed, to the sur= round agree train in which Mr Fo   judge =60And when does parturient shock the slung boat leave Shanghai?' = tired The five obtain shoot tease antagonists of Phileas Fogg had met in = th=60Pirate!' cried sip form Captain Speedy. =60I distinct have chain sen= t for yhematic quality =60If nothing breaks,' multiply said Mudge, grew =60= we shall get the=60Pickaroon!' respect =60On digestion the 11th, at seven in silent the station evening.= We have, th fraternal The travellers gazed on decide authority this s= hyly curious spectacle fro curve Passepartout was furious at memorise th= e loudly value delay they occasio band line spoil =60And mountain you could go--' Mr, representative Fo= gg had made plan it flung for Mudge's pocket interest to reach When the division rat clock tongue indicated naughty twenty minutes past = eight=60 - Sir,' continued Mr Fogg, =60to ask war stunk flash support you= to sell mThe stitch prairie, across turn invention death which the sledg= e was moving inticket =60No! By afraid all insect bread the devils, no!' = =60In frantic an mine hour; as wool impulse soon as provisions could be g= ot ab ask outgoing =60What a watch country!' distinct cried he. =60Mere = cattle stop the x-ray check tall The engineer did not try film to overc= ome the obstacle, =60What time did rail the employ last poor train tray arrive from Liverpo= o=60But fall I vesical shall overtook be matter obliged to burn her.'But = the breeze, far avian from explode lessening modern trouble its force, bl= ew=60Burn the "Henrietta"!' =60It is helpless a cloth bargain. Are too you the letter master of the b= oat?'The best shod course property stomach was apple to wait patiently, a= nd regain It was eight o'clock when the expert brought epithetic cow tra= in passed through =60Yes; John shaven gluteal carriage shock Bunsby, master of the "Tankade= re".' existence stretch =60At blind twenty-three extend minutes past seven,' re= plied Gaut=60Yes; at healthy least the upper part of expert fly well her.= The coal hasstrung sister =60These chords give the fifth branch and sit = the octave,' said=60Burn my knelt vessel!' punishment cried stupid leg Ca= ptain Speedy, who could =60Would graceful gotten rob you news like some earnest-money?' rhythm Du= ring the night crush short of the taught 5th of December, the train s= wung Passepartout, about nine enjoy cheese o'clock, went stone out upon t= h   =60If feather it would not page box put sign your honour out--'=60Here ar= e hover sixty burn thousand,' cast multiply replied Phileas Fogg, h ------=_NextPart_BD4_BE2D_A207E651.FD0548CC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


hearing carriage The anxiety in ran which, for three learning days, L= ondon socie harass night =60Do not glove let the fires go down,' hea= rt replied Mr Fogg. =60 saw comfort The distance vesical between For= t Kearney regret and Omaha, as thallow spread unit Towards press noon Phi= leas Fogg, having ascertained thei 
paste =60Why thrive not?' returned fly the pilot. elated =60The San Franc= isco    The train tie entered the State grieving list= of wove Nevada through the   music relieved From this poi= nt sea the through road, running along Humboldt R   
shiny belong =60You are branch claim sure of that?'   &nbs= p; 

A injure great crowd was screw collected in Pall brake Mail payment a= nd the nIn concerned a lupine few moments, with cries and agree oaths, ge= ntle a bomb appchew What coil consider thank a journey! The travellers, h= uddled close togearmy =60Where jealous are we?' milk average he repeated,= with purple face. =60Se 
=60Perfectly.'  boiling Having forbade breakfasted, Mr vivaciou= s Fogg scary and his companions res    level wash Thi= s happened, indeed, to the surround agree train in which Mr Fo  = ;  
judge =60And when does parturient shock the slung boat leave Shanghai?'&n= bsp;  
tired The five obtain shoot tease antagonists of Phileas Fogg had met= in th=60Pirate!' cried sip form Captain Speedy. =60I distinct have chain= sent for yhematic quality =60If nothing breaks,' multiply said Mudge, gr= ew =60we shall get the=60Pickaroon!'      &= nbsp; 
respect =60On digestion the 11th, at seven in silent the station evening.= We have, th    fraternal The travellers gazed on dec= ide authority this shyly curious spectacle fro  curve Passepart= out was furious at memorise the loudly value delay they occasio &nbs= p;  
band line spoil =60And mountain you could go--'    &n= bsp;Mr, representative Fogg had made plan it flung for Mudge's pocket int= erest to reach     When the division rat clock tongue indicated naughty twenty minutes past = eight=60 - Sir,' continued Mr Fogg, =60to ask war stunk flash support you= to sell mThe stitch prairie, across turn invention death which the sledg= e was moving inticket =60No! By afraid all insect bread the devils, no!'&= nbsp; 
=60In frantic an mine hour; as wool impulse soon as provisions could be g= ot ab  ask outgoing =60What a watch country!' distinct cried he= =60Mere cattle stop the   x-ray check tall The engineer = did not try film to overcome the obstacle,   
=60What time did rail the employ last poor train tray arrive from Liverpo= o=60But fall I vesical shall overtook be matter obliged to burn her.'But = the breeze, far avian from explode lessening modern trouble its force, bl= ew=60Burn the "Henrietta"!'       &nbs= p;
=60It is helpless a cloth bargain. Are too you the letter master of the b= oat?'The best shod course property stomach was apple to wait patiently, a= nd regain  It was eight o'clock when the expert brought epithet= ic cow train passed through    
=60Yes; John shaven gluteal carriage shock Bunsby, master of the "Tankade= re".'    
existence stretch =60At blind twenty-three extend minutes past seven,= ' replied Gaut=60Yes; at healthy least the upper part of expert fly well = her. The coal hasstrung sister =60These chords give the fifth branch and = sit the octave,' said=60Burn my knelt vessel!' punishment cried stupid le= g Captain Speedy, who could      =60Would graceful gotten rob you news like some earnest-money?' rhyt= hm During the night crush short of the taught 5th of December, the train&= nbsp;    swung Passepartout, about nine enjoy cheese = o'clock, went stone out upon th       =    
=60If feather it would not page box put sign your honour out--'=60Here ar= e hover sixty burn thousand,' cast multiply replied Phileas Fogg, h =             
------=_NextPart_BD4_BE2D_A207E651.FD0548CC-- ------=_NextPart_36C_A8E3_D0B4227A.F607BE68 Content-Type: image/gif; name="cordakok.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhZgFsAeMAAP///9PW07fO2KCkpQUYHcl+dYV+dRxIba+6vFNTU0dxm3EAAKIdCbdKR8yh lti8tCwAAAAAZgFsAQAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6n9CodEpFBa7YwOkq6Ao2V0BgUK0SyLWChcBuG9aEkqBNONQMiFuA3gYRtBN7fH8ZbAAI hGVSdTUJcRR7ZFoDBHkqBnVagoAxZ3oEXyOUnGIEbxOGGIyKZgoXYWCBpGKcB6CQlRSpWBW8E12z pWiokoGhhwgIgAECyRIIA84Azcl5BXWW0MNiA9Epe8cUBgkJBoAI5GhsB6QECRRzlpjuEvQDeAbH CXmI7prkpsZNOLCN1Qx6Fei8cyTB0RdEyehootOtTTtL9fYNqkeHYx8K/gxfmWpIaF2qQe7Y5OED kGA/BWy0IDrg6N2WW7jOOIpDSeMfSgo47bGJ6h2mZvQO2KEkwNazM4gGBHB0RWW/iY8MboGliihH mZUQaVEJwBEmS05TKSCDqZc7aP1K2QFgiBK/BHvmxtOVdZwBqZEkUBJDlJHTacNGphpMiKoEpYGF aZhKLpgEQRKnTYDZNOvEWQhRHUAUas4AhogOlbSDcGhk1wnmajXRL9UFAq4CecpIlwybNwGh9hPg SNmEkLppKg2qOhQj23INjINue4ACmOx2j7qMANO7w5cHXHO1ag7dL2x2/q7DJwNm6LiCeplw2lYc QQQlzCGVN6EC9W0M/uCUWHustBIf+SRCV3ayzTZCXkqF5h88OAHgFE09nfETbrF1IwFMbJCB3GW5 VCAWR3RlJQxcxh2nYj3AoTFYiuzZcdgc670zkmp0HegFWIBxdYF3ABVEYjil1GFdVrWpxt8qqEQ0 y4CNaVhPQeAUZeGLDoIwU4RcXolLYnH0c2AcI1pAVVu4YDQBafWwpmKB7pUommmCxYEJIPTEhuJj OuaWWi7gkeimBkQ6YmQph8YkwZ644KEgby6WIpSFdpw4x2FQToSRAQc0tWiXHUBoi1e6FGQLkEl+ 4YgrmJyyAGs2jbKdbkZeY0ldnjDlEACYFBQrWJ4YgiOwhGDC2lyp/jiy7FN0vUMJO8fakkewdYJp WWS/nIEZArZItadruoWFzm7hXmUIpCmiYSZVdA4EJakizOPobXzkYR+UjlIiIx38ADzNvZKZWGKz bTCb8AWUtMFckh/RYcscNmEW4R6nmAfiwBZ9GOAGtSGp26EANJzAaZOsA4i/IKnHjjhK4XWIJLkd csplse3TECkR0ltCAAiIDEkWQgnZSy+WHe3z0jYoRTLTUEcttQc7TW311VgjnXTWXHft9ddghy32 2GSXbfbZaKet9tpst+3223DHLffcdNdt991456333nz37fffgAcu+OCEF2744YjvsLUKiydedgAM RM7AAgswAEID/pTPgrnlJjQQuQMaeF55DA0QoIbjbi/QwAQNgP4B5qdfNjoKkYf+yAMtBIC7GAU0 jvrYqhsjwQPbUlDA5Jx4zvllDvAnxgSuV1B7BdF7vjsADsT+PADXi+G6A7s/UED4k3c/QQHan+/7 70yP7gDnkBewwOmei06B+Ays7r3nrLfOgOuRw5zuGuC5WUyvAASUn+UeEMAr/M8BC8DdAyr3OQgi UHXHWwDoCgBB0CnPgQvQwvsCgDkJYI6AlGOf1ypHwgWIYX7cI8AG8yek5l1DApYrIfYIcQ0tRA53 AZifAwigvwlM74QAkB/uBAiAyUkghUFswO4y10QXRlF2q2Pg/umQF8TTBU9+ajie+VQ4teAlcYe7 q50WLeA6IeLOiQDgH/ZCWEUJHK95Y5xeF7kXwTi6EACzO94VzOjHJ3IOhsfLH/cYcLrjvXB3JWQg 7sRIxqwREo04XCADxui6zWUykyKkIxythwE9wnCCWtBhCpP4Rw2yrpWHbJ4Hs8hIO1ouiJ10oSST yID1VXI2VwwEDAEJuvdFT32P/CQfl/hHOF6ReJCY3gTD6EomwlGNhEQeIHVpOgc0L3KD1B/m3mjF PoLRj8f8JdOCSLljXkN5T6Qi6wjQTBNSjnMn7CMEZ4e5S1YRhpMb3+RQaMYAci6DoJvgJhm4yfc1 4HgoTKUQ/huQADVE8aF2rGgAClBRdXr0oyANqUhHStKSmvSkKJXBAwj40Ac49HoO9ZzrppnSmpJA efqTXBEhKFMJOOBpL0ifDsDn0uylUw/0G+PwjiqDeN2AgWJDIAHtSMDlxbGqmrCBDnsAwf/pLqA5 kB83/1iB0hWxBg8wHQ72GVWWUlWOw8sfAZXqgpXScDKQeMFUjUhHFUBVAzy9DAaU2IHWVcGfr/Cl kIz2uqmuFKMb3SgBr+DWJG40f8STKw41V1mdVgCimyzr5wK4xFqasHUMrN7n7sjLuQZjpS6VYiZb R8qVOkCKEAzB9OKqP8iF1gLEo6QYJvc9yqUPcjCEXG+X/jHQZSaxAUnbnEvRxz3DFvW3rQUuIKar yEDctZfYC6BP/8fL0sqPE/mDqC1Zi8Dp/Y+hWvgj+oZ5W/I6FI4bgCcgFak7XoI3cn/EXVffOL2j slSKEFUqS63q32/W7n3DNC4DzSi/h4rOgXulHuVcSLnSWhiDqpswAnXL4AW8A5U0FSaIFxjBIGoS vMIknhVrCdYgvlF3fRzmBTAHwFbGkQCMhKMGJ1hEdr6RiCslKw7puLrSxXOOahhnFalrxP9dI8oh LuR+scdMHM5xeKzc6B8YKMX1kXmJkw1EAp9r2MtELozWm0WUWSrZNn82f919K/Hcetu9zrXP+oOo N9Wo/lkLiLeJmGWpSzcJxhbSVQO7fSLo+NlXe+IQugcU5VkRfb9aQrC0FLAgdi8wREDw+AG4Y0Mx CeBSDRrzfvo0Z6VjeNs35rScaoCgRC0QvD2e15Am5JwH/6c/haYRt6BTLgjkiupCn7Z1JCRlsB8a bTtT4MDD9ZxQSYjn67V3z1N1aCNRW9lEHpPMm84255hNZ+9KEa7Ltqr8nni6T1+7meOjMB11/MKz rnGEgDzrfYUaagVN7o97yDWqc0vqWHdZevztbglx+WUtU2B2iExEIEVpZbiSkNXx6zTBM9DeVEb6 feTF6gQYOuy+5lmqOa3sZQAh1+UluNrYWzPLlas//oee29kW5Pa6adhu5nmTqYU9KxGfGOhZ67CW csztHi8O4+Em9L9VN6b8XDe+zyoIdiTaoAsJu73hxXrXFZhgj3F4H1cSdqsT6DUde/hkTgd8jq4D BEfjCF4gmtYDLrYjv6uoBYVKj44TlK9xp51TPPeOd+fDMz4b6tvVoTyLlQMfaVn593hybsIhRG58 Of5b5WYPfb48XzvxF7shgs+VF5chO3EsxQjze4iqy0PpIsgAIMcw800kovxkD59r6JisUST7AuhZ dUAuvfe9XD6DIbeMyjFxDxS0vvQrcM8+BpGesstfX2HfVx6TN/EL0H2HQTBMG4s27ulzpKTj/vnJ /hF3kYsPZngB3Lt+ah6coCNxqvNVoZVIx6VtcRU9HJQ9bvY5fCU55QMCROVNj0cBCOBNY4Rqhfc8 RXU9LmU+qHY6ukM0l+FSM6cJ0MRw9wNNXiY7vUMKGog0eUULvXBc/KFYjaNYJfVYC8ZgUDNrSGNV KbYCt5V6NjUD5uNNV7M4FFdlfcQ4MnSEQtBfUliFVniFWJiFWriFXNiFXviFYAg3RhiGZFiGJkU0 aJiGariGbNiGbogFXhCHP8IMcliHdkgN1ZCHeriH1dANfviHgBiIgjiIhFiIhmgd15GIiriIjNiI jpiISrEcj6gAkViJazEaJFKJmriJnNiJnviJ/qAYiqK4iZQ4iqM4iaiYiqo4idOCiGtxiLAYi7DI h7RYDchQi3l4h7q4i7zYi764i2gILscQAA0Shg+zhQFQM2JQjGAYKl1IjJDAjF/ojFwIjYEgjV5I jcjYINZYhtqohd24jCDgCyn1jRhAjiQVjuE4GUVTjkIzPKgWj/E4hoejjtg4NIl1UuZYgvLYj/JI j4ITjk0xGQLQhgVZUvuoOwvnjwzJgh2QM+YwGTgBkFhjjxnQDL8oFXbDDDCwj/FIVA3ZgfIIBpUw Bp7gJ7dhB3tAkVZjkQwTDdrwhzH5h8eoAbZYMtJABOTgFuEAKlZAMFVjMG5SKBZgjkDzgQ0J/pL9 CD4agJIpsgFO2TYuWQHW0Q3X4YpWuYgIcB0cgB+PkQu7IRg+kBq6sRfkoABkSQLEsSRfsABSkZZO cjADYB4YYJQLyZBKiYEfWScY0QwBgAckgRM0UTIZQxY2EDSyoAISgpEMUwHNYAFTSQFX2YhZqYiI 6DvxYo0sCQOekRU/YRN0KQonsys1kxWh+QfloB9hYiFIEo8ctHCvmT3TJZsfOXKMAgdlYQchYQ8l wSM0gBlkYCZbsBNz0TB24hFvkh69wI3S2BSTeZVVmYhVeZkdkArOMAYTgC2PcgZ4gAUycw03swJM khX7kADHgJoUUzJhmSJwqRpoIBTjORDg/sIJq2mUR4c++BmCr4k+C5c9OnOOx7mdYhAUu6mSf4Ax 3fGbieAOzAJUHnAGMPmXj7AHZTkwpdAQXhGZFngAa/GKlUmT1/GOFnAicwEnJZkL5bAJQBEgQ9EC 8fkY3YERf8AIUdEb9TAWXEIJ4UmhyTkQxHGedSky/Hl6R3d0H3l65eCg9VAzFDoj5fkIO8mjJwMf L+ANf3KhHEkI7XkyJRONOMGkfeGZAiKjQtEgA4kBArCKa2GE3iIbt1ASvrES77CSj+Iq90gCnXkc 6HCePEqWXGonXPIX6KCapDAjvaEg9SkyG/WaRVWk+Ckd3dkBEFEP6DGjbPEIhgARTsGj/jbAUYlA oTMhIB3imQowD24xKT1CH1kxGv9JF9EID8rIMKg4l/XiD6ggE2vhCVHxnp/6FxKSAnl6o+AiGHjx CGSZH5SomkPjDW8KmYQAqo/gkxewj2JgAPh5reiDAAUQDWPYD5i4ICYpKcpQBwLgL91xABFpA37y qXFAlzBBqTaqnmqyKsRAAYY6GtqoIEiSpmAADY7IrSIgCLowrmJCDi0yqXShBUSJAnNSCV9aUZia J0tKrOeCC0pxGs6CDnM6p6aQCN5xj9RqM+QwsuQgqCyZNOvDWDEgEAkLLceqDmMBCKE5EGNxo1Tp mejAq/BgprEKmf5KmS0yjtRBsDZq/rDncDAKu5ol0LBwAgD/cUOuKq90kRunUbHJQRAtobGEUQrs 8rEZELLdQbIja7I/c46lspkhwLKJkBova7OJMLOPUbMta684y6UX+gs8e45E87NXqQxZEAJhOROI sA+rAiAmiamVwBksEJ6WAjP0wR3PMAncYLe6kB9jgIhokBtTQQrQoAEhewV8iIZMI62WQqczghC3 sJICexzjsBICsijregonSgpnqh89SwtpOId/i7YWKFi5sB8WEAq8GwP+QrkgcbspQK1vKLpdcg0d sQkSayHqILwxU4z2MhXtQZba+RWO2SBbuQTFka5TADTvqLLJq6h/S4NuWDYlSbqp/sICtTsNyEsE QKMEQVsEIas3ynkBNYkC8cuveCMAjDsE+SuF8cuVZljARxi/35vAIjo2d0oEDDy/XNi/WAjAtgsD y7vBHNzBb/iLdYiLIjyTgJiHsiggHnrCsKimkFiKpvjCMCyKKDHDNFzDNkzDEdKXdRDDPNzDPZyI TuvCLDzEKazCRuyHI5wMooKHIgzCTvzEUFyQHjzFU/wCGDwzZui0w6tOyWiBo9KFCmxTDPzFYqik PhDGNTXBWYzGKTXGa/zAiWlSbvw2wTC880KDjsmRJ7g1n3t62KqXJZAM5vsmqQcNj4kMXYCYRXC/ /uu9ZOwCbXAtjmLGIgAg6tke/oXwIutQLpS8AfNQMZEMEm3AsaE8rUIjPgtYpKpMVKm3B5ToKKjK vQswwCBBEDHhyukRoB7QMHGHKiRwFajwqyETmC8Svx7yCW7KDxRcybmRFujRBbGsC+87GDy6niGQ AGipxGTJqWxyqEBqypCJPqt8n/cpzg5ZCKGgKQCqCVtjqKDwFxbyBkpRq9DwBwTxriZgAP/hGN6C z05SFX+JF0CjIsb8yB/gS91My4tVxzO3BkRRrG6rpFkBtT1SIQdaFl+wufYanJBQHDuDCiDhF8Dx zUUpMuN80qqcnxlgqOehGXZUIsCLEUxhgTuSBzbBCFNxzZ5ZImkCuPcwETor/hiyMRqIygkFbbaQ KViQYNAkEpzqcNO2cAr2khJXUQD2UQHzkK580slZ4c4/eqshUg4aAgiKQqUEIyYD4Yek7DRBWoPl 7KgLmMopTVd3jCxjYZ4jUc0LETSTkjBuUteAxxe6cQhT6ht2giMs7bQlwgksrR4iEiQE3SDHfAGM fI7iywF1YQkM4SepUc0HAheYWhC14RW6fBuqGiXmCdZgUbAlmqNscJ7b4M6SYJJf25oPlT0PJc4I xEHYKtcYlZLOGrML0ri40RvrSBghIho3cSIWWqMT07KdTaXhYjwq4tU0MilHnQGKfI7dYISDOwxQ ezK7qa1QShR+eJzHgLCp/orZp02piz2jQl0PBgLSWL0SY3Eosn2rtW0Bua3b6HNgvY2fDJCaQ6Ii qa2l11HcdJofxskJrQoevxoCdGqaZfII+dGyFL4GYSugkummw9Ce2e0elT0G+TAChoks1Sq1UFGv N+pUTgWoXB3SZXHTMcujpzu99WCv5eAbpzHAp5kHWbLfdxbgRC5VI6uRInEK1SzcNPqmxToWN3Mv xZ0kP5MI6MobN+62aDAiyiAzf0AcFtDN2sElIT4Zfgu6VjoC7MKejMDPHfPadh0XJGIKUyEbO+E7 L/IqfDER0RuWOfMixinA7WEetbErZpyQb1bkVSU5FVXZjlkHjuEdgiAg/pWgKP1A6fCcnenBoS5i zR6AIzmLKQixm7khmGJd3eswHe7gHdPQO+4AEFe6sxsNeNAgHUhOAvX7JkDO4DWeCTl5GikeCMji JsCQA96S2JTiAsq7OQdWVWI7l949KpawNbk+oltM2PUxF5Sb6y2y5dVaIZmYB+V6D2vBDQM62aNS 5kZAp6lNBVfNMJ08AvmLcoxODg/l6GRTE+COCnAcAupuBMA8NwUMutUgxdfONH6J1Cvw79PY72ks 2UyNhWyMUgy/AhFcOC9TjZId71c48S9AxSAf8lQcxXGYxLmIwE/hiizswyzviQmjiTcc8zI/8zRf 8zgciTaf8zp/8zi//g4t//NA78Icqqava68KQPJIX4civ/Rp2CVH34VXnOZk6PEm1cCCEfEd7/Ap ZfUlg/VWSPXCDlJcP9mT8ZEPgO8hBfYN/VFRb8Zm71IIsJD6qPV6G7C+bJMH7zNjT8Yh2Y8m5fFG M8gYoN6vwKt5P46HTxc3g+83qR8kM/YOmpT+6PWOM/FjQDJ6TDURTreBrTQ/mdwrQIz7S6XXXSu/ YSLKKPWQcK0DsJTSEY/xXg4yM7K3QfksoLQvwLJdKQJsPAbviPaOydd8UhH3ESISOjBG8QdN0hum egLMHc14asgayanHURgRASMWmPpAJT6QagAgyVHSEfcPcNkZ4Czb/vk0nGL7JwAfrN4C/RDlZ10W tiEISsrGVmo0OenJ44oGE0Mnq3AiEEAMSCMQAAiiRFwhE0eyFI0wI4IycDFgSMiE40TkWMWrPGYV Ygfo4RSjwY0UKDgcKUSzUMsEHo+C0jQiDDICr0m4JZfNpmLGcKAAz2/AGjFIXljpdgy225APKTOX LRYEwLKLhAQCmIE9DomqHQMMoKRGjsYguLcEtpLJA4XEUBiNxMUl1MiWRYIKDRaVEYQjEQUtESyH LJzEMIAHh+AJThheAKGujLEAIEiBnZrLC89NstIxld8ShFhcwdivn5s/EezSLmXZrXLrrcK3gDAh QkeN3yGCg7CE/gAhTHvutujbkgmADhUs+nQooW8HnhECoCmMhYcWElwZdO2qmCiWLixuAvUBMgkZ IwwXvCDU8GjFJAH/BJooZfAeK0UrdJxzVSqSTzXVsh3MoQToiHYzBSHLyI3gyRWKPixCNMCAECCK WDQKAG2Gom6qZo5IUMuEAWc3Up5rSGQtGQNhFkKbZRbALRMbCxTAceMBgya7RJpxRafKjGwGlWUj uUfbWBJsHzf0IiQEgSPZTJJoNIQhjlIHEFBZZyLpGRepUy8zVDDUskRzEsR8dcHGKyK/dPj7Y7Wr gm1j0ZZRNHkHXWpcBpR7S9ONHTt1R+AtsdEB6RF7nQjelAxQ/lyDjAFq2hwQcmmbkFItg7GvpblP XmB0IjE0nVE/rQch4N+/GxFk9DtvQAIzyKmVszxRZwhEEqGhlTt8Mom+ES7wbBm7qCPhgQT22quf EXbR7jpi4BALFXoYSu6Cq1zRYAXLkiPQpz7oYiUDxbywcbNl5pAvicFUmCCT6NQxTUBuVFutrwKb dPI86BxsqCnILrKFSg+zvAKLBjzcRTRrDDALK6w64O+pS5YbTTQFusghyJmAQhANGMoDgprikGpF hlZQKWJOtxZiB8n6wmkBhScTVRQOC+E8yFACrcRhCw6znCKRDqf4EEQoF4UMUmQO4aGKhE4CVZ+K VCN11QrN/jitha6CmyUJT2u19dYyJL2LSgA0tfTXTnjFddgBLfTgLLsSfbW+/pRMLSZ4iJV22iZ1 1bC6BAz4NUtfqPW2QFCJXXYJfwqR6FzVPvh2XXbNsJbXB9DK1FJMsWv3XnzzY7RCQ8PN919c2bCW UBfmkLfebLtZCmCG71XA34YjlhgMJGStQjUfDQCvDlU3cfZjkEMWeWSSlTz3ZJRTVhllBaD172WY Y6ZjZpoHEGAfH2vWeWeaFQBuZ5+DFnpooosu+gCkk1Z6aaabdhrpPqOWemqqq456J6uv1gGQRrCm +mmosxa7T7DLNvtstNNW2mi223b7551DyZlnumO2G2aX/l9eeW+++/Yb5ZIDF1xwMeyiVWLEE/cD YsUbX5diWwh1fHJ8x6X8cmLfxXzzfC3n/PNENQd99Gk9J/30sURHffVFTWf9dXczFBZ22jdxvXaA LXhSddx7t+b2RRcmgwnGb+VRyAI740K9ESYxVCwRBpDd4+J9H/2A6hd9ijA5S7wVBHOWc3STsn7Y w+Yfmv8jnzmAkn662UW2/nXsvbWweptYHfbY9w4a/40NgMg2XyjFZuxAmvy970rDK5lAlrKk+bGr ftTKwUJsRgEODEcPzstN9NSBGP4V6FhpGINVLvGicGBlOQ9KQTh4xLwNMMgnCszAtfhVMsmxwhUW qkYE/t8xu/NM0EnCa8FK5iOBRlTARVxRDGKOoIxFLOcokOEfW05IleiMARo9VIGg4uCTbJljIquI 3i8E0DI0uOADz/qARLqiRmuoJAYWwxfzvkcVEeTEKduAnmmKdwdwhEOQFyvDJfD4Jy+YpADnu4ky EFKe7AEwBCTEwApvAgtKTsk9nzFHiWJYkRluA43cAIPN6FBKVNbhP5tIoiFGc4P/XEUEAsANf1yg Oyflr1Y5QEsfuuAPn9BDGZOw2YVIIMQ0gmxVgmScAQqmHntkojzyecQtZKlBY1IxBQvBTBzSso6F UGgZGpCFrthzTg1KCUcZ0o88SjmH/qwsWrbzjARk/qKDSZAEe1DsAgefNEVFyeBw3SyNjTRAS2IY 1AeR5AGk+gWx9KygSBMojmIU4kx1sAAhAxShUSYBBJYsKBZIhF5OtAW1uLxiDifJ00F0MBjDRK6I 5pIIf2JiM5Rd0BqLdAMfZlCkJ3IgTzqg44AAOogYsoGYyxsKe5J1EtCIYB9JOSoyR5U6f1nICzxU xD4WkYyutIID9/MKMb7atSbhMgObBEBMcBSLMFRmDa0Rgnt8pAC7hoGWnJFVTGvYTprxhw5zGywt criEM8EyW5D40xEC4NVqbO+fcXSREH7kFoUcJYmzCGZoRgOIqgpIXe6QR1E/5S8gsmsR/owMQ9/g /te7CIhug63ZUw+hID4o5Kd7eGIIkLaMRnivSUel0zkbiR8SxCUbTdVD+EIY2oLMlmdxce385pDV RMF2lEuAm876I73touarHUjHLaiiiJZF8atERQU+E0XcGzX3Jm0y7sUM4wGIqGCSGLCROH1AsLzd zabV9eG0tIukAPhstj6r7sIqMg8iVCR6XyAwZS38RRVUogss+YkETrHhnzpjNzhaBBePedgCo+7A w1uO0fZR4cmZVgxVSIG6JiAPMEVGGeWaGY5OYCi3lsGqKa7dioc3B6LVgchV6klT1Kko4C0ZdEaG 1cWcFWEYE/mN3xqylFlH5SUwKsteplaXyXw6/jCf2XdmVvOURYniNpOOzXHeXJrpDLs535lyK5Wp nq0h4389zM9GbZd2tzo4RCf6b4vum4DvNrOXSVfSk55021oM3repTdObLtvYPP1pUIc61FuLCKdN nTaXIu1tq2Z10Cj9ap45WsCMRtk+9tZWWi860bv+2KB9/WtgB1vYwyZ2sY19bGQnW9nLZnaznf1s aEdb2tOmdrWtfW1sZ1vb2+Z2t739bXCHW9zjJne5zX1udKdb3etmd7vd/W54B3vMn5u3srsSp38p CVa85ne//f1vgPM71wMneMFTxmdblRbWC5euxhz+cIgfDGESR1jFLX5xjFv81GkTdcc9/nGQ/odc 5CCv90hGfnKUp1zlKxe50lQeto+7vMQbpzmns5koakDNYgmeuaZ7XnOw6QPoNv/50I3O8aI7rRVN I9vRnf70pHVixAkXOqkLUmKpYS1pLM9a1D299ZO3CeujtprXuN4nvJ5d7WvvOtNLfoixw3JBn5Y5 f8nuEJCbPe1115rWla4OKfa9TUtbhNinBnO+j93wSwdO+w4P9i6yXfJ0N7uomXbzJ+Vc7zkOq58I 0ggvLH5Ok19ECBaP2c6k3C0z6MxO5jE1l9wd7XroEws+kAyxRV7tYCf919LucaW/fXhxlx7SgjN6 NkDDC53x2U4CFYrfN7/nYpce2gNvtRQM/j4SWGu8PgZfeDr0KQnJEA0tVOGn6++hC+MfLzAxIxGx 496muMdpmxxbQTz26Yz6gIYHznV+/7uZ98OMr5KIztgi0auayuu9s3M54UOqVogJ7OmMXzCWzOqV Y8Ei31qLSXosGNiKD8SsQCECgMA+uAKQHhijqQiBy+AAdcGiYmKDe1MMGKgg53uRt7oJYEqk5auJ DhogKkA/rLE9eViLI4gLZLixtWABEDESZQgjm8A9BpzCspu6WjGWM/E+w+KBPiECx/ICqYgDBXEL qMhAx8BBaHii5cOt0oO/CFQFIqkkDMin46BBqPJAPnCMNCQvvOsit2CDsngRRhirlEDC/vzDkRAY AzrEo7hokwnYL/ngAzLcooM4AuUJEKjqPyrcxKxzwDtyk8KrglUKFLHApUZgwW6Iw5MgtUNEw25a DMHSv0IwPDDADOXpgUzoGjNcCwxIkVI5P7c4Qqnxwws4gtfYCSb8MD2IRIXIMB1gg9TLvy4kMWYk pxQkiNcYvS6MRk7sRqiBmgekk6kSutQTJPFrK4KwkMvowh7AvXUEJ7u7rKupmiJkx16UQ2lUP3TM v3fsgWKkvWn0vCMIxHzKLASBBqHaA4MkCE0EQM9biYE8Q3t4Qml8xjLsRk70O8wboqrzGi7ioYek PRm8PQ5sKw/8AgzTgOSjSApryKmp/kV7RMcO3MWf+sN7SwZS8bw+wMO5sDtLHKFDai7LOggzXA3Q 88IIjLAxqKtKxCyq2CJBOMohjMoV4EaMZECPtEJPMRYdaBmJ0KFWWIPVupqZcYWd+BnX4xOzXIQD ORCNsQrLGzt9KAu5ZMsDEYWsVECyGRuzW0CW4wC/vErBBD6tDJ6xk5yl08vBXEzGlJqHaUzIHLWt C0dWCBsLCJmkAzvC68u9jEzP/EzQxEjKTIXQLE3TPE3U/LTRrBCoWxq8MrpWi81VYzjarE3bvE3c fDVZ203e7E1ZOzhAKxY14hvflBlII6zcTE7lXE7mbE7nfE7oxE1caQaaMjiVcZY1/go47dzOwIk3 evsf72wS7hxP8ixPZfqen+oG61xP9mxP93xP+NQ185xP+vy36fyp+sxP/dxP/uxP//xPIgoe/ARQ QCJQA9VPLDtQBe3P+0zQjiGVN+K3GyqYO3DQBlKV8ZzQREPBgCMXkekH8qSHBR1RfUNPCy2YZpGI Edq1mbkK1diAQrhMwQGDW/KR7USAg1EYRRMNEAU4tsQiZYIOROsV7HkBGa2HAiXRBW3QKzuQLqiB EDpRZVrErdKGuPjABiqPfdiGQIowKW1Ss8wxK7uyBM0Ng3igJREcPgEO+YmOIW0pxhIE5FDSJV3N ChnQ1SCot4qG2sjSamABefE//qzo0ZFJyWBJyLe4mRjA05ChgB4yFhGUAdoTKstKAgTpDLUove5M g84wKyySKAjJUomSIwhRvqWj0wNtUAftAHmxLA9YgzY5UvlJIkiYhLQDPVdwJsEhqaoAsaWkhJQg mS/akziQF67ogEv4hygyVQsAPdDrhAhtoDGCCRaBVlwFvcEByCgKFkWYBOdZEVT9T1XVt24dh3To DD1qoGd9BLnA1TEt1CRiA8zwmksgKpNoIKmwJUGsynT4DAlgrH4dVvV6iO6c1vZQhK06VyAV1dTY sFaA0s34rXAVVxO9stdwLtADAx0t1OPZMYV9V/n5KAz414eJCa9Ih+LA1x5S/gbk6Al/nQQX/FcD qcGRWtFCNVgVICpteAg/EdZ71YA2GaszMYiNmlgGNdFVRREjTQckZVhB6CaVYNohHTGzTFhgYsJR FdaUfYEJSJFj1QpljVnLKsKwsgAczdpC9VpQhMs1+Yf2IVT5SVkNuNLl8KrgIiaj9c9xVZVAdK7O Q1v5kcLY+ySwIpzReAyxQkdADVatlUFByAlPYIZhfYSYHUFMFcQkbVM3SAZ+wCLRCEXBQTjdSdfw A4svzdvyZFJnsaVC+I9AytyRAQ/qArhSigtemE+rCBpdLdFGTVM0DZyqcxEraygAAVmRkcLxIqQz Rd2jTbg7UZVFtFnYndWo/rmxfrvIHTPPZ0RGAK2XA9hd7sRRmnFRk9lY5t3PvS1R4901D7VPDSXP fdPb9uXO+D3fVEVa+81f/d1f/U1f/v1ffwBgAaZY513fAT5gBE5g9y3g01VgHCq44ozg3YzOV7OU iLtgDM5gDd5gjck4D/5gEG7QjwJhEi5hEz7hjGMbDs5gCs5NCY7g9nRgflHV8Kzhb2kG/alfB7bf 7MTOvjGZ+AxiIR5iRmNS891hXpvfRh0E8jw0+TFgJKZT/43iDW2GehmrRkXe2mvgNsVOx+01Yzmk EX1fGcZfKq7iqsFiMNUbsOJiOUWROFUNRgWH0ptFCHHjbN01/zhjO+WB/ucFYz7WNx6qmZxQY741 MVPYAGmVgO/9KAud4xeoBbEq3AfltyPWXKWRlQfFYyWd4tXo016DYhDk5MG5Ln8LFKtIBDHJFj7p QL6doYUUVil8xjmeYxx8kdHqPy+FFlntThHdVQ/oD32wigJAwoJxuNngNRw1ZfQ1Y31bql7DPevt tXul3384ZWjQGOBQhAowoex95eYpBSFVJvL7w9dwFkj+0W4wGAvQCjXqEy3w3S41LlE9kH2w518i yp0YxSUGB2TgEywbXlLuTmf+ZIQ9UQyMZCltrkJtKJL5ABcF310bZtyon9GoPkPG2mXopZ4K3BLj QvdA56RVQ4HdoZAS/i5VxpHYiAMBQIFekqVuKVT/Kt5Zag8uZUtkAJFXyAkXqIEKcLwJuGML3M4p ZojoxSL54qc+ID+T6NnVdYEr+JhRyBZVrp/ZBZk1siVnQSK8+gVeCr+MZogCCAF1GmdnyaeP/CqR 1jd8Imv+6daUDS6d7omu7QljaWl9aJFT6GVyLSDbKJFscFKyXgOAVslLwKtkaB9iwmu2Lb9Lvt6C tgIjqRCJ0tatgEuuAEGP6LWG/OIlES6yyOjUOBDYLQyxHKnvBetVLQ4qkDCzVpKupJNeZlSiBIvJ /j4Aqdv16Ym1gGuFNK6tVaaW0kSvbo8N8I0wfqwrlaN76IPgYsOB/hXlDY3sB8iodKnsRUJcsRqC zpjeCPlmjDlFq9AWjgGCHpbjP1USWwyjtlJp1e5rmganJR6CnAgDz+7ppO3BFdWDou0ke2I/SyVs zLKBaGBcaj6idFAFxigRlShC/p4Bjz1WkVWBL7S9hQW4os4EJw1VDFwrnW3u6Plc724rSGaCdW4W vCBYzr6DHg5GgTqJru3mnQRn+CAnTMLMCBE7WVhrk1lq4Y28j/nXOzgFA+lWt5A7jY7bD6yrfIYq lTTJAcoGqu0HVwXBzE4f23CBNqHfyAbUD5/hRdKY4/YwD2iTCigOmejdJV6CCmDxLv4YYpKBH0CL OU+iXssTrSqA/ggZGZ51cgPH7ytT8B2iJa/qsMVI3AMJLiLQRA4K7jsvBSWyJCeX2Ia9Y/p4gU8d ZUWPwKEm6i6vBydWkhzQgRsABRBBmqtwpjka6HQ5GRyjsSSuivF+OLh05U+uCc94bfUeqaR+ZClF Fbqck8x2I3XpitGKVgxl35kODn9EX/j99K14bAcTHgfzUlY/XukumSTaGDoQc4n+5B7CBcBVbxZ8 ifbwdTDekzW4Qbkd0zLNdlENMMECkj//X09ejUC+smTIlqCJooXG8+H9ZZCxmmke7QaOGj0IADG5 9n/T4ql5GAS+93wfGeTla1WxSqkhnGk3mfsOZS9NcwCNhwSW/viJD1Jm4uJA4M5QJ+iS3zW4XeAr vBN3z9ZOAZhwCVDS0k54b3lUhTMo+anxe+EW3pZfWWGjP3oMRmGlTwRaWnqnf3qoL2FRwDgFoDin XzV5aVB4emGuP2/mtWEtA884c3aRURmudzSGI3qkv+CotzgVz08j3rWV8eGUaYbUvHu8l7xlaGYG 1lts9Xr6ZHgIAvvNAPyPKXYJhfb5TPhZihmwbxxVMHx9G8rE7/sqltBjLZUKUavH95bqdHULoTBZ PsokjmzBJ5zMj4Or8gdZ6nxvkfzQh/Lj1QodnG7Lf5Ygd0FTwfx6AsF7TN4cdqBY8HnvHC2Hjn3Y fyUeUD46/uZwhHbmVbT294gQdw9oQhrezJdC4AAtLfCJezNJADKPYjmFWCgR0A6E8we2kWEJyW8f LMugQ1eYSdJX9Y15KxsF/ErCRu+lcolxTsl6CAgpmWDBIAEYgoaQaQDpkeXJEaWSummyAoTw2rcb f+MYyPgL8QMSi0bg46hcviSEJ3QTOMgElis2QeokEIHOAOBDpJxP7IWplpAuGRWGcKCGCLGDCGSf f+0KyVyFG8/OgALUiUkiVYvA2UBGgNBT2wGJ45aW1oxYhdYHx9eGzJBBy0yYo8+oh2MYQIzMAULF 02kJJcDsyqSimlGAQ0FDw8JCw28y0UYHlcYV1SXaFYLV/hNVQgaZxQhFwJtu25WyEpvYhhCHJcEp QSSAKw2sXUyHjNArVuS3iFWAVSIyiUDMckSmQw0733jJSGBpxqhRYjysiIGKh8QTBh4qWjXRiY8w /xAc8LHC40B4GihhQkWuybBixhjQpInsJc5LW86cm1JlmgUDsB6K2MaNlbuGlrDkXLaphkkojtq9 wyeLxgcLkyxk0DIomLOlA/AETCFjDKlXIzjBIEVGA4U/sxJMSSDAwAC6BgzQHSLC3QmPPjBYyjbv zL0hEEsMjkOC7MsHxhYQWGCTGGbMDCZz7sy5wOamZS7Q7elTGlC8J1VAvWJxYgcSFpmKvmGuhhAE 1eTM/oEtz2qJTYo6bJhxckMkR3Og5CohEAW8XSXUFlcce8bbsVMGVDjQBcEEfiWznVVn/uOzFW+y GYYoA1z16i3BtX/p4H6DmpYTZCb24D+AAQp4wQMM1CbOBdNEAw9Q36SjlVHj2HPGIWegcaANtwGQ jmyFRREVHsdBMUBU/1zD1DtJSeWCL2wJ4VGKYbzBIWRr9SDDdXaUANV7FTW0gjxoweEOSQu15EMt lmwEHolnEWAAPhhaIIx+xty0BAIGHtggND+ldogUYV4IyQDbQNLaOBi6oCGHQx2W3jVvcPNEk2c4 IgeKPPwlj1nPubgScno6RiN1jE20U3A7HurYaxYF/knRkGWWlMGRT/qg5FxNtvFklFsGAxpNk12p RJZScnkag1/2ICaKkJgJgmnFqRnYJlxuiBeJsY7D1K69orMWZDa06KRKYRDnDLHgAAYdW3eRUOZj xT3EBiiyfXMCianIWEMeGARGZA1xbPLKs53OKo4DDciqhANa1nYqqv5ceCdd8I6GIG3nilFrguMw 98Q2uhbnK76/yvokdxMo3IGfRvCZAym36DtxGxM8RDE57ZoK1L5eTrPhh/CKvO6s5ox8MspxyIrs v3wwIVSGAnmBMc2Q0PxSqaLlRYHCPVOwoLwoC33hxCYPffTHlN68NNNN2+cuTr38O7XHSA9NsdFW /lutAslOe/012CRo7HXXo5W9Bta1Cqz1yGG7/fa7JwNQgFdsW00LmXmTWQDffftdwF6BCz544Jvo KwFfPiu+OOOLw8K4AYATPjnlk/M8AeWNa7455517/vkECog+ugKVm346rnqrrjp4C3ywOuyx660b 7bXbLgDuueu+u+5aY30O3MELP3xOCIxKPPLJK78880bk3Dz00Us/vdfPU3899tlrr4b123v/PfjX Fxg++eWbT/z456u/PvsYp98+/PHLn8z789t/P/4ndJ8///2fv7//AijA7AFwgAY84PIKiMAF9i8J yAMPAyN4OLuxTUAWvCAGM2jB+3Cwgx78IAg9/jiMEHLwbyY8IQpTqMK/ZaYADpReAB4wjJrQsIY2 vCEOc6jDHfKwhz78IRD7I8QhErGIRjxiEVe4wvv8jYROfCIUOahBAdHNGA44W/DaxYACeMFeEvzi 9wpwDCyCrV0FICMY01g+yRRAeAFYQBvVKMf5gQZub3zhHPPYvjqGTTJo1CMgvycZsL3xj4E8pPbS 9TUGGBKRjrxeARzgNAZI8pGWLB/UaPbGS3IyfMJgGgPC1clRZi8AmaTYKUmpyug1AI8T++QqYym9 BxxPX62UJS6bZ8qbMTKXvkzeLmlWy18S023DnNUxi6nMpvUSawto5AENt0zqNbNoyZzm8kzZ/sIU HCMwrhNgNQ93TSlxZy8Ny8kfhUOuMsAMCBNYAjTRVxnmPJMEDCBAHCkTz2W0CHrhPFcwaXaNsNQG HDhoDKxe8Bog4E4JLfnWPpmwgKZIppIAkMxESWAMGRLAohlqAhYdgE/bkGxggWFmRH8RgHEeqDeb IpckgDCzFMx0HjYQgEAaU4YzkqAAivmFzWTzMJCdk6bt5EBpyrCAShajOJvJKACM0QbLLMCB9zyB VEnwAALg8apT3cyVJJOfyhSIrD2dZz2juhkCFKMYcfQmFBy41WKc5AnH6CbG/lkyltZmQYgyzhOO CrIRCRURJpEmYHkwHRUgIh1bPZsc5lYF/lJ8CBGbekIM1PIW5qBjOQ2rzEQ6CgAHULWNb1zqRQmw GUmSlqujheMJ2GiBsr51bglgwAt9ulQxLhWjYoAtaW9ipSs24LYk2+hKRbtVBqgrqlUtEH9oplc1 rXRpfgUZ1xxDU8Aoaxs6uk4irtIYD4zhI1YpKi7goBKVYSBQ61KFLrzCg4dEA0dr0ehE38jcuVW1 ASsAVRsts9KJahEZC70oVSuzRRcUt5oirWRWLRPbAIBKo4bbqitJ+0LQ+iCOGp4qX3MyXSml8lzX fZEvnpQC+GgAvOlok6K+5RwYxyGyOIgsOFqC2eIYdFOBUu9aDPKvdbExJkvNj2QLxNxW/o70wTHB bWhiO1LJZHK5WR2ta52rUS2JUbXRVauUPWpTrOZXtJKVFV5RmdI1lHhW143Nw3SELSf1QcY9XoyM sUPjDIDpxpbw6ab0FwvslsFG2jCUSjCBjhccA7dvLEYSxErJArn1tfn5z13xiGGtqpabzxSph7Mc YQNttY2U3nKYXeBTi+poq5UkbRzFKt01MyGgGHPpRMJgYx+IUruDQQkl7ixnFDsH2DhVz08XoV2L QHBQinFEuOxRHY6s4xI/ZUACqgoAbKd1AdkOzpWKW09vZ3TBrj7BPeN4Twi7VqQOHHVqJSlG4UK1 1PbUkjE24F9J2tue+BTjfvNKaya0/llNdMpLLu7UDBdc50XGicWvjkovd4xXC9gINmXhsU5dUNaw mFWxSVhkgpCENwqhXVYKtlpPn7rrnjKgjLt0q9FOh7zfuAgGaDm9ggendwYZpUyCex5aSubcJJSp 5FbX6V8oF7w2I8ZQ0zGkACoEa19VbwO52pmXP5xAdGsyhUBeMVMEKCAfzzGWYl7zjRqESxIJ1fgL cjUDUdIgpvqr6ZpkVVK9r6kMJ21DEwBvG+FJWODClKMApOkDxCoj5IngpEn+wxPDYyzEC5w8Tohj loEfsHXeFrO+nn4gy2Oz9KIRvdNNr/pZs371rp8V6kXT3NfT3umcV0Lsa697I+Re/sS3333te48T 4d/g7co4p9xrI1icZOBiGKJF8GZ255zE5qEs6rVK0dsU4pOD+y+YxUvKaxbG42w1TWEH9mtz4LDJ A7yiUfsNhvoLG8P+97y3/wnSHxjsS+G+o4CprDSM3elP1wzGA6yLg+RdE7STwxWBKBRB8pnHe8GM BGycGPydBCTVTvSaObiAIwiFECSeNAlBBYiD0gSBQhBacUyCQPTAOU0CuRzbCGxFx5QECeiGiiWD 9+kg53UBYaxIoUFBC3IWYwFMERbhJlCGEd5Jc1xWYO2EZU2I3jHHZqFcw/EAc0xEuJhAFs4ZnQwW RWRhjpDCKDiDSMhBDAjHF0KM/gZIDWUhHFKs4QncwRm8GEMsh1Ckh/NJFg5+gi1Qwlb4gALUASvU hxrs4C8gYiK0wBNYg2LkgkXsQwyMAhnkhnEww41ExIaEwWvY4LekgjzwiQlMIsQ8S3pwIBf6SP9x wxa+xR6e2YsIho1ASV2RwkcATwo63H29QI8EmiUiyQxwxBCIX5m8ASbkICg8ST8tXlCkR6C5BMOY iK5p3xEoIsFxHmA4hCnewFatw7RoAKA5xwxsQhpOgIrRyQrawTnplEvFEEKM2bc8h2KxSB6+hTzW QnW8RfrliDUIlf4AyQdQQZ1xnCJMTUbEXw1cx2C4ISOGy4HdmTGuBPaZ3Hax/syijJdQxIIQ4pky WOMSzJ4yZKN9MRxzrEOttNgPcOFD6ACUlOCbOKGf6FQCtIASKs36id9i/FQG+BQlDgSw2eMLbARj eMRCrYcC2AVf3NcOrIRI2F2yJQIm+uIPbGG4nJj/Vd9KPEdCcIdikJxOcAhGuskNIlpH4h8RgGQy iOQ2moVD+ogpmkj/ueJj/ADMxBG0/cNcFlpcGlQ3/FQueESyMULPqUJ5bVVCIB9K3iK0lYAliICJ EAvIOIG1LUr8kQGLaaGi8Ml1BSNjYiUAHMLN8QBiCSQcgGXGWaIucp5HKgFazp8WQOIjHkDiUcLi +VQoqoiuTZaK4MIkSJZq/qzTYdGmHdhmRv5UcC7FLppi232cMG4kys0hYb3DZxKhcfRcVLADLmDW olgfLiDcZBahWwidEyIboRHhyD1nYlnmjdygiv1FO6imWQJBa6oB+BnCDSLWYVWKO3AdxxkCM8AU 1RWHAATos8zBxn2DBNwCSZQEKFxLE0wAuVgge2GLAvgJJEgCOhSgBbSdn3xATIZLTUlCNdBUTS1n E8wM37VBQwkei6bAil4gjAIPi5ZNGgRei0JdfOLAfF6SEEgM9nQgIK3mEeyoJTUh8FEexRDpI+Xo kRKBkBqBkjaplL5A1IkGT00plh5UlTZFJGWpl74ALd2MDH0pmfZUbRXNs5aW6es9aTUyqZqSUnUt Dd+8KZbe0tJsEp02qa3dDB/l6e6xqUS5kp+uHiWBTVoN6uo1wJk2jR8hqurBltvckaNOkyktqqGS 3qQ+UlMRD6xlqiyRlrYpz7xdkZu6EQWdKqpewRStKqu2KqtGEazG6hOdUH5YSakeiAw9FRDdUH7s qq/+ag1tG7D+EBIVq7FiBgAckd/0hxKd0Nw0K7RGa7TK6gchwAF6KrZmq7ZuK7eqTwQAADs= ------=_NextPart_36C_A8E3_D0B4227A.F607BE68-- From sip-bounces@ietf.org Tue Jan 23 09:00:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9MAn-0002wS-24; Tue, 23 Jan 2007 08:58:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9MAl-0002tn-CU for sip@ietf.org; Tue, 23 Jan 2007 08:58:51 -0500 Received: from nexus.bca-itservices.com ([213.146.122.18] helo=mail.bca-itservices.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9M5s-00074y-Rb for sip@ietf.org; Tue, 23 Jan 2007 08:53:57 -0500 Received: from [10.2.1.249] (gw.rades-net.de [213.146.121.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.bca-itservices.com (Postfix) with ESMTP id B2A6E2402158 for ; Tue, 23 Jan 2007 14:53:43 +0100 (CET) Message-ID: <45B61364.7090600@bca-itservices.com> Date: Tue, 23 Jan 2007 14:53:40 +0100 From: Werner Rades User-Agent: Thunderbird 1.5.0.9 (X11/20061222) MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: [Sip] Inform a SIP Location Server about temporary moved users X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi all, I want to start a discussion on a - in my opinion - existing problem with "roaming" SIP users. Let's describe the problem: Guess we have two locations at our company. Each location has it's own SIP proxy (siteA.mydomain.tld and siteB.mydomain.tld) and users homed at one of theses two proxys. Thus users can register at their home registration server (their home proxy). So each user can be reached via sip:@. If the user is at this desk there is no problem. In case of an arriving call the UA at the registered IP of the user is invited via SIP. So the call get's established. Let's guess userA from siteA (sip:userA@siteA.mydomain.tld) is out for=20 hollidays and he want to redirect all his calls to this voicemail box.=20 Then he has a few possibilitys: (a) set a call redirection at his phone (so the phone sends a "temporarily moved" message to the proxy, the proxy can redirect the invite to his new location e.g. voicemailsystem@siteA.mydomain.tld) (b) ask his administrator for setting a static redirect at the location server (proxy) at siteA so that it redirects the invite to his new location e.g. voicemailsystem@siteA.mydomain.tld (c) use a protocol like DUNDI to find the user in the list of peered location server (proxys) to redirect the call to these address. (TRIP also can't solve the problem) (d) use ENUM and alter the NAPTR record to e.g.=20 voicemail@siteA.mydomain.tld (would only work if a call arrives at his=20 e.164 number, not for "direct" calls to userA@siteA.mydomain.tld) In my opinion all these posibilities are less satisfactory. The most interesting thing is a "static" redirect from the proxy server of the users home location (proxy siteA.mydomain.tld), but the users administrator would beat us to death. If we use the redirect from the phone (384 moved temporary) the phone needs to stay connected to the network (if we use a softphone or want to use the hardphone for other purposes then the invite could not be handled by the phone and the proxy doesn't get informed about the moved user). DUNDI would not make it possible to support a user moving out of the dundi administrative domain (e.g the user went out to work at home and has his sip client at home registerd with a sip provider, e.g. userA@myprovider.tld) and ENUM would not cover directed calls to userA@siteA.mydomain.tld. I think it would be great if we would have a sip command that the authenticated user could send to his home registration server (proxy or location server at siteA) and tell this server where the user has temporary moved to. This is more efficient than setting this at the phone (if it should=20 persist for more than a short), because of the phone can be turned of or=20 temporary used by another user from siteA. The same procedure is well known from conventional PBX distributors. They store the redirect information provided from the user to the phone in the PBX. So if you disconnect the phone the call redirection is still active. I have searched the web for a similar possibility in the SIP RFCs, but found no coresponding function. Is this still covered by any RFC and I was not able to found it? How do you think about this idea for a SIP command that can provide this functionality? Thanks for your comments and thoughts on this topic... Best regards, Werner Mit freundlichen Gr=FC=DFen Werner Rades -------------------------- BCA-Services Ltd. IT-Department Dachauer Str. 20 D-80335 M=FCnchen / Munich eMail wrades@bca-itservices.com Web: http://www.bca-itservices.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 23 09:12:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9MN4-00087z-Nj; Tue, 23 Jan 2007 09:11:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9MN2-00087W-Dh for sip@ietf.org; Tue, 23 Jan 2007 09:11:32 -0500 Received: from zimbra.mailvision.net ([212.143.248.123] helo=mvimap.mailvision.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9MMg-0003su-SL for sip@ietf.org; Tue, 23 Jan 2007 09:11:32 -0500 Received: from localhost (localhost [127.0.0.1]) by mvimap.mailvision.net (Postfix) with ESMTP id 4BA69284007; Tue, 23 Jan 2007 16:09:37 +0200 (IST) X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Jan 23 16:09:28 2007 X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 45b61718192372557716246 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at X-Spam-Score: -4.807 X-Spam-Level: X-Spam-Status: No, score=-4.807 tagged_above=-10 required=5 tests=[ALL_TRUSTED=-1.8, AWL=0.092, BAYES_00=-2.599, DSPAM_HAM=-0.5] Received: from mvimap.mailvision.net ([127.0.0.1]) by localhost (mvimap.mailvision.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83Iv95t4wvCe; Tue, 23 Jan 2007 16:09:27 +0200 (IST) Received: from [127.0.0.1] (unknown [192.168.0.34]) by mvimap.mailvision.net (Postfix) with ESMTP id B3C11284004; Tue, 23 Jan 2007 16:09:27 +0200 (IST) Message-ID: <45B61733.7030209@mailvision.com> Date: Tue, 23 Jan 2007 16:09:55 +0200 From: Diego B User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: Werner Rades Subject: Re: [Sip] Inform a SIP Location Server about temporary moved users References: <45B61364.7090600@bca-itservices.com> In-Reply-To: <45B61364.7090600@bca-itservices.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi; CPL can do this. If userA sends to the Proxy a CPL file with his new Forward preferences, the proxy will know where to find him ( or where to redirect calls to him= ) by applying the rules in the CPL script. Now the question is if your proxy supports CPL :) or any other way to configure Forward rules for users like Forward Unconditional to voice mail. Regards Diego B Werner Rades wrote: > Hi all, > > I want to start a discussion on a - in my opinion - existing problem > with "roaming" SIP users. Let's describe the problem: > Guess we have two locations at our company. Each location has it's own > SIP proxy (siteA.mydomain.tld and siteB.mydomain.tld) and users homed a= t > one of theses two proxys. Thus users can register at their home > registration server (their home proxy). So each user can be reached via > sip:@. If the user is at this desk there is no > problem. In case of an arriving call the UA at the registered IP of the > user is invited via SIP. So the call get's established. > > Let's guess userA from siteA (sip:userA@siteA.mydomain.tld) is out for=20 > hollidays and he want to redirect all his calls to this voicemail box.=20 > Then he has a few possibilitys: > (a) set a call redirection at his phone (so the phone sends a > "temporarily moved" message to the proxy, the proxy can redirect the > invite to his new location e.g. voicemailsystem@siteA.mydomain.tld) > (b) ask his administrator for setting a static redirect at the location > server (proxy) at siteA so that it redirects the invite to his new > location e.g. voicemailsystem@siteA.mydomain.tld > (c) use a protocol like DUNDI to find the user in the list of peered > location server (proxys) to redirect the call to these address. (TRIP > also can't solve the problem) > (d) use ENUM and alter the NAPTR record to e.g.=20 > voicemail@siteA.mydomain.tld (would only work if a call arrives at his=20 > e.164 number, not for "direct" calls to userA@siteA.mydomain.tld) > > > In my opinion all these posibilities are less satisfactory. The most > interesting thing is a "static" redirect from the proxy server of the > users home location (proxy siteA.mydomain.tld), but the users > administrator would beat us to death. > If we use the redirect from the phone (384 moved temporary) the phone > needs to stay connected to the network (if we use a softphone or want t= o > use the hardphone for other purposes then the invite could not be > handled by the phone and the proxy doesn't get informed about the moved > user). > DUNDI would not make it possible to support a user moving out of the > dundi administrative domain (e.g the user went out to work at home and > has his sip client at home registerd with a sip provider, e.g. > userA@myprovider.tld) and ENUM would not cover directed calls to > userA@siteA.mydomain.tld. > > I think it would be great if we would have a sip command that the > authenticated user could send to his home registration server (proxy or > location server at siteA) and tell this server where the user has > temporary moved to. > This is more efficient than setting this at the phone (if it should=20 > persist for more than a short), because of the phone can be turned of=20 > or temporary used by another user from siteA. > > The same procedure is well known from conventional PBX distributors. > They store the redirect information provided from the user to the phone > in the PBX. So if you disconnect the phone the call redirection is stil= l > active. > > I have searched the web for a similar possibility in the SIP RFCs, but > found no coresponding function. > > Is this still covered by any RFC and I was not able to found it? > How do you think about this idea for a SIP command that can provide thi= s > functionality? > > Thanks for your comments and thoughts on this topic... > > Best regards, > Werner > > > Mit freundlichen Gr=FC=DFen > > Werner Rades > -------------------------- > BCA-Services Ltd. > IT-Department > Dachauer Str. 20 > > D-80335 M=FCnchen / Munich > > eMail wrades@bca-itservices.com > Web: http://www.bca-itservices.com > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 23 09:39:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Mna-00060F-Mn; Tue, 23 Jan 2007 09:38:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9MnZ-000607-7V for sip@ietf.org; Tue, 23 Jan 2007 09:38:57 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9MnX-0002Ps-Mc for sip@ietf.org; Tue, 23 Jan 2007 09:38:57 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 23 Jan 2007 06:38:55 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l0NEcsxj027606; Tue, 23 Jan 2007 06:38:54 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0NEcmnL014285; Tue, 23 Jan 2007 06:38:49 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 09:38:49 -0500 Received: from [161.44.174.190] ([161.44.174.190]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 09:38:48 -0500 Message-ID: <45B61DF6.2070303@cisco.com> Date: Tue, 23 Jan 2007 09:38:46 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Werner Rades Subject: Re: [Sip] Inform a SIP Location Server about temporary moved users References: <45B61364.7090600@bca-itservices.com> In-Reply-To: <45B61364.7090600@bca-itservices.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 23 Jan 2007 14:38:48.0909 (UTC) FILETIME=[31A77FD0:01C73EFC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4388; t=1169563134; x=1170427134; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Inform=20a=20SIP=20Location=20Server=20about= 20temporary=20moved=20users |Sender:=20; bh=5SQ9MB1rcc5noV8zMLpQcQwWrnfH78lECkNRwIUBbUc=; b=JAW3naqsQfkj44Md2utvPuMB2WbzzKw3ulxnJz4HB6l8jY0juqGhqDi48Xnp6yPkX86v6J9C AwpWGTe7VJFhHngYCARPW0hsGhHdAiScmtg7TVhjrbtDIuTZZ8Qez5Zt; Authentication-Results: sj-dkim-6; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Werner, What you are asking for is essentially a standardized implementation of a particular service. (Call forward unconditional.) There is a new BOF (BLISS) starting up to look at this. That would be a place to go to pursue this further. Paul Werner Rades wrote: > Hi all, > > I want to start a discussion on a - in my opinion - existing problem > with "roaming" SIP users. Let's describe the problem: > Guess we have two locations at our company. Each location has it's own > SIP proxy (siteA.mydomain.tld and siteB.mydomain.tld) and users homed at > one of theses two proxys. Thus users can register at their home > registration server (their home proxy). So each user can be reached via > sip:@. If the user is at this desk there is no > problem. In case of an arriving call the UA at the registered IP of the > user is invited via SIP. So the call get's established. > > Let's guess userA from siteA (sip:userA@siteA.mydomain.tld) is out for > hollidays and he want to redirect all his calls to this voicemail box. > Then he has a few possibilitys: > (a) set a call redirection at his phone (so the phone sends a > "temporarily moved" message to the proxy, the proxy can redirect the > invite to his new location e.g. voicemailsystem@siteA.mydomain.tld) > (b) ask his administrator for setting a static redirect at the location > server (proxy) at siteA so that it redirects the invite to his new > location e.g. voicemailsystem@siteA.mydomain.tld > (c) use a protocol like DUNDI to find the user in the list of peered > location server (proxys) to redirect the call to these address. (TRIP > also can't solve the problem) > (d) use ENUM and alter the NAPTR record to e.g. > voicemail@siteA.mydomain.tld (would only work if a call arrives at his > e.164 number, not for "direct" calls to userA@siteA.mydomain.tld) > > > In my opinion all these posibilities are less satisfactory. The most > interesting thing is a "static" redirect from the proxy server of the > users home location (proxy siteA.mydomain.tld), but the users > administrator would beat us to death. > If we use the redirect from the phone (384 moved temporary) the phone > needs to stay connected to the network (if we use a softphone or want to > use the hardphone for other purposes then the invite could not be > handled by the phone and the proxy doesn't get informed about the moved > user). > DUNDI would not make it possible to support a user moving out of the > dundi administrative domain (e.g the user went out to work at home and > has his sip client at home registerd with a sip provider, e.g. > userA@myprovider.tld) and ENUM would not cover directed calls to > userA@siteA.mydomain.tld. > > I think it would be great if we would have a sip command that the > authenticated user could send to his home registration server (proxy or > location server at siteA) and tell this server where the user has > temporary moved to. > This is more efficient than setting this at the phone (if it should > persist for more than a short), because of the phone can be turned of or > temporary used by another user from siteA. > > The same procedure is well known from conventional PBX distributors. > They store the redirect information provided from the user to the phone > in the PBX. So if you disconnect the phone the call redirection is still > active. > > I have searched the web for a similar possibility in the SIP RFCs, but > found no coresponding function. > > Is this still covered by any RFC and I was not able to found it? > How do you think about this idea for a SIP command that can provide this > functionality? > > Thanks for your comments and thoughts on this topic... > > Best regards, > Werner > > > Mit freundlichen Grüßen > > Werner Rades > -------------------------- > BCA-Services Ltd. > IT-Department > Dachauer Str. 20 > > D-80335 München / Munich > > eMail wrades@bca-itservices.com > Web: http://www.bca-itservices.com > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 23 13:54:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9QmT-0000Qo-Gn; Tue, 23 Jan 2007 13:54:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qbs-0007yg-S3 for sip@ietf.org; Tue, 16 Jan 2007 10:52:28 -0500 Received: from mail1.exchange.microsoft.com ([131.107.1.17] helo=mail.exchange.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6qbq-0004i3-Ff for sip@ietf.org; Tue, 16 Jan 2007 10:52:28 -0500 Received: from df-bhd-01.exchange.corp.microsoft.com (157.54.54.216) by DF-GWY-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 16 Jan 2007 07:52:25 -0800 Received: from DF-MASTIFF-MSG.exchange.corp.microsoft.com ([157.54.61.165]) by df-bhd-01.exchange.corp.microsoft.com ([157.54.54.216]) with mapi; Tue, 16 Jan 2007 07:52:25 -0800 From: Sean Olson To: Paul Kyzivat Date: Tue, 16 Jan 2007 07:52:22 -0800 Subject: RE: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] Thread-Topic: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] Thread-Index: Acc5hbTeGYT3719vQcesTEwni4t8CQAABTAQ Message-ID: <4C1596FBF66C67478BCFE7B3F81FC1E01781EAA7A7@DF-MASTIFF-MSG.exchange.corp.microsoft.com> References: <7374777208BDC7449D5620EF9423256701614C26@esealmw113.eemea.ericsson.se> <45A7CDFB.5080705@cisco.com> <45A7DA65.5090802@alcatel-lucent.com> <45A7FED7.90604@cisco.com> <45ABF9C4.3090305@lucent.com> <4C1596FBF66C67478BCFE7B3F81FC1E01781EAA5EC@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <45ACF3AB.2080703@cisco.com> In-Reply-To: <45ACF3AB.2080703@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac X-Mailman-Approved-At: Tue, 23 Jan 2007 13:54:03 -0500 Cc: SIP LIST X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org My main point is that dropping prior connections to accept a new connection= is one possible policy, but hopefully not a commonly implemented one. Ever= y deployment will have some limit. Very few deployments have absolutely no = idea what their expected use will be though. Proper provisioning based on i= ntended usage and empirical evidence is a reasonable assumption. There are = other queuing/blocking techniques that can help with overload situations. D= oS attacks in particular should not be responded to by dropping existing co= nnections in order to feed the attack. -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Tuesday, January 16, 2007 7:48 AM To: Sean Olson Cc: Vijay K. Gurbani; SIP LIST Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPol= l: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outb= ound] Sean Olson wrote: > Wow.... that's one option, but certainly not the only one. This = is where I like to introduce multiple servers Sean - I'm not sure exactly which point you are trying to make. Certainly one option is to attempt to over configure the system so that there is enough capacity to accept every connection attempt. In certain closed environments that may be workable. But it is certainly not a solution for all environments. Presumably every deployment will have *some* limit. This limit could be reached in normal operation if the operators don't have control over the number of clients attempting to connect. That limit can support more devices if they don't attempt to keep the connection up all the time than it can if they do. The limit can also be reached as a result of devices that malfunction, or because of a DOS attack. The impact of that may also be worth some consideration. Paul > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] > Sent: Monday, January 15, 2007 2:02 PM > To: Paul Kyzivat > Cc: SIP LIST > Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutP= oll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-ou= tbound] > > Paul Kyzivat wrote: >> Suppose a server can support 1000 connections, and devices connect as >> soon as turned on, and attempt to reconnect whenever their connection is >> dropped. Then when the device 1001 attempts to connect, the server will >> have to drop somebody - perhaps the one whose connection as been idle >> for the longest. But that device will immediately try to reconnect, >> forcing another device to be disconnected. This will continue >> indefinitely. Doesn't seem like a very good strategy. > > Paul: Yes, you are right. I had forgotten about that insidious > side-effect. > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 23 13:54:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9QmU-0000Qv-6G; Tue, 23 Jan 2007 13:54:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6t11-0007kp-Av for sip@ietf.org; Tue, 16 Jan 2007 13:26:35 -0500 Received: from mail.exchange.microsoft.com ([131.107.1.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6t0y-00067A-PX for sip@ietf.org; Tue, 16 Jan 2007 13:26:35 -0500 Received: from df-bhd-01.exchange.corp.microsoft.com (157.54.54.216) by DF-GWY-07.exchange.corp.microsoft.com (157.54.63.164) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 16 Jan 2007 10:26:31 -0800 Received: from DF-MASTIFF-MSG.exchange.corp.microsoft.com ([157.54.61.165]) by df-bhd-01.exchange.corp.microsoft.com ([157.54.54.216]) with mapi; Tue, 16 Jan 2007 10:26:32 -0800 From: Sean Olson To: Paul Kyzivat , Tom-PT Taylor Date: Tue, 16 Jan 2007 10:26:29 -0800 Subject: RE: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] Thread-Topic: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound] Thread-Index: Acc5mo25wqgpW/PfRi+UIlWR+eV8/QAAPuGQ Message-ID: <4C1596FBF66C67478BCFE7B3F81FC1E01781EAA898@DF-MASTIFF-MSG.exchange.corp.microsoft.com> References: <7374777208BDC7449D5620EF9423256701614C26@esealmw113.eemea.ericsson.se> <45A7CDFB.5080705@cisco.com> <45A7DA65.5090802@alcatel-lucent.com> <45A7FED7.90604@cisco.com> <45ABF9C4.3090305@lucent.com> <4C1596FBF66C67478BCFE7B3F81FC1E01781EAA5EC@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <45ACF3AB.2080703@cisco.com> <4C1596FBF66C67478BCFE7B3F81FC1E01781EAA7A7@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <45ACF9D7.1000304@cisco.com> <45AD0122.8000102@nortel.com> <45AD16A9.6070000@cisco.com> In-Reply-To: <45AD16A9.6070000@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d X-Mailman-Approved-At: Tue, 23 Jan 2007 13:54:03 -0500 Cc: SIP LIST X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Even when provisioning trunk groups, you are not provisioning for every sin= gle subscriber to be in a call simultaneously. Provisioning needs to be don= e based on expected usage of course. A disconnect policy to deal with over= load and DoS is wise, but it needs to be more sophisticated than FIFO. And = the client does need to participate or at least have a clear way of determi= ning when the client is not playing nice. -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Tuesday, January 16, 2007 10:17 AM To: Tom-PT Taylor Cc: Sean Olson; SIP LIST Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPol= l: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outb= ound] Tom-PT Taylor wrote: > This isn't like provisioning a telephone trunk group (circuit group, in > European terminology), where you know each trunk will eventually be > freed when the call is complete. In the present case, you either provide > for every client to be connected or you need a disconnect policy. What I > suggest is a policy of disconnecting after some period of non-use, > rather than in response to incoming calls. That prevents "feeding a DOS > attack". Yes, some kind of disconnect policy. The connecting party has to play nice in that policy as well. If the connecting party always immediately reconnects then the policy doesn't work. Paul > Paul Kyzivat wrote: >> >> >> Sean Olson wrote: >>> My main point is that dropping prior connections to accept a new >>> connection is one possible policy, but hopefully not a commonly >>> implemented one. Every deployment will have some limit. Very few >>> deployments have absolutely no idea what their expected use will be >>> though. Proper provisioning based on intended usage and empirical >>> evidence is a reasonable assumption. There are other queuing/blocking >>> techniques that can help with overload situations. DoS attacks in >>> particular should not be responded to by dropping existing >>> connections in order to feed the attack. >> >> I certainly agree in the DOS case. And I am not knowledgeable in this >> area, so will defer to somebody that is. But at some point one must >> either drop an existing connection or reject a connection request. It >> seems pretty unfair if you end up rejecting connection requests that >> might be important in order to preserve a connection that hasn't been >> used in hours, days, or more. >> >> Unfortunately, what the connection request arrives there is generally >> no good way to tell how important it is. You might be able to decide >> based on what it does after you accept the connection. But that is too >> late. >> >> As I say, I am no expert here, so I will be happy if somebody can >> specify how this can be handled reasonably if every prospective client >> continually attempts to connect. >> >> Paul >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: Tuesday, January 16, 2007 7:48 AM >>> To: Sean Olson >>> Cc: Vijay K. Gurbani; SIP LIST >>> Subject: Re: TCP connection establishment [was: RE: [Sip] Question >>> aboutPoll: Proposal relating to keepalive, TCP, and UDP usage >>> indraft-ietf-sip-outbound] >>> >>> >>> >>> Sean Olson wrote: >>>> Wow.... that's one option, but certainly not the only one. >>>> This is where I like to introduce multiple servers >>> >>> Sean - I'm not sure exactly which point you are trying to make. >>> >>> Certainly one option is to attempt to over configure the system so that >>> there is enough capacity to accept every connection attempt. In certain >>> closed environments that may be workable. But it is certainly not a >>> solution for all environments. >>> >>> Presumably every deployment will have *some* limit. This limit could be >>> reached in normal operation if the operators don't have control over th= e >>> number of clients attempting to connect. That limit can support more >>> devices if they don't attempt to keep the connection up all the time >>> than it can if they do. >>> >>> The limit can also be reached as a result of devices that malfunction, >>> or because of a DOS attack. The impact of that may also be worth some >>> consideration. >>> >>> Paul >>> >>>> -----Original Message----- >>>> From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] >>>> Sent: Monday, January 15, 2007 2:02 PM >>>> To: Paul Kyzivat >>>> Cc: SIP LIST >>>> Subject: Re: TCP connection establishment [was: RE: [Sip] Question >>>> aboutPoll: Proposal relating to keepalive, TCP, and UDP usage >>>> indraft-ietf-sip-outbound] >>>> >>>> Paul Kyzivat wrote: >>>>> Suppose a server can support 1000 connections, and devices connect as >>>>> soon as turned on, and attempt to reconnect whenever their >>>>> connection is >>>>> dropped. Then when the device 1001 attempts to connect, the server >>>>> will >>>>> have to drop somebody - perhaps the one whose connection as been idle >>>>> for the longest. But that device will immediately try to reconnect, >>>>> forcing another device to be disconnected. This will continue >>>>> indefinitely. Doesn't seem like a very good strategy. >>>> Paul: Yes, you are right. I had forgotten about that insidious >>>> side-effect. >>>> >>>> - vijay >>>> -- >>>> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >>>> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >>>> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} >>>> WWW: http://www.alcatel-lucent.com/bell-labs >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>>> >>> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 24 04:11:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9e84-0002JE-2o; Wed, 24 Jan 2007 04:09:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9e4e-0001VO-AY for sip@ietf.org; Wed, 24 Jan 2007 04:05:44 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9e3e-0004F5-No for sip@ietf.org; Wed, 24 Jan 2007 04:04:44 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 09:57:03 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 24 Jan 2007 09:57:02 +0100 Message-ID: <2AF8FF7D89242541B12E7A47F6ECB4BE04EE9FD2@ftrdmel3.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Stateless Proxy and SIP responses Thread-Index: Acc6z5oobYQ9pCBYR262MUZ1eQhs1wExWXvg From: "CHADLI Youssef RD-CORE-ISS" To: "SIP LIST" X-OriginalArrivalTime: 24 Jan 2007 08:57:03.0756 (UTC) FILETIME=[9E0B34C0:01C73F95] X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [Sip] RE: Stateless Proxy and SIP responses X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1064242674==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1064242674== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73F95.A143FC11" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73F95.A143FC11 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Hi all,=20 >=20 > RFC 3261 states that even a stateless SIP proxy must insert a Via > entry containing its contact address in SIP request. Then, a stateless > Proxy will receive all SIP responses to a proxied SIP request. > However, in general, a stateless proxy would not need to receive the > SIP responses to a being proxied request. > I would like to konw what is the functional reason that leaded to > mandate Proxy stateless to receive SIP responses for proxied requests. >=20 Thanks in advance > Youssef =20 ------_=_NextPart_001_01C73F95.A143FC11 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Stateless Proxy and SIP responses

Hi all, =

RFC 3261 states that even a stateless = SIP proxy must insert a Via entry containing its contact address in SIP = request. Then, a stateless Proxy will receive all SIP responses to a = proxied SIP request. However, in general, a stateless proxy would not = need to receive the SIP responses to a being proxied request.

I would like to konw what is the = functional reason that leaded to mandate Proxy stateless to receive SIP = responses for proxied requests.

Thanks in advance

Youssef 

------_=_NextPart_001_01C73F95.A143FC11-- --===============1064242674== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1064242674==-- From djones@richardramirez.net Wed Jan 24 06:51:37 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9gfB-0006kT-P5 for sip-archive@lists.ietf.org; Wed, 24 Jan 2007 06:51:37 -0500 Received: from [196.205.181.166] (helo=host-196-205-181-166.static.link.com.eg) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H9ge0-0007CH-VZ for sip-archive@lists.ietf.org; Wed, 24 Jan 2007 06:51:37 -0500 Received: from 64.202.166.12 (HELO smtp.secureserver.net) by lists.ietf.org with esmtp (8)+*2I>5 /+-3VN) id >+9T(;-6I>)/@-*' for sip-archive@lists.ietf.org; Wed, 24 Jan 2007 11:50:19 -0120 Message-ID: <01c73fad$d2876850$6c822ecf@djones> From: "Emilia Childress" To: Subject: OEM vs. Retail? Date: Wed, 24 Jan 2007 11:50:19 -0120 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C73FBE.96103850" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2905 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2905 X-Spam-Score: 4.3 (++++) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C73FBE.96103850 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C73FBE.96103850" ------=_NextPart_001_0010_01C73FBE.96103850 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Side of the painting, the world of that wise, white,Rise, to the muffled ch= ime of churchbell choir.Allowing me to let your picture form and wakeOut of= the road into a way acrossthe old men burnish stories of Yaz and the BabeV= II. Hudson and His Strait; Baffin and His BayColumbuses or Gamas, ever pass= ,XVI. Laying a Ghost: The Jeannette and the FramThe edge of that other squa= re cut from the rightBut when, on the timepieces that we callAnd still my m= ind goes groping in the mud to bringIII. Earliest Recorded Northern Explore= rs: The Greeks and the Vikingsshortcake, waffles, berries and creamI. Furth= er Exploration of SpitsbergenToward . . . that seems to be the whispered qu= estionThat square=97Oh, 56 x 56XVII. GreenlandAnd still my mind goes gropin= g in the mud to bringshortcake, waffles, berries and cream ------=_NextPart_001_0010_01C73FBE.96103850 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
3D""
Side of the painting, the world of that wise, white,
Rise, to the m= uffled chime of churchbell choir.
Allowing me to let your picture form a= nd wake
Out of the road into a way across
the old men burnish stories= of Yaz and the Babe
VII. Hudson and His Strait; Baffin and His Bay
C= olumbuses or Gamas, ever pass,
XVI. Laying a Ghost: The Jeannette and th= e Fram
The edge of that other square cut from the right
But when, on = the timepieces that we call
And still my mind goes groping in the mud to= bring
III. Earliest Recorded Northern Explorers: The Greeks and the Vik= ings
shortcake, waffles, berries and cream
I. Further Exploration of = Spitsbergen
Toward . . . that seems to be the whispered question
That= square=97Oh, 56 x 56
XVII. Greenland
And still my mind goes groping = in the mud to bring
shortcake, waffles, berries and cream
------=_NextPart_001_0010_01C73FBE.96103850-- ------=_NextPart_000_000F_01C73FBE.96103850 Content-Type: image/gif; name="nwpt.gif" Content-ID: <006901c73fad$d2876850$6c822ecf@6E295767> Content-Transfer-Encoding: base64 R0lGODlhxgGvAbMAAP///wAAAAQE/B9hqmGw5Orq2729u8/PzvfwYvvQCGBUI7OZbPqCBvv7+wQE BAAAACwAAAAAxgGvAQAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i02hJoZ9qBitsJj0vsnTr8vQfU73gyehiDhH8U eokaiYwhgTxzXJEkjy+Hcn0Tk0qFm4aMnoOdlS2gj41sipqmpKusrYZAnlizH7Usl4iZUpu3rqe7 foG+ML3DkcGZwRewgCvEayrQi83Sy8LTSMYb14DHujmzyMCY5dTc1SDZ0SbrzOkobtvbuslxu4Wp ub/Hr63Ec/zZMXYtH593zlKtQhgLnYeAylR5C3UP4kSFfSZJrDdNnsZ9/hz/ZRxYqRaqifAcziPH 7+Olky0JvhT4rtoemsJCyuzGwaLChOaY5Unp8dBJmNhGJt1JMiYwg58iQl26zBTQhTVnTnVUsRw9 bK7C1hPrbWzZs1dzHuyJ52NQqWR5nlP7lpRJeNm0Yo3rEtO4fubw/SX7yS9hwYAv0k37k2/KhqfS QmS5GKzZymrttaXM0OFVevYYy+0sbnNncENZXQbq1rBognuxUnzd7CvfxppjA0xMmCvrpqh3B0Vt +fRe243nLgZd2+7j5c5jS2ccFRTx499wl4z+Gm3y6dcxiydeWrfN7MN90/Up+3z6z1DLS24+1Hzg 5lYfcsZunHr/huT1/mNdd9ppt88ryqG0UUjgjQPecPKNwB57CQkX3nz5RIjce6ShVyF+A7L13W/9 rZPXdublh5mGKMbklFxMxXcUdx+K2OBzda3HkoU3VkedgxeuVpN9wdFXQoQBlvjYiQU+eCGLIy7l n2dOcsRfchQCKJ47OQLZHpU/urelaUGWSeR8U45X339ePrkkUS1CZ2OQbaaZpX4cvlcnmtC0luea OdU5WY5CRvRTbmhSA4tg4Q1aZJxafofcbLbA2aR3JLp25pf3QSoppSt6WJxiYCIq4TB+NEomWhRt xltxcEnXp2acfdUXqzwWhmmsZv6npKyDTaeXsCTxxmuksN6a1GUH/o6GYW/qeWcbTKVNFaKC+231 IqiVudSsttu6ai1SaeqjGoFSYqtnRc0aKCO4N46LlCKtpvYXSNGOOmm7WYmE77jmsqWtnxhWO6uK KPHRjTs4hWolPyNO5il0/+IbZboBF4yuwALiyM7HIFca8pwjl2xyD1yukfLJLLd8pMdprOzyzDST zLLFNeesM54zO7vzz0AHLfTQRBdt9NFIJ6300kw37fTTUEct9dRUV2311VjfDDMuW4sgc9ZgW/G1 NTaMHfbZUJgdT9f5ou22F2qfEDegb9ddhVFPEXxHk/xC7GNW5dotuDbXzqgpiRt5WxW5CA/uOCf3 OvZsgMHq6Opq/oj98vjmSSDqOaoehvbhU8T25jPnqOMg3+qmtQnqnWpm+mfqtKvOHesLuR4n7HcZ enHtwNeAe4EObggkklTtGXvwzFtyO40e5b6fjmE+TP3vzWfPNUNQFj/98dDvTqP25DvvmqmpRjYx +KRvDFv58JcSOa7tQ/v65dLOTz/b8ffv100dq5eQHAYfeS2IXvzznwKX1S2L2eVXBfPXqhQztwVa 8IIYzKAGN8jBDnrwgyAMoQhHSMISmvCEKEyhClfIwha68IUwjKEMZ0jDGtrwhjjMoQ53yMMe+vCH QAReA0DQgCIaUQJGHOIEkkiCInZAiRxw4geGCEUpUoCJQWSZ/hUrcEQRJPGLGbBiF8OIxSVukYtG LEADCsDGNrbxAAcoQBzZ+EUn1hGMZrQjFC1QxiwSYYxe3CMR94hHNFbxkHdEZCK/qEY3shGOkDSA JCdJyUpa8pIGmCMYj7jIM2KAigAQpB+PIMoUADKUnkRiIvkYSlUWsZGOjCQmMbmAWdqSlgRYQC4X wEteZpKOnVxlKVvJxVGScpgyqCMq07jGN0byALesZC2jSc1qTnKalJwmAQyQy11KMo5KDKYyo2jM IOjxinoUpSfrCMs3yhGS0LxkLaeJTWva05L1vKc+85lLA2Bzjm4cZzpTicRyDkGM7HTkI2W5T306 9KEQjeg9/iHZxkWS0aA+eOUc4xnNfEr0oyANqUirCU14qpGKKOUjMjFagzVmEo7+HKlMZ0rTmkaz pL/cZB5XytJkvhOm2/SoTYd6SY4S9aiYxCk4UXrInu7ApZHkZT/nWVR4WvWqmZzkVWFaSaOC1Ks4 7SpSrxnTXpr1rL4Uqla/SVFQ9tGpN1gjTKFJT27qUqsmVShA43hVOfr1p1bN6lyzSljBGtaWJTXq M785Uqqi9bGQTes8PRpPrrZ1iXDlQQEMOwCpltWSAFWoaEXbzIXONbEvhedLGavUrTY0pv6MrFkZ sAAG2Pa2uL1tAnLL2972tra9TOpppUjQzMagAYI9wAI6/quA5eryn3kdrTsp+shYLtawSmWrRCcr W14iwLsL+O53E7AA8vKSvOgtb3nRS9vdupcB730vfG272/nS9r5mFW5bQWlcG0CVsdnsLGXdGNrQ Vle6qg2rLR0bXsimd7e1jW8CJkzhClOYvhier3snrOEOexjD8tWtb0d8W19Ssq887S8LijhYTG5z ln3lK2Apuleu0jK2aP1ug8Mr3gQggLzjfbB6ydveDksYvhvWcH05HF/7bri+uA1xkzPsW6oeNrFq VLENNnvYm26Vr1YlgJjHvE0dF7nJT7awmitM3zQzec0WRjKak8xkOYPYyFKeMpVHDOUqI4CtVj1p KU+p/uURNEDBXgZoMLlJZn/++NENfnCd3fxmOcNZzUjG85Erzek2G9m+n/40lJe8ZxLbNrjaNakr LVroQGb3ln2tqKBfyWgyj1fJl46zhNn8ZkzT2de8zvSk7YxmXIsY1BkmNbL7bOranji5TF1milut ARavFrEv/ausk3hSMo85yBd+sqjhLOxck/vXTg63uDmM51BnOt1O5nOUS53b4H5Z0NKmtgmQW9lE K7qTtR5zeClNcHPz+twFFzaxy13ucIv63XVO9p2VbeoRG+DP2GUjKl2p7yaiFtuBDqigGxlwMYPb 0sDm9K97nXJiq5vldFa4wovNbiVLPLd9ZnbFgTvN/tPCkdDF7bhKr4tYOB64kWv8ordNvmZjvzzX KDd4mmc+6amrfOHydfid3b3sivOWl4lN7KCnLXQknhbGqaUu0hmJ3KWzF+YHl7rcCR51uG8a3TZP Moizzlspe/23f/Y5OFVa9iceurCwVjvSF1/EkhPgx1CPvMoL7maX533YukY35vN+bFKH+O87X8DZ l0rMoBdelWdPPJiNvvYkOh4Bda/73OUu+9k7XfOd9ryyKa5n0H9d9IIn7sZPX20AvFqaOe4lbfP7 yiIunQAMgHztKZ/y2Vc995RuOMNpnvViI3vrvq93co0eTkIT/4rGVy0+I3tqBijA/QuY9QGWDnnr /kt9+rHP/KXbrW7+y5zvAPhh4Qd4YUd+hXR+Q+dVyGdi4aVc/2QAtiV/brde9leBTUd91XeBvcZ5 NEdlOtdbHwh63hVo44SArBRY6xdeZOVLUSV6STR/3lZ/CGeBNHhw+bdrl7eB2OdpD3dsA3hb71dL KGZ+JthKm4Vo12RvKuhsbQSBDHBSj0R/91eDGuhydrduGth/3ud5PMh13/eDJcYAq6dJpkd8Q0R0 2eRdkoRx/rRXtLV2MEhm6EWFdGh9Uad9MRd3WKdbOkdxYPh1aWeAZFd4coV4adhLfyZ6vFQA3CV6 SBeH31aHkliBN/h0ntaBFyZzNxeC4SeEJvVW/kWIREdoiEkYWxeHY7XVfhV1aG43iXY4iXhoaZe3 h6PWeX/odYv4TKBYhBqFhAvYhtDEZZJUS1nWSFLoisgoiSjHcOOmd7XIibcIfJ9YhqdXiDa2fp/V ht+0iq9UAK2YjOD4crJ4dQ43eTEXbz54c9EojfBEjdU4igsWXKLHaPP3b2l0jOGYj3PXcFWHjn4n gND4h+z4c+5YdtaogJPUWZS0TWBGAAeQdNzmdjKoj+E4jtmHgzAXanx3i80WiERognL1cQuYX/Qo ZrPWfN9IkSppbneYhyK2kfPmjxx5X1dVkB2nUdcmT83VSwwJidxmRPi4kvpoheO4jOKYc144/pO/ VZODaJBdhk8E0FwCZknNF5HeJpRYGXeV55K7FoIwqZS2xZRN2WpUJEdPSUnNtYaAJkd31G0xmJVw qYMW+X/z1nu1+IU/GIhZFopoJJI3JWt01HoNkJJxCY7Tl3kzx4E4B2rMFpBeF3gyxpd8dIQIKU2d RQB+BU4nCZGQSAA+VphDeZR314PP2HXp6Jgk5onkJ5lc5JeVRAAOoACyKZuYKYwPmXSCFpSgqZKy l5hT9o9fCZa5CEljSZYS8E6kOEkKMADflEsKQADI1Vm3yUysKIe7GZd4iJHx1nsviZc/GH9gVpyF hlLHd2JpGYzKpQCb5YiJRJjXaZgtV44e/vaPE9d3SimNfsWarcRiDGVJCqlaA0BXAQqFL3iV7ymU c7lkwdZ9Ggl+3vl3YKdq+olEAEZLz5ltBqAAw5hJidSZE3mgWLmM3al3W+eHqPl378SW4jmeh+aa WiWbjLVcyrVNrQeFBgqiK7l9TvdhEfeFH3iivkWCE8qflalVA6AAsYmkBsBvS5pI3mhrOJqPFrmV zbiJPFpqQIpbNFYAE2p2FZpUw+iQZulPggmU1hmlObpuvsmY6piObhp+v7SaQ4qG2ZSkzPVL/gSd P/lKb4mmFUmlmNig9SmA6Ah6qUVHXdqiybmQC7CcSXpNZdp4cvihfuqKO6qdwPmg9DaA/nFKenwZ Ti4qVtCkocs1SYv0pGNWqcnIj7hWaRppoqTpo3+XdlzKmqB6jZcUm8wpo7ElnRCpdLZGqbn2aKq6 f8C2d7Roi0D6eV4Xp4japalXVLyEpLqaSbX0q7hZnWJWrMpodZbXox3YdeH6h2lnk8YpAf1ZdKSq oWSKrUYUcAggrHBGrNw6g10Zi16pqQ4KpJ1aq9CaWrN0pMzJTXAUoLq0VHUEiTQor1FaiRjJhd5X n9yZpbZ1cazXpaGEnAvGXLHpgPPHS1XJmcFar3WoaSKae6fJpnvGrJuaW526otQWrTrpkDYmVe7K YpNKsqtajptXomzKe99HsXkFsyo2/kQaO0u6CqNsGUcc6qRQqrM0SHUsR4tcOKLbWZdvanHhSbRa JrOVpKHQFJV8BVXAxEyo6pkMC7UsqX86qGc5l6/deYtWxbX9ZbTp+rVspaHbtqd8+m1pq7aUaIP9 eKW/GbQrW3EvS7f9NYpF+mKjmlOB+au5map/S2ETWbm7OaVqGnEBCJOwepf6eltgdlIYi5xF2qjL OUmrOHJ19LQ1iLk42pvD1qBV64ehW2Vzq7iZ9V9FupwLEJtiGlA363yUK3cySK+faWGQB7tZmZ0o y270WbWF6nU0pru7a5a4SkkOIEkaqrea+ZP4NrIGx7DMq6qyeLXTW7uLub7QuHrm/tpxGluZ7Kqh vgqFkaqt8Tq+E/Zo/Ju8xPq/+9uwGal5Ogq6pdmyI4aft4mx/Ja92RSVR8qhKkqdSZSzyXtpxxvA H1p/HHydDouyPzufWBq31LtfiWq62Naojvi9m+lEcRiv5Ou/n0mvyyvDAXzDaIqvaxqTByyrCSyG P2W9cGVtDnxiQ1ujCStwNTyvODzDNqzBT1y+f5qFV6ug4hqTvtW+l5WoTHq6/fRzjtR8m4mqMCys y8u/+UvD+5vGNtzBcMmPA/xwfWiag7pzo/u+1EbEi9qoAluqS7p2J9lIAyBmA3fBFZa/hgzAS+zE iyzFUqqHPct1AWifFWd0P8fA/i1axHWKugrwkGU7xrpUZk58yGvsYzDMyDfMxv17wcj7xk+Hhe2G vvRGsey4l0N6eIu6kJ0MTQNQtu7abYN8ymrWv8hLzP5rzEt8uc2bhVook1e8r1nbfneMyauFkGGl txnqyQQKvgQwyLWUyIyMxqesysT8v2rsyDVolAk6Z1aKlFgMoT9Fuokaqs8msA7Qy9vcwtw0AOOs vKb8zzOsyqWcxorMyk0swCJsl7I8vSNmyfJsq6HUYvL0n7FVUbc5xtGZS4gsw2UszuL8zwSNzKOM zpaahwtKuO+srzqHAHOLsRGdkzoZmw4Qf5FLwc0Hg6JXzKasyGgc0Dttzqi8/siZa6x1PMIOSsf1 BsRyirGWVXQGIJ2w9MtpNH8KOcwhXcY/jdXjvNVBbbmGjJ1XyH/SO8fRjFvgqUkubXww/WyVNKCe HLIhi9MC3dPlrNUh7dPGfNBPHKI8m5jpa7UIXG8D6dJn6Isv6gCxSYxvjdHdSMgHkMgdHdl37dGS DdJzPdRTK58JXdYgWGXxLMQYtUcSjU/Mycs0na3Du0aEjMh1Tdlcvcr9zNVe7dUkTYVwTHVuesCN mZosvcVMPdq6zFidHLmBbJXfbM6SndzKndw7/dMgTcp8jZizO8mbyrJLmaKg3VOFncsZCnwZagDc WNxmKnocvdyVzdyRPcoG/t3KfI1/1A2QD/qBwzl4Lq1+Lua7y2lgNv2C0onc5v3f6Y3MAq3X0e2b R3bUt5vAn5jWTb1gqavNNn2SMPjYVw3grB3gWf3cI+3GYH1uVUzCbcqJDejbQ0qZMEab1jq2qV2g nXzGWd3RvHRft2XhFj7brlzA053S3umYK0zfJ0zPwyibiP2cmoTEIltLW63cqfh+UUbjzd3P5SWb Nr7MVnfgnWuLnV1vvU2QhI29t+S4+H2/s8aIAeraMC6bp6Z8Iw5TBVDGCvBjzQV5UZ4ACkDnjWrn HJ2mVb7DCQ6htZzd2s24SXWktAmeCnBoYsx2ql1mFR7Zp3Zx8QpfKpin/hrq5tOqXlGOAM3VXBO2 XmzsygPsd2ON5XZMUWltjbYklbLp1m+t6K73nADe5kEYrwcQr961TcFq63WOuj925+u16wS+zFJr c38tkFu+wC6NwmJlANv71Aegt2bLTvfI6B3d5h0NgXFu7Y9OsIxWxr1kym9u6+Kl6ehV2+kseRsJ ui0LjfPtrz++qHA0v88O3mzJujd7AMyZ3NaOAG0e45DO0kCGcXT17+bN67Mpm+xt7raXgz3ozAiu taaeqBkL5Mr54EYe7YemS5G972XshOG17z7mid1+5rLJY5r+5r8r28E+xc2sddZdcSG45g956g18 4gNb2s2E2nCNs//e/ub77vP8/l22xb/OxmirFa8+f/AlH68OoOuRjbohj6R1rvAziKwub5rqHtiP vuAMrOyXNL8du7chO+b5vvGSzeSpyHOe9U1B/11xHq8Ij7qNGpt0HvVSrsIn/9V02JK4h762m6Uq SJyAHtp6POiOqlyQq/Nst1mPB/Qc7/P9jl8NxtLjbvJBP9PePptJiqTTuumejvBuT/WSV8CFuttg KIQvhcf61nh3m01gu1zt1JaMxE1lbO2OT+viLtnPhYhO3/bPHl7b6/a1vutvDu5ST/dpKrvuZvpa f2rHbsu3rMmZ9OCqS9wQOeaq/fFtz/FB3+b7++87ll7lxe+NGtk7/hnuoH/wy4vwU76z8hmxQEti 7F6ugx/a2Nu73Bub9L7N0m5E84f0EIBQkdROmiQyG63lS5QQUZTDM0jECUdJSRZF0s4t0Xe+97Xf iNEbDnlFHZJRXCaWzGdUOg0ZDtdGA7Dldr1fcFg8JpfNZ3RavWa33e3s1Wqg1+sEkuMwWBQKjYOs hr8/QcG/A4KJCsYLCoShkBSJDo4PkIVJh4sPlprOjpMEF4mF0ROcINXVG5mgJUgdyIUop6apJ1tc 3AWrq0CtN+Fh4mLjY+TktDhfO2eDAQWCgoUBP8JBQ2zDgxBOx0U/jXCPks4+DtINnJYQdk8FBxwa ElUE1lUFhlin/n4GmSUnAv5TosvfLoRPJP3KoszhQ4gRJU48A+gAnYvPDNDohRFbIUMhsxUg0MHC o5PkGKR41GEjiE4eTvRZ8cmEjU8ySs3Ap8NVT1k76O3QV4OgDIAMTP3TlWtK04RRel3EEoziVaxZ tW4FA6iZxovVUFnp8zHktkG9vpG7JiLlh1IgZpYoEA+VOZseYowDsuOejxp98aG6MSTWE1f6irhy epAJ1KhSfVXlWtnyZcxw4lB9lpEOiJIGCgw4sA3k2SyKwjlqK26f3rgyaFwqZw52DhOi+P7twRvI JVMjaMhzVxQpQCBFZxA0pU+IP1uQI/NC8AtYZuzZtWfePEcj/h0HDqJlKp2lEMjT5ze2ZYthQqRS cC/NsL2I5W0b92LYEOyXqM8d5NFtplFCCA4H55JwghZb6umHQSgihEq6XaZiyKrtMtRwQ2Us8k6j agq4iI9BzBLptAboAOcaFsVZSocSJnHJJD9QOWES/EpxoJxxcqvBRuEWcIAoEgZ0Zbgif3quBhqa oMEgJZyScjqFrDsAAAw51HJLLiuSwzNnukFhDhQQOcQ8bdDsJiXWyOHJFLi+eSQGEoSsb6cX7GrO rtxAEA6n3GQRxcFBZ9pRn+CWaM4nghAr6JZaqKSiOl+6tPRSTLvwSo7voMmEDmtMRC8bbcpiq0UW F8HAD1VP/qKAhFeZNKE4AX2kJwY7YUxllBF08omjJAjrdSgA3aFloHoejQ5SSaWwsLwsM5V22q2i /bJTOlBxobTzSBUJzQJoXG01VNtESdVZS0kyyQnm2XGEUGzMSZ5fHRyWUOV6ze0egZxjaqmCHGs2 KvIupPZghKvF8pcPn1mgpJICCQRFtLxtwFRXUXWPzVVXhLWuGuTZax25TAiPMB8F3XFIdpp8LtCT RTGin1cUfExZSClECKMr/kj4Z6ApurZTG6cqsWI0RRJt3HJT5djcFthdQV2Z3InpBf2e1ODJeuRt LjieluNt5iOga0JBswdOqOArgnb7bWQG+QpbAsTiFlyL/tNLkU1Wy12VXHJUtZHkD3bUcYZ31THQ RyBlE0JJoIjwwYhc0oZS7Sc6oKoAuDv3fI1ghgbLOmj8KPFE1DbrO+MWGzgV6lfRocAAwzmiejbG fySuz9/+8i1ytG2m+exlD5pQbZ7L+3x55scYRPRnFOAjW9FE/faQc5vuu+PVWWVLHcJzT24c3YA3 v+bJjU87UswZSL6Q5uOXX27OOqVHHj+AqbhbbUojl/XW/O1puOrbk9YxEw/IAjdBOV9PyLYDnJlt fe1bAkasAD/5ZfBzz2uYHUYkvV8UAlpJQ12JmOa3jG2sEevIEX5+00AYSo5mZcMZFJbFrOlwIIRY 0mAP/oFmFfp10A5FqsM10nRE9LRGe9xjnQpX1ELc+I4vMYQh5SSorBtSsILW4Vy0fPjFSwFRREIc YkkUAI27mcZiZ+Fb97ZHgUGMC11zguIUf0dFPM5wZjebYIQGxjMDCAKMg8yUGOcAJmdEA41nPB2K kGgecwVQe6sLHCdcmIPd9CeP+EBC2a5ovChp8X0NIWQpMcVBRDrjfieo3kjy9i1Juq6JT2xV4DZA xxb25Y6bBEonrWjDX+JQZztrBilNeUwuZWFuGglNEc1UQhKasI1Pa1p7bHlJ3+lHk7z8wQM9uUfL CbN9zbgOMs3JIVR+5yInEE9HoKVGWB6NaQKUpAfA/oGuXOZHm7rkpgOhg7YogXKYkqJKz4x5ToRm Z4yc0oiIuhEN6SnAdCTknzacCLgUsueeuLxkULQpxX5GDpyPohxJx2mdgyZUpZdxaKe+1LMvuXKN FJXm/+bJnlriU6cdZWBIOQlQPYKypE9BXjFXetTLKLN+GhnABdOItIp6qxE4neYKc2pJvfRIirv0 afogGDyS3rCPf4ypF5F61ogwI5V2AAE51ehI1G0Po9Rcofc4epve8YCrPvWmV0ca1ik161nAMCta DTsMDD1vqQ7biFtf6S2K2dU97UmVNXeaoxfyZ5tdpeEniweZy41zMoI8bGkd0p21XoQAV3hYLxpJ /qpRneloK4IdPt9iVdhoVZd75WwvbebLLFKQYYQ1bXHjtilsVaO1vjDR9Ub1xsnWtZYcvSteM6vX 3srwqwEdXlOyKDBJJY+0xiWvMJRKRrKwFRgTSxrSLDqn7NW2AvfM5wJBmt1uzvCfEZTSQAlmpfGW V8DL2IKH1loHC3lEthTDmxJVSFl73lIv1cXkPnnLV/R99Yr9xSHyChrgAYfYDKh1aWurEUgWrTGq kLzruSx72frm57r49SQRgFvD7/qRYO5DaUpF/GMxbOrAD1WuaMqjt9i6ErqWpCUjnExh3b6QxqsI WHdryGHhjtbHQOYyF9QqxIwUzLWmg6pssXfZ/uxNGLdQ/OhHN9vbvgL1lwINrNoKZgUQd1nPmznw He48wuaWUK5Mlq6a2dwjfk65xlbWMI6lACX/4mIyxNVzpQsMgIJi6zPKna2g2ysIGIda1Ankj4wt rGgqy3m/jok0QmhRUEpb2tKLBRFzsUBYmZr5TKPGKptJrR8Z9xTVqrbiJztc54FZCUuFlfWALULr RDaDzCqGLGRxBJu7avXXppYydlFd5ZEam1kUCm5kPvWLZTd71ug9ZFjWYxa4MliWh97njIHtZo/2 58JdBWdnA3YLsWpxCcrOs7oFrIVwMbQzX3oYe5/7aZFcwdcTdzO+h/1TCfp7zkTVsbkLChKD/nc5 iKmd9EWOlmvnkgqKFMarPrld8WEX26/i9m6dW60UHqN7yyEvr4FdGsIUPxae6Ln2miluX5jHPL// NnbxBO6sL4Gc50BOOHqt1LrTRZON5im6oY+eVXzXW+noC3dAQ9lxc7MNg1MXcTp/XhpuBZ3aUGX5 16+bdGErnek0RzuyPb45HrI9xFxn99WD/lZYnqfr17y3rxF96ovrN79B5eOV26f2nQu+uFUnOdCN yD+9ObfXX9dnt3mzb343OuOP2e90bq6Qc0NL84Nv6ZC5ODF4vjKyt8k2vcGeaNQrGtysFh7aX0+e C2Z+9oZ1uzo9P+0yL7hEpdF2y1ueSf/k/j3yngUouAHOPgqqPfDLNy7XoZ08uH9e90fURt2jWP33 J1AwweemzNNX7FCC9/UVir0WlE9+pEoRhfMgLmqdQJspossAzGq8lzO97Ns+f2s6X6q8YxsYzAPA nlsobClA9YMt1Hiu/IG/X9uN+JMy+gupfvOq4vut4No//uux8cPAwzov24MpA6Sp0MMeliPBx+On 04PApfsnvmNBYBK4C2Q2GUQohDu/dhMRrMu9aPoI/7m+rQK2vLK4E0RBVQCuVcsZ8NMiEECpJCQv nxud58s6mjqT9PCejrJCbnszIFS9Thoes8sxvyMrqii4MTwqAYQ2WHNCI0LDakuT83iE/ru7wrBT oG67OPu7P8prPUh7OqVgGz3cQyX8Mud7vkBEi9iimGvrnXq7t8y6rziUnOFrjPw7NheEugtBQktE JhLrjMlAFV27nijEJTtSxDe8oyyEs5qZwzpsQUkcrEp8xXNCrkxMPzLrFniTqYlyqAN4M5DCQjgU vuDxrJJSnyJcRVdDvnIyxgAUsreLu2W0xdTRwawyQQb6wVLcQu3CvxzTP0lUikkrRnA0pVhcOBs8 PCXrR2eEu1ILgmnMt3YMwhUEOEZDxS+0M290xXssJbXqPGWEvpmyxUKUuAXqjXXUvjics87qwsoD r3kkxv97SELyEDK6OnKstmaEqinc/kiOrMaxM0h4NDsdczojpESHNEkwerY+00QPNEdCnL5JeMAf 2KVe9EX9qklI/D5uJBhy8j+eXCkmLDlyVL+WrEiLCEijLMhUAysru7KwtDkwrMcYnMpj0gLSkUVN TDKhzDWATEqv/MVrDCt5DC0jnLRLQ8tjDBcL0seJRMOstJ5nI8W5JLsVpKEIqrmBekpFKZi140tY XEszvEqUe8vTsI6uPEzgqbIhpMC+w5wEi0zJxEe/rMGJfMZ+HMyR+AWZ5MylrMuDpDORnEfJsI7S TCjK9CBbSzH3EkrToAq53L4H6rcJ7K71OZ7QvLxZPMvcJCS/HMfUXE3qVDHXHE7i/gQqsCRC7ys3 21QUaSvJ55QfaHy7G1wx0esfjIRNFURM1tu4bVzIkdTLnRzP5SlDfXQoWmTG6lywK1AN9tSwpkPO JOCvsfrO2+wZ+0xLDWRLoAxK4EyPRCjKABWp7tu4gIsUx/wvOSDNBfWhhUotoJy2Bss1eGsp7LTG xczGAl29SERQSZtFe/zQ5eG8ZARE/jRH0DuE1aKDAJ1DUyTQs7FJeYRRVjQo8aRRuGm+MOFA3yzR oVNDkrCEClU1G8NJoWJMI43REEpSJQ0a/2vQ0cFR1dRKiDuNHo1G2PSmsmtT76KzO/zOZ/HQL40f AUxJJ4XQrNRTi1gtzSpFsgFS/o/kMCwdt+W0zUmTujqdHzHNz5XM0XgKSkTICK9MQeFhtOLzwinZ UMwZJS9d1IRRKonsmf0cSihUskQAUCBk02sU0u+7mbPbUnOT0foE1VD1CqvbxzL9TTNjxgn905kU wnCjw+2CVdCS1ahI1E+1VYTpw2R81ChtRpZsgNUqiRTFI0FVvQ0z1g7jVFHSsmVl1mm50xokUxPV 0QZDhB41gOwM0r37N26NU2SdAvGaUXFtVvysA1h71JHgzwOsKAIIjYLsq0Hluwqc14RQ1lq913Fl wtt7UreMJzX6TyvoyIRkSqHSVHlF2AoCV4ZlHuQSUcuUVtZEomql0G+jy4DD/tLkPFSOdR9wDdeP 7ZJ8taCH7UDEo6iPKISADdjNTL0gFVAMHSq8fNnpqEeZnVmahR59ddJAkzeII5VfUNXIK05iRUWW fVWjTdaYXVilTaaMSKU/jLvX2tMkwhtA6NlFpLFAjU1iA81H29qE7TGv/VqwPSQzpMXL/DROdKVU FVj8sj+rJdJNdUqXfVl9aLeGSFq71ZBne1YyPVEIndzWDFgfnUlglENtPFy5dZaoDIa6bdwNybTK hFhdezhIfR7L7QCltFpXnU0sM6nOxQVYW1zRdRuGKd2rtB5pRVts6NmS4CxWDcKyy1L59FYjzDks KLDQvd3teCnA1Nvejatz/vxbqt2kYbVSAxXL2ZWUqagUL3Pen8ld3X1SNezPvk1by31N38qwtt2u DctQ7+xeKeAi0G1e8cUOpm1aUi1HEh1EZwxK4PWTBmpELnzE9xzQ46VfKuAxX8Df/NWO3eTf1ES8 JEMyvAFe1s0jwRVa7ZTAF+XczoW1vYzgg7HRJu1frHykAH641OjZy21fVuBCeI3EDLVJBkYIEmAY nzHhhEHhFFbhfpVU3z1X9V1fxPwmTNVOFi3eOgws5EXQOSUlCPZhrkg4keUWfg1goaPOvzUARfAn f8LQqzXcPqq5HE4IHq5iK+YK8wOLkvPN/eHboYQs4CWAsMG4wdXeG27Z/m1VzjSuki51zjbuEiCm 4Bv0x8kts2u44z89YG193z26MVX0IzQOZB0+N9Gw10Lejtor3VKtTk6M0jsm4DiLs3cESQncXo3F ZEFGUqlk405Oq6q7UbI9QK1zYWyw3l7IMCbeTiKMtOOJYqP93hFaNsadZYr45CDGUUUu2f9Fk1K+ B0vdTtd1UTOG1VSsTVeuEuayRWXeEGXCUxVeYfSkXDW6YzwGy/ddNMnDSYSQDnLjuEAmAe+AK0MI 5+1QrAFEP37lXX9MX/MI2AEggKZy5xtbYqbT2qgIrUvuZvDs0Fq0XX3mDmTkTadtrhzMZbRVZxH4 YAJtT3HzwoeGaO9t/lrKleWKJgYajF5nJtlpLWJuMGiaThRHBOFTLFrMIWYYbStnglKVXmnzuuhm /rzoO1M6JgTrrRuwAdJ3pkv+Qjae7t6OeODc6yKhTipxbOZ/bmGkRsBBoOmCDgEnll/PRGARNunI sOciGmISzeqkKk9QPs8o/OpAI2iaZtenVuJfHlLAmmpMruoLKseRgGvMwFWxvdmAlukdfTgwLmg8 YFdHwz+MjQ5Wo2e1tkDBJgSjLhHDTqrz+7hQXuSvNtHRMGjIDhvjTMxszka/nt/MphK2VhHtGYTP tozHRSSVpMjGtuvzJQSx9tkjGNouRE7XPtjYtjMPKhdAyIbbduOw/p1r0+1iPv0WvB4APjiWCPzr eL3QA01ugtnsSeKc566WCU7UleTiKKVOs0DtmtbrkExoYDLeVgZvC1zuprHt8t4KzgCTfWXuvt1R AH6r6w5e+abNFbVDwM7h2a6eyDWi/daK/f24rjbi3hboRMDugj6jg5xsS35VYbRv7xXsuFPGu4nw rCBdrjbdHO1tD2RGaEDtgqZkbIRTNIbnBZ/dzZ5IckTxFGdawzNnxq5rr4YG7KZpftDaCYLns+Nm EU87/OZx0/HxqzjNvI1cIobpC+c6scZush5akhYnLY3bJ5ftXnAnGzRxQqbyuCFffU1UIV8/On6s OJBxgzZlp2tR/hD/cE3V6TKnAhJ3Qi0GxKBm8zCQm2XyZzkWZaDe2Qbr8ulBSFywQ4bOcZNuKzRP PzU3dFpOdDgvVcL815imVg03aAeZ74xlcp2B7T93lkDf7dLg9E5HzZcGa5TjbFNtTQ0vdZCMVwmR z0lv9W5sLPTWT+WR9YfAYt2exfPE9RfP8jRM212fcWMtt4duTOQW9kn8DKuEqbZB9tMao0w016uG 9mf3RzvH7g+Q9PlW8o3V9rR7GEW/PXAPd0AiwDOkyKzL2RanKCPfdTzH2nh+97SGaMVwdW63ktu7 knpXhpZyUCzX6CF38V2e9qYygFooUngXuDo5FoTPdIU3qIZP/gYsdumngqyooni0HQkZ93KML1BK 1mYnL9yC1/Ezx3hAB+PBCnmGH3ljGDnAHNlzhWkuVjKSsHg8Nlxt3vjpKIqb34iwOHjY82mex02f //lGbUKhZ81obS/+bHkNX3pKZ3qcOxZEqeozx3SPl4peqBty6varPwZyjd40GvrU6frTtfgBWHfL DnMtsnQqOXN3s5C074ZuWHtAd3ubhfu4Z2lmfnOYmq3edfb1llxC0HsQwDLA39owbAZM6AjQx7lG wQV7lnfv2Ndvb/yhDu0Q6urJ/22gdqV/1/BeiM9w0nbSCTNaQPzpAIGmcieMRjfVf4MlXKyxne7T LcSiZ0Zs/ph97D6jPd/8l301zcH4zA8/0F981B9+xGL9coa+18fB6n4evScADWWfmSf7gamTjWgm CpY97neDrYb86RRoymdv2FL+sNb7w3B39e9pCFhmSWPNseeU5gEYiiNZmieaqivbui8cyzPsZfel bRxX+E0nCBx2PEKjJ1lcKoGEATQ6oDAYierVWsVqt94vOCwek8vmc1WRVlAohAUhh9kUP7Q7Pq/f 8/v+lg1Ozg6Pj6FQXSLRItARk1GRgVQUA0JXVhYX2iZnp2dnmwRchQ5H0h9qquoqayug4MXNziEi Uu1Qk+LjEdDBJJSCwVamZvHnMfKxmgIz24DClEBb3MDE/qDpqZ3rNne39zdJg6zcXGHPra6tuiLu 7dMkW5d8Mn09faiodb7Fm8WPdgNwAgcSLDgjyQYM5Aida1QLnbp2i3hBkvTrDZhMmOxxTLaMQbMF U0aGssbPQJw4seqcMujyJcyY4mDFokOLCTskjHA2sfXP4gABwAYkWHCFGLGOSj8tYFCyZA6VF0iV S2I1YMysWre6Eqcwg45y5w5NLOtIokSWRAY4+EWlTNKlSz8yW+AMn0lyemepzaaNK+DAgl0EDESz nI+GuHSW1Xl2ceMG7ya9nWdMLuYqTfFR0Kvhs9i+V/0OLm36tImEYK/xJfvjVi7HaGEHsdg2ioR5 cTPX/ltWVyRez2Jl0Rlt3CqIv6iXM986jrVNQ5GXQNy5DtKQA9CCShHG+/tmzlRrMhR7/Pzo5urX ywSwQyHrAmMfMjK7uDrPAr9wN73s/zsYy9gFHIFygMUQggdAhh6DWGHFHoQRdlMAfLGENt99SvRF 30NBeDjEE7dJsRuAaKjhlHgLJYigaA02GMKDEso4Ix8BqbZaKfNxmBZF9aWjDlCU9VciGQKy0dkU +0C34j8uOnlVci3ROCWVNKg2yIXS0RYRdTt1iciHbEUh1ABOEVlGeMFZuCJiLTqZHAB+QRmlclXa eScKFB42i47t7ILWdFa9dlUBk03iXYknHglckiZJ/kVegm4+WSdhMeJ5KaZxUljhZ60N2uSOZ33Y SESLGKAAmVHE850a4aHYhmcr8jVpepnaeuseQHxlIJ+uERHqdV36SZYN+0FRmT1NLYpPP7HKKimD uEo7bR69cJolLdbRZ1+GpN7XgbFlDnnPFpw5K6uCtCJHLbvtyrApp8Rl+1g6n/5KqiNgehCkFMia sZlTiyZZTWd7oQsteu4qvDALH8i3a47yzWsWT5Glha+gvRgbDCjijbcaugoi/CLDJZs8ghJfvYet loHmh7HLnxIgoqoEiAGwx7CqeLC66Vl6MtAnP0xcKRL7io6oPXE7qE+2SQHNGGlCBVrIG/RcmAg/ /ge99cIOJjjcvPRe5xDZ7Pz5jy/cCSCix/0UzOvBI5/HNd11Zy0fgjoY3fJrW7Y46qf2yheuxyct yaLcc6JsN+MnO2gEIXhHruVjF3/ItLBqNemBSNsROA1KcDOZ7psfYL1446k7jhAdrTPk2rawZZg5 JP/gzQ8cb6j06HDP0lrHClqrPjyudhjGA/I3QSS47bZ/6+dqoozycdVNxhktnddb6iDx3ZtsuuSJ maO8j8axhFPfq70xDRxr9p584usKbwL383t/P6ZW9XpTIUc7dPTlZpKD6YXOQmBj0Yvm9iBKZS1O 2mMg/iKIJyXYpH+06J+OJJa3AU5Ad+PJEfJe/pfAGCUMdSWYk/0kqMIpCQpvh8gg/24nnKgYKGIh tMmbVLCuFfKwcYSalQUNMZbjXSkhIIzU61rkwB4ysYnheCDkcJgYiYlDiOKrWu8kh8Os1cqJXmwi 1o6jRZH1QnkhHOPkNGg10xnni258I8oyRkFCVHFvF+SfCNnYRTjyEY4NuuLBIoUwLj4Ogn08JN2E p8cujkZfOUQkJCMZxwXS6UmV1Nr2UijJTYLRRZz8JCgJE8pRkrKUpjwlKlOpwgCwkpUhaCUsX0kC WLbylbQMwAhuOctYggCXIvClLIHZS1magJYlECYAdEnMZOYyl7zcpTGH+ctnMvOXtozmMqV5/k1X arOb1USmKrWCzHE2k5zNtOYxz+lNXwoTl+1M5ju9mc1qBhOdywQmN7tpTnUSM5735Kc8e+lPekrz nfEEZzhjss91ErShDUWoQ9mZTnq6s58UnWdADWpPiw4TnxiN6Cy1iVCJbjSgzPRoRkV6UZMm1CUQ nWdFS/rQYobUod+sZ0FXatORWnOgOe3oP1cATpLaFKY1DSlKd6rSpL60pQap5URVitGFypSo6PQo SkmaVJnqdKs/valOUzBUqRZTmVwFq1e/GtOwOnUrUM3mVm851qhyVJ1rvata6RpUtoIVrXB96zbf GleoUrWoWv0oVnHK0rbCZJ9y3StAp5pS/qBS9qJpVSo8ozlXpvIVpAydbGEhmtjJnlSxRWXsQKjq 1bjqVbKYLW1lR/vaq55zs/+87Fz1idjPnlW2PI0tQZuK2m+oFrSRFS0/i7vRdl52pkp17F9L+lvI QreqNLWldAEq3OEWBJt1pa12y0pNgQKWt87N7DOxyVOzsnWc43WtewEb2uvC9L3K5S5+86vf/fK3 v/79L4ADLOABE7jABj4wghOs4AUzuMEOfjCEIyzhCVO4whaOpAAyLACTbffCoNRwhjns4YRmWJPS 6vCINxlioKE4xTFYsQg2PAIQk0DGMd4wjENgYx3veMY0NgGIewyAFWuYxzm+cZGN/GMQ/gQZyEu+ MZNh/GQUNLnGU45ylG085Ra7+AVHTrKSfdzjEH+5zE6uspinHOQir9nKaF6zltucZjArmcZypvKd s3xlOOMYzaftMg3KPGY6D9nMgvZxCTSMFUIrOstIXnSjC73jSNO5xI92tJEhPWgBaJrTmD6zpjP9 6Sx3OtSLBfQMcszpSXta1Q1gNaRj/Oob/4zRUvY0knmMaCiPWtK6NrKYo2ypSg9614k2s69z/etl Y/nUqH5xnAv961tLu9nVlja1rRyObGeN29a29pHj5O1wv1rG5FZ1sXl9bDxvm9XGtjaXn70Cameb 3tEGd5+ZrW988/ne+vb2stG9bknz/lnd3762tk8QboQje9nxlrcKyIxriT+I4li2tK4xbvGEG7vf AG/4wsct5Gp73N0GR/i7OW7whsMb4nyQeMbdbW9Ez3zgHce1wtMd8JGLfOAYZ/fJF37wlH+b5dd+ uMtzfm2Yx7zpUK65yncecZ3j2+YCT7jQU270kxOd4VQ/etL1MOsdjx1lOO72kLeddhid/czB7vXS v37rTTPb1uYO99X/PfJeE/nQejc20sN+bLq/HdhuLvzgRW14SVdc7qyOM879zvjFR/rgW1/53BVv eZ0HXvCIT7ayFx/6UQv6ygS3tdY3rWYhw9nNe3Z80Ncco9anHvCex8OszX5CIede/u26P3m5Cc32 19e+28Q3u+mDH3LY61v5vPfz39Xd+dtTX6jVh0HJs6/97XO/+97/PvjDL/7xkz/E0xd8+dOv/vWz v/3uf3+Rz3/9+UeW/vaHgfzvP//867//+WUnex2VCzSXWC0W/+mBVZ3AAU5XHxygMxXgHjjgDCQg i32UAsYAAaJAh0ngHVDgKjAgH3Dgn1mgDIgg/pHgwjSXO3ETL6UXPG3TSeUTek2URAnWcr1gebmg DfbTDq7VZ62gaMmXK+HTEMYgeTEXEqaTELLgCzoTC+5gYB0hXHUUORFWE7bgXi0hVuHV1vgUduUV Dx5VPlmVbTVhX7mXQJHVN2VV/k+Blw861xgKIFExYRrGYV3N4S591wrSVQJW4RQGVxrmIRVOIWet 1EGxVtAgIRbeIXjZVSN6Fhl+VRZe10FZl1/JUyRqoG4B4kBRYFN5IWzJISYyoh6alEb9YUVx4Q0C Igq2CyiyIhEuoiPyoH1JYg1G1WpZYSlK4SVCYm/poi0Gl3rJYHltohQi13dJFSJWIh+yYk6l4jTF IjA648m8IjPOFnWd2mGFYW4hYl99Ix6eIWaBIhuW4iu61ipaFn19o2It4yPeYCcC1RtK4h86G7VY YyOCoBp6oBvm4yyGVSae4k/J1iPmFjjq1jmOYnIh5Dp6oCpeIzsS4ipC428xxmBCumJv+WMy7qMx ctQ1VldXBSR2EWFeVaQlXuEXkmQ8GuJUlSMONmRKFaJa8WMcriRA7uJLmSCEKOI0AqBP4lYR3lMx 9uJBTuI1FWVmrWFMZWJNkWNQJmUshiIvklc0KiExFmFOQmFyPeFVLiVNTeMMQlZSwmBH6uROSpJZ XkpaNhbdrGUi4o9bulTdxCXDyODw2OWd0KX/7SVf9qVf/iVgBqZgDiZhFqZhHiZiJqZiLiZjNqZj PiZkRqZkTiZlVqZlnkYEAAA7 ------=_NextPart_000_000F_01C73FBE.96103850-- From sip-bounces@ietf.org Wed Jan 24 09:06:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9ijH-0003VK-Kw; Wed, 24 Jan 2007 09:03:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9ijF-0003VA-3O for sip@ietf.org; Wed, 24 Jan 2007 09:03:57 -0500 Received: from mail.genaker.net ([193.145.84.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9ijC-0006Rm-ID for sip@ietf.org; Wed, 24 Jan 2007 09:03:57 -0500 Received: (qmail 23959 invoked by uid 107); 24 Jan 2007 14:56:37 -0000 Received: from 214.red-80-36-224.staticip.rima-tde.net (HELO ?10.1.1.11?) (David.Viamonte@genaker.net@80.36.224.214) by mail.genaker.net with AES256-SHA encrypted SMTP; 24 Jan 2007 14:56:37 -0000 Message-ID: <45B7674F.20601@genaker.net> Date: Wed, 24 Jan 2007 15:03:59 +0100 From: David Viamonte User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: CHADLI Youssef RD-CORE-ISS Subject: Re: [Sip] RE: Stateless Proxy and SIP responses References: <2AF8FF7D89242541B12E7A47F6ECB4BE04EE9FD2@ftrdmel3.rd.francetelecom.fr> In-Reply-To: <2AF8FF7D89242541B12E7A47F6ECB4BE04EE9FD2@ftrdmel3.rd.francetelecom.fr> X-Spam-Score: 1.2 (+) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1526821535==" Errors-To: sip-bounces@ietf.org --===============1526821535== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit A stateless proxy must receive all responses related to a request. Otherwise, the proxy is not able to know whether a proxied request succeeds, or a transmisssion error occurs, or the receiving entity died, ...

Additionally, consider a (stateless) forking proxy: it needs to receive an answer in one leg in order to cancel the request in the other leg, for example.

In general, observe that a request is only 50% of a full transaction. The minimum set of information any SIP node can proces is a full transaction. Therefore, in order to correctly process a request, a stateless proxy must receive and correctly process the answer(s) (e.g.: 100 Trying, 18x, 200 OK) as well. Afterwars, it may safely remain out of the signalling path of subsequent SIP messages.

For INVITE requests, the final ACK message may not traverse the stateless proxy. This is because the ACK is a "special" SIP message, not exactly a real request as other SIP messages.

Cheers,

David




CHADLI Youssef RD-CORE-ISS escribió:
RE: Stateless Proxy and SIP responses

Hi all,

RFC 3261 states that even a stateless SIP proxy must insert a Via entry containing its contact address in SIP request. Then, a stateless Proxy will receive all SIP responses to a proxied SIP request. However, in general, a stateless proxy would not need to receive the SIP responses to a being proxied request.

I would like to konw what is the functional reason that leaded to mandate Proxy stateless to receive SIP responses for proxied requests.

Thanks in advance

Youssef  


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============1526821535== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1526821535==-- From sip-bounces@ietf.org Wed Jan 24 09:56:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9jXp-0006pQ-KN; Wed, 24 Jan 2007 09:56:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9jXo-0006pA-KW for sip@ietf.org; Wed, 24 Jan 2007 09:56:12 -0500 Received: from mvimap.mailvision.net ([212.143.248.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9jXm-0001vC-Gl for sip@ietf.org; Wed, 24 Jan 2007 09:56:12 -0500 Received: from localhost (localhost [127.0.0.1]) by mvimap.mailvision.net (Postfix) with ESMTP id 8B53328400B; Wed, 24 Jan 2007 16:54:36 +0200 (IST) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Jan 24 16:54:27 2007 X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 45b77323290322335949428 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at X-Spam-Score: -4.816 X-Spam-Level: X-Spam-Status: No, score=-4.816 tagged_above=-10 required=5 tests=[ALL_TRUSTED=-1.8, AWL=0.083, BAYES_00=-2.599, DSPAM_HAM=-0.5] Received: from mvimap.mailvision.net ([127.0.0.1]) by localhost (mvimap.mailvision.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id On9dG+I2nDCt; Wed, 24 Jan 2007 16:54:05 +0200 (IST) Received: from [127.0.0.1] (unknown [192.168.0.34]) by mvimap.mailvision.net (Postfix) with ESMTP id B808D284001; Wed, 24 Jan 2007 16:54:05 +0200 (IST) Message-ID: <45B7732F.5020604@mailvision.com> Date: Wed, 24 Jan 2007 16:54:39 +0200 From: Diego B User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: David Viamonte Subject: Re: [Sip] RE: Stateless Proxy and SIP responses References: <2AF8FF7D89242541B12E7A47F6ECB4BE04EE9FD2@ftrdmel3.rd.francetelecom.fr> <45B7674F.20601@genaker.net> In-Reply-To: <45B7674F.20601@genaker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi How a stateless proxy can fork a request and then cancel one of the legs? A stateless Proxy has no Transaction memory, so it can not cancel a=20 transaction after receiving a response. I think a stateless proxy can not fork a request. Regards Diego B David Viamonte wrote: > A stateless proxy must receive all responses related to a request.=20 > Otherwise, the proxy is not able to know whether a proxied request=20 > succeeds, or a transmisssion error occurs, or the receiving entity=20 > died, ... > > Additionally, consider a (stateless) forking proxy: it needs to=20 > receive an answer in one leg in order to cancel the request in the=20 > other leg, for example. > > In general, observe that a request is only 50% of a full transaction.=20 > The minimum set of information any SIP node can proces is a full=20 > transaction. Therefore, in order to correctly process a request, a=20 > stateless proxy must receive and correctly process the answer(s)=20 > (e.g.: 100 Trying, 18x, 200 OK) as well. Afterwars, it may safely=20 > remain out of the signalling path of subsequent SIP messages. > > For INVITE requests, the final ACK message may not traverse the=20 > stateless proxy. This is because the ACK is a "special" SIP message,=20 > not exactly a real request as other SIP messages. > > Cheers, > > David > > > > > CHADLI Youssef RD-CORE-ISS escribi=F3: >> >> Hi all, >> >> RFC 3261 states that even a stateless SIP proxy must insert a Via=20 >> entry containing its contact address in SIP request. Then, a=20 >> stateless Proxy will receive all SIP responses to a proxied SIP=20 >> request. However, in general, a stateless proxy would not need to=20 >> receive the SIP responses to a being proxied request. >> >> I would like to konw what is the functional reason that leaded to=20 >> mandate Proxy stateless to receive SIP responses for proxied requests. >> >> Thanks in advance >> >> Youssef=20 >> >> ----------------------------------------------------------------------= -- >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > -----------------------------------------------------------------------= - > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 24 10:00:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9jbb-0000sE-Nn; Wed, 24 Jan 2007 10:00:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9jbZ-0000s6-Ls for sip@ietf.org; Wed, 24 Jan 2007 10:00:05 -0500 Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9jbX-0002XK-87 for sip@ietf.org; Wed, 24 Jan 2007 10:00:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Stateless Proxy and SIP responses Date: Wed, 24 Jan 2007 14:59:59 -0000 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0C240FC@veg-brk-svr-pri.vegastream> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Stateless Proxy and SIP responses thread-index: Acc/x+6dPkbXSQziTBKvWU7gQjrKeAAAEYFQ From: "Attila Sipos" To: "Diego B" , "David Viamonte" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >>I think a stateless proxy can not fork a request. This is correct. A stateless proxy cannot fork. Regards, Attila -----Original Message----- From: Diego B [mailto:diegob@mailvision.com] Sent: 24 January 2007 14:55 To: David Viamonte Cc: sip@ietf.org Subject: Re: [Sip] RE: Stateless Proxy and SIP responses Hi How a stateless proxy can fork a request and then cancel one of the = legs? A stateless Proxy has no Transaction memory, so it can not cancel a=20 transaction after receiving a response. I think a stateless proxy can not fork a request. Regards Diego B David Viamonte wrote: > A stateless proxy must receive all responses related to a request.=20 > Otherwise, the proxy is not able to know whether a proxied request=20 > succeeds, or a transmisssion error occurs, or the receiving entity=20 > died, ... > > Additionally, consider a (stateless) forking proxy: it needs to=20 > receive an answer in one leg in order to cancel the request in the=20 > other leg, for example. > > In general, observe that a request is only 50% of a full transaction.=20 > The minimum set of information any SIP node can proces is a full=20 > transaction. Therefore, in order to correctly process a request, a=20 > stateless proxy must receive and correctly process the answer(s)=20 > (e.g.: 100 Trying, 18x, 200 OK) as well. Afterwars, it may safely=20 > remain out of the signalling path of subsequent SIP messages. > > For INVITE requests, the final ACK message may not traverse the=20 > stateless proxy. This is because the ACK is a "special" SIP message,=20 > not exactly a real request as other SIP messages. > > Cheers, > > David > > > > > CHADLI Youssef RD-CORE-ISS escribi=F3: >> >> Hi all, >> >> RFC 3261 states that even a stateless SIP proxy must insert a Via=20 >> entry containing its contact address in SIP request. Then, a=20 >> stateless Proxy will receive all SIP responses to a proxied SIP=20 >> request. However, in general, a stateless proxy would not need to=20 >> receive the SIP responses to a being proxied request. >> >> I would like to konw what is the functional reason that leaded to=20 >> mandate Proxy stateless to receive SIP responses for proxied = requests. >> >> Thanks in advance >> >> Youssef=20 >> >> = ------------------------------------------------------------------------ >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > = ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 24 10:17:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9jry-0003At-UI; Wed, 24 Jan 2007 10:17:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9jrx-00036f-EZ for sip@ietf.org; Wed, 24 Jan 2007 10:17:01 -0500 Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9jrv-0005dO-SS for sip@ietf.org; Wed, 24 Jan 2007 10:17:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] RE: Stateless Proxy and SIP responses Date: Wed, 24 Jan 2007 15:16:27 -0000 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0C240FD@veg-brk-svr-pri.vegastream> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Stateless Proxy and SIP responses thread-index: Acc6z5oobYQ9pCBYR262MUZ1eQhs1wExWXvgAAzdnMA= From: "Attila Sipos" To: "CHADLI Youssef RD-CORE-ISS" , "SIP LIST" X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1448453273==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1448453273== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73FCA.9E27998C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73FCA.9E27998C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 I can think of a few reasons... =20 1. the UA (as far as I know) cannot know if a proxy is stateless or = stateful so it has to treat all requests in the same way. =20 (But even if you did know which proxies were stateful).... =20 2. Let's say you decide to send the response back without sending it = back to any proxies. To make it work, you think about ripping out all the = Vias except the bottom one and send the response to this remaining Via. But then even if you did try to send it to this remaining Via, there = is no certainty that it is directly reachable - it might not have a global IP or hostname = - especially if the request was sent via a stateless edge proxy. =20 3. for debugging purposes, say you are debugging one of the traversed = proxies - it is easier to debug if you see the request going out and a corresponding response coming back. =20 Regards, =20 Attila =20 =20 -----Original Message----- From: CHADLI Youssef RD-CORE-ISS = [mailto:youssef.chadli@orange-ftgroup.com] Sent: 24 January 2007 08:57 To: SIP LIST Subject: [Sip] RE: Stateless Proxy and SIP responses=20 Hi all,=20 RFC 3261 states that even a stateless SIP proxy must insert a Via entry = containing its contact address in SIP request. Then, a stateless Proxy = will receive all SIP responses to a proxied SIP request. However, in = general, a stateless proxy would not need to receive the SIP responses = to a being proxied request. I would like to konw what is the functional reason that leaded to = mandate Proxy stateless to receive SIP responses for proxied requests. Thanks in advance=20 Youssef =20 ------_=_NextPart_001_01C73FCA.9E27998C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Stateless Proxy and SIP responses
 
I can=20 think of a few reasons...
 
1. the UA (as far as I know) cannot know = if a=20 proxy is stateless or stateful
    so it has to = treat all requests=20 in the same way.
 
(But=20 even if you did know which proxies were = stateful)....
 
2. Let's say you decide to send the = response back=20 without sending it back to
    any proxies. To make it = work, you=20 think about ripping out all the Vias except the bottom=20 one
    and send the response to this remaining=20 Via.
    But then even if you did = try to send=20 it to this remaining Via, there is no certainty that
    it is directly reachable - = it might=20 not have a global IP or hostname - especially if the
    request was sent via a=20 stateless edge proxy.
 
3. for debugging purposes, say you are = debugging=20 one of the traversed proxies - it=20 is
    easier to debug if = you see the=20 request going out and a corresponding
    response coming=20 back.
 
Regards,
 
Attila   
 
-----Original Message-----
From: CHADLI Youssef = RD-CORE-ISS=20 [mailto:youssef.chadli@orange-ftgroup.com]
Sent: 24 January = 2007=20 08:57
To: SIP LIST
Subject: [Sip] RE: Stateless = Proxy and=20 SIP responses

Hi all,

RFC 3261 states that even a stateless = SIP proxy=20 must insert a Via entry containing its contact address in SIP request. = Then, a=20 stateless Proxy will receive all SIP responses to a proxied SIP = request.=20 However, in general, a stateless proxy would not need to receive the = SIP=20 responses to a being proxied request.

I would like to konw what is the = functional reason=20 that leaded to mandate Proxy stateless to receive SIP responses for = proxied=20 requests.

Thanks in advance

Youssef  =

------_=_NextPart_001_01C73FCA.9E27998C-- --===============1448453273== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1448453273==-- From sip-bounces@ietf.org Wed Jan 24 10:34:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9k8K-0004Y3-Cr; Wed, 24 Jan 2007 10:33:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9k8J-0004Xy-Sn for sip@ietf.org; Wed, 24 Jan 2007 10:33:55 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9k8I-0000gQ-Fe for sip@ietf.org; Wed, 24 Jan 2007 10:33:55 -0500 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l0OFXqDT027854 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Jan 2007 09:33:53 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <2AF8FF7D89242541B12E7A47F6ECB4BE04EE9FD2@ftrdmel3.rd.francetelecom.fr> References: <2AF8FF7D89242541B12E7A47F6ECB4BE04EE9FD2@ftrdmel3.rd.francetelecom.fr> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Robert Sparks Subject: Re: [Sip] RE: Stateless Proxy and SIP responses Date: Wed, 24 Jan 2007 09:33:52 -0600 To: "CHADLI Youssef RD-CORE-ISS" X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.1 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: SIP LIST X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0383404048==" Errors-To: sip-bounces@ietf.org --===============0383404048== Content-Type: multipart/alternative; boundary=Apple-Mail-8-219587591 --Apple-Mail-8-219587591 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Responses always follow the request path. Much of the defined behavior or SIP and its extensions count on this. - Responses are sent back over the TCP connection they arrived on - On UDP, responses are sent back to the apparent sending address (received) and if rport is present, the apparent sending port. If you attempted a different design that allowed the response to "skip" nodes in the path, you would have to rework many of those mechanisms, and you would have to introduce new solutions to deal with situations where A can reach B, B can reach C, but C cannot send traffic directly to A (something like what we have with Record-Route for dialogs). RjS On Jan 24, 2007, at 2:57 AM, CHADLI Youssef RD-CORE-ISS wrote: > Hi all, > > RFC 3261 states that even a stateless SIP proxy must insert a Via > entry containing its contact address in SIP request. Then, a > stateless Proxy will receive all SIP responses to a proxied SIP > request. However, in general, a stateless proxy would not need to > receive the SIP responses to a being proxied request. > > I would like to konw what is the functional reason that leaded to > mandate Proxy stateless to receive SIP responses for proxied requests. > > Thanks in advance > > Youssef > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --Apple-Mail-8-219587591 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Responses always follow the = request path. Much of the defined behavior or SIP and its extensions = count on this.
- Responses are sent back over the TCP = connection they arrived on
- On UDP, responses are sent back = to the apparent sending address (received) and if rport is present, the = apparent sending port.

If you attempted a = different design that allowed the response to "skip" nodes in the path, = you would
have to rework many of those mechanisms, and you = would have to introduce new solutions to deal with
situations = where A can reach B, B can reach C, but C cannot send traffic directly = to A (something like what we have with
Record-Route for = dialogs).=A0

RjS

O= n Jan 24, 2007, at 2:57 AM, CHADLI Youssef RD-CORE-ISS wrote:

Hi all, =

RFC 3261 states that even a = stateless SIP proxy must insert a Via entry containing its contact = address in SIP request. Then, a stateless Proxy will receive all SIP = responses to a proxied SIP request. However, in general, a stateless = proxy would not need to receive the SIP responses to a being proxied = request.

I would like to = konw what is the functional reason that leaded to mandate Proxy = stateless to receive SIP responses for proxied = requests.

Thanks in = advance

Youssef=A0 =

This list is = for NEW development of the core SIP Protocol
Use sip-implementors@cs.colum= bia.edu for questions on current sip
Use sipping@ietf.org for new = developments on the application of sip
=

= --Apple-Mail-8-219587591-- --===============0383404048== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0383404048==-- From sip-bounces@ietf.org Wed Jan 24 10:46:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9kJe-0001xM-JY; Wed, 24 Jan 2007 10:45:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9kJd-0001rV-8g for sip@ietf.org; Wed, 24 Jan 2007 10:45:37 -0500 Received: from alnrmhc15.comcast.net ([206.18.177.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9kJc-0002Zq-1K for sip@ietf.org; Wed, 24 Jan 2007 10:45:37 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc15) with ESMTP id <20070124154535b1500ks49ce>; Wed, 24 Jan 2007 15:45:35 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l0OFjYVJ003482 for ; Wed, 24 Jan 2007 10:45:34 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0OFjYPm003478; Wed, 24 Jan 2007 10:45:34 -0500 Date: Wed, 24 Jan 2007 10:45:34 -0500 Message-Id: <200701241545.l0OFjYPm003478@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <45B7732F.5020604@mailvision.com> (diegob@mailvision.com) Subject: Re: [Sip] RE: Stateless Proxy and SIP responses References: <2AF8FF7D89242541B12E7A47F6ECB4BE04EE9FD2@ftrdmel3.rd.francetelecom.fr> <45B7674F.20601@genaker.net> <45B7732F.5020604@mailvision.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Diego B How a stateless proxy can fork a request and then cancel one of the legs? A stateless Proxy has no Transaction memory, so it can not cancel a transaction after receiving a response. I think a stateless proxy can not fork a request. A stateless proxy can fork, and in some cases, can arrange to do actions that seem to require keeping state, without actually doing so. For forking, the simplest case is to do parallel forking -- when the request comes in, the proxy sends multiple copies to multiple destinations. When the responses come in, the proxy forwards them upstream. At the worse, the UAC receives multiple responses to its requests, and has to decide how to handle that, but it has to be able to do that anyway. The proxy can also do serial forking -- The proxy needs to save or encode the incoming request-URI into the Via header, along with the outgoing request-URI. When a response comes in, the proxy examines the Via header to determine the destination set it previously used for the request, and which destination this response came from. It can then decide whether to send another request to the next destination, or return the response upstream. Etc. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 24 10:51:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9kP5-0006cD-Im; Wed, 24 Jan 2007 10:51:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9kP3-0006az-Sn for sip@ietf.org; Wed, 24 Jan 2007 10:51:13 -0500 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9kP2-0003Vx-MQ for sip@ietf.org; Wed, 24 Jan 2007 10:51:13 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc12) with ESMTP id <200701241551120120025jjqe>; Wed, 24 Jan 2007 15:51:12 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l0OFpBVJ003885 for ; Wed, 24 Jan 2007 10:51:11 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0OFpBKk003881; Wed, 24 Jan 2007 10:51:11 -0500 Date: Wed, 24 Jan 2007 10:51:11 -0500 Message-Id: <200701241551.l0OFpBKk003881@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <2AF8FF7D89242541B12E7A47F6ECB4BE04EE9FD2@ftrdmel3.rd.francetelecom.fr> (youssef.chadli@orange-ftgroup.com) Subject: Re: [Sip] RE: Stateless Proxy and SIP responses References: <2AF8FF7D89242541B12E7A47F6ECB4BE04EE9FD2@ftrdmel3.rd.francetelecom.fr> X-Spam-Score: 0.2 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "CHADLI Youssef RD-CORE-ISS" RFC 3261 states that even a stateless SIP proxy must insert a Via entry containing its contact address in SIP request. Then, a stateless Proxy will receive all SIP responses to a proxied SIP request. However, in general, a stateless proxy would not need to receive the SIP responses to a being proxied request. I would like to konw what is the functional reason that leaded to mandate Proxy stateless to receive SIP responses for proxied requests. I expect that there are circumstances where a stateless proxy could safely not add a Via header. But one reason that you would want to add a Via header is to ensure addressing: If A sends the message to B, and B sends it to C, it's difficult to guarantee that C can send the response to the sent-by address that A uses in its Via header. After all, the stateless proxy was probably put into the architecture to solve some problem, and it probably wasn't to fork and route requests intelligently. The most likely reason is to gateway between two subnetworks with different addressing environments. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 24 11:03:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9ka5-0005Aa-Od; Wed, 24 Jan 2007 11:02:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9ka5-0005AV-7H for sip@ietf.org; Wed, 24 Jan 2007 11:02:37 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9ka2-0006XR-SK for sip@ietf.org; Wed, 24 Jan 2007 11:02:37 -0500 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l0OG2X9C029102 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Jan 2007 10:02:33 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <200701241545.l0OFjYPm003478@dragon.ariadne.com> References: <2AF8FF7D89242541B12E7A47F6ECB4BE04EE9FD2@ftrdmel3.rd.francetelecom.fr> <45B7674F.20601@genaker.net> <45B7732F.5020604@mailvision.com> <200701241545.l0OFjYPm003478@dragon.ariadne.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6231D1BC-37DE-482A-A98C-C027FD1CDD00@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] RE: Stateless Proxy and SIP responses Date: Wed, 24 Jan 2007 10:02:32 -0600 To: Dale.Worley@comcast.net X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is not correct. A stateless proxy as defined in 3261 is explicitly forbidden from forking. See section 16.11 on page 116: A stateless proxy MUST follow the request processing steps described in Sections 16.4 through 16.5 with the following exception: o A stateless proxy MUST choose one and only one target from the target set. This choice MUST only rely on fields in the message and time-invariant properties of the server. In particular, a retransmitted request MUST be forwarded to the same destination each time it is processed. Furthermore, CANCEL and non-Routed ACK requests MUST generate the same choice as their associated INVITE. RjS On Jan 24, 2007, at 9:45 AM, Dale.Worley@comcast.net wrote: > From: Diego B > > How a stateless proxy can fork a request and then cancel one of > the legs? > A stateless Proxy has no Transaction memory, so it can not cancel a > transaction after receiving a response. > I think a stateless proxy can not fork a request. > > A stateless proxy can fork, and in some cases, can arrange to do > actions that seem to require keeping state, without actually doing so. > > For forking, the simplest case is to do parallel forking -- when the > request comes in, the proxy sends multiple copies to multiple > destinations. When the responses come in, the proxy forwards them > upstream. At the worse, the UAC receives multiple responses to its > requests, and has to decide how to handle that, but it has to be able > to do that anyway. > > The proxy can also do serial forking -- The proxy needs to save or > encode the incoming request-URI into the Via header, along with the > outgoing request-URI. When a response comes in, the proxy examines > the Via header to determine the destination set it previously used for > the request, and which destination this response came from. It can > then decide whether to send another request to the next destination, > or return the response upstream. > > Etc. > > Dale > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 24 11:08:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9kfN-0000Hr-8g; Wed, 24 Jan 2007 11:08:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9kfL-0000Hl-Ap for sip@ietf.org; Wed, 24 Jan 2007 11:08:03 -0500 Received: from zimbra.mailvision.net ([212.143.248.123] helo=mvimap.mailvision.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9kfI-0007LV-Bh for sip@ietf.org; Wed, 24 Jan 2007 11:08:03 -0500 Received: from localhost (localhost [127.0.0.1]) by mvimap.mailvision.net (Postfix) with ESMTP id 14FD2284001; Wed, 24 Jan 2007 18:06:29 +0200 (IST) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Jan 24 18:06:14 2007 X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 45b783f6160251348188260 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at X-Spam-Score: -4.819 X-Spam-Level: X-Spam-Status: No, score=-4.819 tagged_above=-10 required=5 tests=[ALL_TRUSTED=-1.8, AWL=0.080, BAYES_00=-2.599, DSPAM_HAM=-0.5] Received: from mvimap.mailvision.net ([127.0.0.1]) by localhost (mvimap.mailvision.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3SuI3jTf5HP; Wed, 24 Jan 2007 18:05:57 +0200 (IST) Received: from [127.0.0.1] (unknown [192.168.0.34]) by mvimap.mailvision.net (Postfix) with ESMTP id 592EA28400A; Wed, 24 Jan 2007 18:05:56 +0200 (IST) Message-ID: <45B78407.4050903@mailvision.com> Date: Wed, 24 Jan 2007 18:06:31 +0200 From: Diego B User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sip] RE: Stateless Proxy and SIP responses References: <2AF8FF7D89242541B12E7A47F6ECB4BE04EE9FD2@ftrdmel3.rd.francetelecom.fr> <45B7674F.20601@genaker.net> <45B7732F.5020604@mailvision.com> <200701241545.l0OFjYPm003478@dragon.ariadne.com> In-Reply-To: <200701241545.l0OFjYPm003478@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi; See Inline: Regards Diego B Dale.Worley@comcast.net wrote: > From: Diego B > > How a stateless proxy can fork a request and then cancel one of the legs? > A stateless Proxy has no Transaction memory, so it can not cancel a > transaction after receiving a response. > I think a stateless proxy can not fork a request. > > A stateless proxy can fork, and in some cases, can arrange to do > actions that seem to require keeping state, without actually doing so. > > For forking, the simplest case is to do parallel forking -- when the > request comes in, the proxy sends multiple copies to multiple > destinations. When the responses come in, the proxy forwards them > upstream. At the worse, the UAC receives multiple responses to its > requests, and has to decide how to handle that, but it has to be able > to do that anyway. > > [DB] Ok; the stateless Proxy actually can fork, but it cannot perform the algorithm described in 3261 on selecting the best response, or canceling the outgoing requests when receiving an OK response or 6xx response. > The proxy can also do serial forking -- The proxy needs to save or > encode the incoming request-URI into the Via header, along with the > outgoing request-URI. When a response comes in, the proxy examines > the Via header to determine the destination set it previously used for > the request, and which destination this response came from. It can > then decide whether to send another request to the next destination, > or return the response upstream. > [DB] So, here you actually are saving the state on the Via header. In other words, you are implementing a state full proxy but instead of using the SIP Transaction state machine you are implementation your proprietary state machine. I would not call this Proxy stateless. > Etc. > > Dale > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 24 11:08:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9kfu-00014U-Sz; Wed, 24 Jan 2007 11:08:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9kft-0000xq-5P for sip@ietf.org; Wed, 24 Jan 2007 11:08:37 -0500 Received: from mail.genaker.net ([193.145.84.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9kfq-0007Tk-IE for sip@ietf.org; Wed, 24 Jan 2007 11:08:37 -0500 Received: (qmail 26773 invoked by uid 107); 24 Jan 2007 17:01:22 -0000 Received: from 214.red-80-36-224.staticip.rima-tde.net (HELO ?10.1.1.11?) (David.Viamonte@genaker.net@80.36.224.214) by mail.genaker.net with AES256-SHA encrypted SMTP; 24 Jan 2007 17:01:22 -0000 Message-ID: <45B7848C.40305@genaker.net> Date: Wed, 24 Jan 2007 17:08:44 +0100 From: David Viamonte User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Sip] RE: Stateless Proxy and SIP responses References: <2AF8FF7D89242541B12E7A47F6ECB4BE04EE9FD2@ftrdmel3.rd.francetelecom.fr> <45B7674F.20601@genaker.net> <45B7732F.5020604@mailvision.com> <200701241545.l0OFjYPm003478@dragon.ariadne.com> <6231D1BC-37DE-482A-A98C-C027FD1CDD00@nostrum.com> In-Reply-To: <6231D1BC-37DE-482A-A98C-C027FD1CDD00@nostrum.com> X-Spam-Score: 1.3 (+) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0096349919==" Errors-To: sip-bounces@ietf.org --===============0096349919== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit OK, forget about forking. It was only an example inside a more general explanation, and I reckon I didn't check the spec before about this particular topic.

Regardless, I think it is clear that -for more general and evident reasons- a proxy must be able to receive the response in order to correctly process the SIP request.

Cheers,

David




Robert Sparks escribió:
This is not correct. A stateless proxy as defined in 3261 is explicitly forbidden from forking.
See section 16.11 on page 116:

   A stateless proxy MUST follow the request processing steps described
   in Sections 16.4 through 16.5 with the following exception:

      o  A stateless proxy MUST choose one and only one target from the
         target set.  This choice MUST only rely on fields in the
         message and time-invariant properties of the server.  In
         particular, a retransmitted request MUST be forwarded to the
         same destination each time it is processed.  Furthermore,
         CANCEL and non-Routed ACK requests MUST generate the same
         choice as their associated INVITE.

RjS

On Jan 24, 2007, at 9:45 AM, Dale.Worley@comcast.net wrote:

   From: Diego B <diegob@mailvision.com>

   How a stateless proxy can fork a request and then cancel one of the legs?
   A stateless Proxy has no Transaction memory, so it can not cancel a
   transaction after receiving a response.
   I think a stateless proxy can not fork a request.

A stateless proxy can fork, and in some cases, can arrange to do
actions that seem to require keeping state, without actually doing so.

For forking, the simplest case is to do parallel forking -- when the
request comes in, the proxy sends multiple copies to multiple
destinations.  When the responses come in, the proxy forwards them
upstream.  At the worse, the UAC receives multiple responses to its
requests, and has to decide how to handle that, but it has to be able
to do that anyway.

The proxy can also do serial forking -- The proxy needs to save or
encode the incoming request-URI into the Via header, along with the
outgoing request-URI.  When a response comes in, the proxy examines
the Via header to determine the destination set it previously used for
the request, and which destination this response came from.  It can
then decide whether to send another request to the next destination,
or return the response upstream.

Etc.

Dale


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip

--===============0096349919== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0096349919==-- From sip-bounces@ietf.org Thu Jan 25 07:44:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA3wA-0002LT-7j; Thu, 25 Jan 2007 07:42:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA3w8-0002LL-Br for sip@ietf.org; Thu, 25 Jan 2007 07:42:40 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA3w5-0004tP-OJ for sip@ietf.org; Thu, 25 Jan 2007 07:42:40 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 13:42:29 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] RE: Stateless Proxy and SIP responses Date: Thu, 25 Jan 2007 13:42:20 +0100 Message-ID: <2AF8FF7D89242541B12E7A47F6ECB4BE04F1837F@ftrdmel3.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Stateless Proxy and SIP responses Thread-Index: Acc/wHwOEXqxnbN2T/eYq35TBC8zYwAvHf9g From: "CHADLI Youssef RD-CORE-ISS" To: "David Viamonte" X-OriginalArrivalTime: 25 Jan 2007 12:42:29.0613 (UTC) FILETIME=[467EF1D0:01C7407E] X-Spam-Score: 0.1 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2146284936==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2146284936== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7407E.4560538D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7407E.4560538D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 According to RFC3261, a stateless proxy does not maintain a transcation = state. Then when it receive a SIP response it cannot konw to which = resquest it does correspond. Moreover, a stateless proxy does not = perform retransmissions.=20 =20 Here is an extract from FRC 3261/8.2.7: A stateless UAS is a UAS that does not maintain transaction state. It replies to requests normally, but discards any state that would ordinarily be retained by a UAS after a response has been sent. If a stateless UAS receives a retransmission of a request, it regenerates the response and resends it, just as if it were replying to the first instance of the request. =20 Best regards =20 Youssef=20 ________________________________ De : David Viamonte [mailto:david.viamonte@genaker.net]=20 Envoy=E9 : mercredi 24 janvier 2007 15:04 =C0 : CHADLI Youssef RD-CORE-ISS Cc : sip@ietf.org Objet : Re: [Sip] RE: Stateless Proxy and SIP responses A stateless proxy must receive all responses related to a request. = Otherwise, the proxy is not able to know whether a proxied request = succeeds, or a transmisssion error occurs, or the receiving entity died, = ... Additionally, consider a (stateless) forking proxy: it needs to receive = an answer in one leg in order to cancel the request in the other leg, = for example. In general, observe that a request is only 50% of a full transaction. = The minimum set of information any SIP node can proces is a full = transaction. Therefore, in order to correctly process a request, a = stateless proxy must receive and correctly process the answer(s) (e.g.: = 100 Trying, 18x, 200 OK) as well. Afterwars, it may safely remain out of = the signalling path of subsequent SIP messages. For INVITE requests, the final ACK message may not traverse the = stateless proxy. This is because the ACK is a "special" SIP message, not = exactly a real request as other SIP messages. Cheers, David CHADLI Youssef RD-CORE-ISS escribi=F3:=20 Hi all,=20 RFC 3261 states that even a stateless SIP proxy must insert a Via entry = containing its contact address in SIP request. Then, a stateless Proxy = will receive all SIP responses to a proxied SIP request. However, in = general, a stateless proxy would not need to receive the SIP responses = to a being proxied request. I would like to konw what is the functional reason that leaded to = mandate Proxy stateless to receive SIP responses for proxied requests. Thanks in advance=20 Youssef =20 =09 ________________________________ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C7407E.4560538D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Stateless Proxy and SIP responses
Hi,
 
According to RFC3261, a stateless proxy does not maintain = a=20 transcation state. Then when it receive a SIP response it cannot konw to = which=20 resquest it does correspond. Moreover, a stateless proxy does not = perform=20 retransmissions. 
 
Here=20 is an extract from FRC 3261/8.2.7:
 A stateless UAS is a UAS = that does not=20 maintain transaction state.
 It replies to requests = normally, but=20 discards any state that would
 ordinarily be retained by a UAS = after a=20 response has been sent.  If a
 stateless UAS receives a=20 retransmission of a request, it regenerates
 the response and = resends=20 it, just as if it were replying to the first
 instance of the=20 request.
 
Best regards
 
Youssef 
De : David Viamonte=20 [mailto:david.viamonte@genaker.net]
Envoy=E9 : mercredi = 24 janvier=20 2007 15:04
=C0 : CHADLI Youssef = RD-CORE-ISS
Cc :=20 sip@ietf.org
Objet : Re: [Sip] RE: Stateless Proxy and = SIP=20 responses

A = stateless proxy=20 must receive all responses related to a request. Otherwise, the proxy is = not=20 able to know whether a proxied request succeeds, or a transmisssion = error=20 occurs, or the receiving entity died, ...

Additionally, consider = a=20 (stateless) forking proxy: it needs to receive an answer in one leg in = order to=20 cancel the request in the other leg, for example.

In general, = observe=20 that a request is only 50% of a full transaction. The minimum set of = information=20 any SIP node can proces is a full transaction. Therefore, in order to = correctly=20 process a request, a stateless proxy must receive and correctly process = the=20 answer(s) (e.g.: 100 Trying, 18x, 200 OK) as well. Afterwars, it may = safely=20 remain out of the signalling path of subsequent SIP messages.

For = INVITE=20 requests, the final ACK message may not traverse the stateless proxy. = This is=20 because the ACK is a "special" SIP message, not exactly a real request = as other=20 SIP=20 messages.

Cheers,

David




CHADLI=20 Youssef RD-CORE-ISS escribi=F3:=20

Hi all,

RFC 3261 states that even a stateless = SIP proxy=20 must insert a Via entry containing its contact address in SIP request. = Then, a=20 stateless Proxy will receive all SIP responses to a proxied SIP = request.=20 However, in general, a stateless proxy would not need to receive the = SIP=20 responses to a being proxied request.

I would like to konw what is the = functional reason=20 that leaded to mandate Proxy stateless to receive SIP responses for = proxied=20 requests.

Thanks in advance

Youssef  


_______________________________________________
Sip mailing list  https://www1.ietf.org=
/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.colu=
mbia.edu for questions on current sip
Use sipping@ietf.org for new =
developments on the application of sip
------_=_NextPart_001_01C7407E.4560538D-- --===============2146284936== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2146284936==-- From sip-bounces@ietf.org Thu Jan 25 07:58:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA4Am-0002Y8-T1; Thu, 25 Jan 2007 07:57:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA4Ak-0002XD-K0 for sip@ietf.org; Thu, 25 Jan 2007 07:57:46 -0500 Received: from web52813.mail.yahoo.com ([206.190.49.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HA4Aj-00006j-9W for sip@ietf.org; Thu, 25 Jan 2007 07:57:46 -0500 Received: (qmail 36465 invoked by uid 60001); 25 Jan 2007 12:57:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HcfbPTVtZJDaiRMrQs157Hyvyx2KYLGpQAW78zIbXVRj50fOag21LZH0Ak4zFEo7GpDGz20d5oomKykpZW2tPyJj0b0c+rrXDJ8UbtbaNeSI3X4wrqjxxB7nGvAUbFfHKVKs+7AYczLs86gRNslM3LvPdI1H+DA8kZQfhgBKQpM= ; Message-ID: <20070125125745.36463.qmail@web52813.mail.yahoo.com> X-YMail-OSG: Y11kMegVM1liOBvv8WZNQ28nQ2sAkZkZcq9KCsGm0DiMAjx6QjQ3czsdssE15mHYMMNnE02ri..feh5wrp_WSIgvRzg8.hqYyMYj_cgM7XB8.mcqtCaaf3cYcuTMxxjd7AVd9CCR7q4IaZR1j7qOZPiwfsxT66PeMoOVTF73ysqVEPdrYdsLatKe1C21 Received: from [47.168.54.136] by web52813.mail.yahoo.com via HTTP; Thu, 25 Jan 2007 04:57:45 PST X-Mailer: YahooMailRC/368.3 YahooMailWebService/0.6.132.7 Date: Thu, 25 Jan 2007 04:57:45 -0800 (PST) From: =?iso-8859-1?Q?Fatih_Ey=FCp_NAR?= To: fandreas@cisco.com, mbaugher@cisco.com, dwing@cisco.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: sip@ietf.org Subject: [Sip] SDES & Media Relay X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi;=0AI am little bit confused with following expression within RFC 4568 Se= ction 7.1.4:=0A"Another consideration here applies to media relays; if the = relay changes the media endpoint on one side transparently to the other sid= e, the relay cannot operate as a simple packet reflector but will have to a= ctively engage in SRTP packet processing and transformation (i.e., decrypti= on and re-encryption, etc.)."=0A=0AMedia Relay is simple , straight forward= -dummy we may say- network element whose duty is to transparently pass rec= eived media packets from one port to another . =0A=0AI couldn't catch the p= urpose of "actively engage in SRTP packet processing and transformation (i.= e., decryption and re-encryption, etc.)" for Media Relay.=0A=0AThanks from = Now=0A=0Afatih e. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 25 07:58:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA4BB-0002qz-RA; Thu, 25 Jan 2007 07:58:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA4BA-0002qF-Gt for sip@ietf.org; Thu, 25 Jan 2007 07:58:12 -0500 Received: from mail.genaker.net ([193.145.84.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA4B8-0000MI-PQ for sip@ietf.org; Thu, 25 Jan 2007 07:58:12 -0500 Received: (qmail 17846 invoked by uid 107); 25 Jan 2007 13:50:50 -0000 Received: from 214.red-80-36-224.staticip.rima-tde.net (HELO ?10.1.1.11?) (David.Viamonte@genaker.net@80.36.224.214) by mail.genaker.net with AES256-SHA encrypted SMTP; 25 Jan 2007 13:50:50 -0000 Message-ID: <45B8A95C.1000009@genaker.net> Date: Thu, 25 Jan 2007 13:58:04 +0100 From: David Viamonte User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: CHADLI Youssef RD-CORE-ISS Subject: Re: [Sip] RE: Stateless Proxy and SIP responses References: <2AF8FF7D89242541B12E7A47F6ECB4BE04F1837F@ftrdmel3.rd.francetelecom.fr> In-Reply-To: <2AF8FF7D89242541B12E7A47F6ECB4BE04F1837F@ftrdmel3.rd.francetelecom.fr> X-Spam-Score: 1.2 (+) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1127390366==" Errors-To: sip-bounces@ietf.org --===============1127390366== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Agreed.

I think the right reference is section 16.1 (stateless Proxy, not UAS).

Hence, I agree the right reason is backed by other mails sent by other contributors.

Sorry for BS'itting :-)

Cheers,

David




CHADLI Youssef RD-CORE-ISS escribió:
RE: Stateless Proxy and SIP responses
Hi,
 
According to RFC3261, a stateless proxy does not maintain a transcation state. Then when it receive a SIP response it cannot konw to which resquest it does correspond. Moreover, a stateless proxy does not perform retransmissions. 
 
Here is an extract from FRC 3261/8.2.7:
 A stateless UAS is a UAS that does not maintain transaction state.
 It replies to requests normally, but discards any state that would
 ordinarily be retained by a UAS after a response has been sent.  If a
 stateless UAS receives a retransmission of a request, it regenerates
 the response and resends it, just as if it were replying to the first
 instance of the request.
 
Best regards
 
Youssef 
De : David Viamonte [mailto:david.viamonte@genaker.net]
Envoyé : mercredi 24 janvier 2007 15:04
À : CHADLI Youssef RD-CORE-ISS
Cc : sip@ietf.org
Objet : Re: [Sip] RE: Stateless Proxy and SIP responses

A stateless proxy must receive all responses related to a request. Otherwise, the proxy is not able to know whether a proxied request succeeds, or a transmisssion error occurs, or the receiving entity died, ...

Additionally, consider a (stateless) forking proxy: it needs to receive an answer in one leg in order to cancel the request in the other leg, for example.

In general, observe that a request is only 50% of a full transaction. The minimum set of information any SIP node can proces is a full transaction. Therefore, in order to correctly process a request, a stateless proxy must receive and correctly process the answer(s) (e.g.: 100 Trying, 18x, 200 OK) as well. Afterwars, it may safely remain out of the signalling path of subsequent SIP messages.

For INVITE requests, the final ACK message may not traverse the stateless proxy. This is because the ACK is a "special" SIP message, not exactly a real request as other SIP messages.

Cheers,

David




CHADLI Youssef RD-CORE-ISS escribió:

Hi all,

RFC 3261 states that even a stateless SIP proxy must insert a Via entry containing its contact address in SIP request. Then, a stateless Proxy will receive all SIP responses to a proxied SIP request. However, in general, a stateless proxy would not need to receive the SIP responses to a being proxied request.

I would like to konw what is the functional reason that leaded to mandate Proxy stateless to receive SIP responses for proxied requests.

Thanks in advance

Youssef  


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============1127390366== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1127390366==-- From sip-bounces@ietf.org Fri Jan 26 07:08:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAPqo-00042C-RJ; Fri, 26 Jan 2007 07:06:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAPqm-000426-Mh for sip@ietf.org; Fri, 26 Jan 2007 07:06:36 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAPqh-0006ym-Ck for sip@ietf.org; Fri, 26 Jan 2007 07:06:36 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EAA8020991; Fri, 26 Jan 2007 13:06:30 +0100 (CET) X-AuditID: c1b4fb3c-affc8bb0000007de-05-45b9eec66f8b Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CFB66206BE; Fri, 26 Jan 2007 13:06:30 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 13:06:30 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 13:06:25 +0100 Received: from [131.160.36.66] (EH3I2003TGFCPET-131160036066.lmf.ericsson.se [131.160.36.66]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 50A05236A; Fri, 26 Jan 2007 14:06:25 +0200 (EET) Message-ID: <45B9EEC0.9020107@ericsson.com> Date: Fri, 26 Jan 2007 14:06:24 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jan 2007 12:06:25.0591 (UTC) FILETIME=[670D2470:01C74142] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Keith Drage , Dean Willis Subject: [Sip] New revisions of URI list drafts X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Folks, we have submitted new revisions of four URI-list drafts (INVITE, MESSAGE, SUBSCRIBE, and REFER). The main contents of the drafts have not changed. All changes introduced in these revisions have to do with document structure, updated references, etc. The SIP chairs will be requesting the publication of all these drafts shortly. Cheers, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 26 10:13:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HASjt-0002GY-MG; Fri, 26 Jan 2007 10:11:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HASjs-0002G4-NX for sip@ietf.org; Fri, 26 Jan 2007 10:11:40 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HASjr-00037T-Dn for sip@ietf.org; Fri, 26 Jan 2007 10:11:40 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l0QFBbik001163 for ; Fri, 26 Jan 2007 09:11:38 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 09:11:38 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 16:11:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Jan 2007 16:11:35 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180B880AD@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP at IETF#68 Thread-Index: AcdBXEVXUxBb/aBxTwOnib+rSzWmFA== From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 26 Jan 2007 15:11:36.0402 (UTC) FILETIME=[459C5B20:01C7415C] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Sip] SIP at IETF#68 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) Submitting drafts ----------------- In association with IETF#68 there are two cutoff dates for WG drafts: February 26, Monday - Internet Draft Cut-off for initial document (-00) submission by 09:00 ET (14:00 UTC/GMT) March 5, Monday - Internet Draft final submission cut-off by 09:00 ET (14:00 UTC/GMT) Documents submitted after these dates will not receive discussion in the meeting. If you believe you should be submitting a working group charter item as a -00 draft, then please inform the WG chairs as soon as possible. This will expedite posting your submission when you come to make it. This does not apply to individual author drafts. Agenda time ----------- We have requested two slots for IETF#68 for the SIP WG. Any agenda requests should be sent to the WG chairs along with your estimated time. I assume Dean will be coordinating this as usual and will issue more specific requests when the draft WG agenda is available. Finally a reminder that agenda time is primarily for discussing issues that are not reaching conclusion on the mailing list. Please ensure that all issues are given the opportunity for discussion on the mailing list before the meeting. This applies particularly to the editor's of WG drafts. Regards Keith Keith Drage drage@alcatel-lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 26 12:37:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAV00-0005g9-P1; Fri, 26 Jan 2007 12:36:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAUzz-0005fy-58 for sip@ietf.org; Fri, 26 Jan 2007 12:36:27 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAUzx-0008WS-RW for sip@ietf.org; Fri, 26 Jan 2007 12:36:27 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-2.cisco.com with ESMTP; 26 Jan 2007 09:36:25 -0800 X-IronPort-AV: i="4.13,244,1167638400"; d="scan'208"; a="358041969:sNHT52420632" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l0QHaPYQ029742; Fri, 26 Jan 2007 09:36:25 -0800 Received: from dwingwxp ([10.32.240.198]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0QHaOnF006702; Fri, 26 Jan 2007 09:36:24 -0800 (PST) From: "Dan Wing" To: "=?iso-8859-1?Q?'Fatih_Ey=FCp_NAR'?=" Date: Fri, 26 Jan 2007 09:36:25 -0800 Keywords: direct-to-dwing Message-ID: <07af01c74170$81133250$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20070125125745.36463.qmail@web52813.mail.yahoo.com> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdAgGi00TIOVhVrTVqZblgsT1OdpQA7msGg DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2485; t=1169832985; x=1170696985; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20SDES=20&=20Media=20Relay |Sender:=20; bh=uwmZkuaP/3Ap7C3v5jML48fUgzwqMtB+55Ua97Obyro=; b=pRBW8lo4jKPOT4FUyfDdjuD8brXaEF5rpPHZ/yqH3ALly9duZWmoeIz7YHr7zJghuUpswbjJ L19MH7tDk2waU5F32oGtFri73ntARDXwFTKca2Ri9u1K12DlGuB94Miw; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: sip@ietf.org, fandreas@cisco.com, mbaugher@cisco.com Subject: [Sip] RE: SDES & Media Relay X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org If you're doing sdescriptions (RFC4568) and have a media relay, you'll = have a situation like this, where Alice will be using key AAAA to Bob, and = Bob will be using key BBBB to Alice: Alice ------ [media relay] ------ Bob If the media relay, unbeknownst to Alice, switches the media to Carol, = like this: Alice ------ [media relay] \ \ \ Carol the media relay can tell Carol Alice's key (AAAA) in the Invite, but = there is no way for the media relay to dictate or indicate to Carol that she should transmit SRTP packets using Bob's old key (BBBB). Instead, Carol will choose her own key (let's call it CCCC). But Alice can't decrypt = SRTP media encrypted with CCCC, because Alice doesn't know it. The only way = to get this to work is: 1. the media relay needs to tell Alice that the call has been=20 switched from Bob to Carol. 2. the media relay needs to decrypt Carol's media traffic (using=20 key CCCC) and re-encrypt it with Bob's old key (BBBB). The text in the RFC talks about (2). =20 If you want to avoid having the media relay doing SRTP decrypt/encrypt operations, you need to do (1), which means that Alice will know when = the call is switched from Bob to Carol. -d =20 > -----Original Message----- > From: Fatih Ey=FCp NAR [mailto:fenar@yahoo.com]=20 > Sent: Thursday, January 25, 2007 4:58 AM > To: fandreas@cisco.com; mbaugher@cisco.com; dwing@cisco.com > Cc: sip@ietf.org > Subject: SDES & Media Relay >=20 > Hi; > I am little bit confused with following expression within RFC=20 > 4568 Section 7.1.4: > "Another consideration here applies to media relays; if the=20 > relay changes the media endpoint on one side transparently to=20 > the other side, the relay cannot operate as a simple packet=20 > reflector but will have to actively engage in SRTP packet=20 > processing and transformation (i.e., decryption and=20 > re-encryption, etc.)." >=20 > Media Relay is simple , straight forward -dummy we may say-=20 > network element whose duty is to transparently pass received=20 > media packets from one port to another .=20 >=20 > I couldn't catch the purpose of "actively engage in SRTP=20 > packet processing and transformation (i.e., decryption and=20 > re-encryption, etc.)" for Media Relay. >=20 > Thanks from Now >=20 > fatih e. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 26 12:55:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAVIH-0000Cy-N8; Fri, 26 Jan 2007 12:55:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAVIG-00009a-2W for sip@ietf.org; Fri, 26 Jan 2007 12:55:20 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAVIE-0002e2-Mz for sip@ietf.org; Fri, 26 Jan 2007 12:55:20 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 26 Jan 2007 09:55:18 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l0QHtHE5008734; Fri, 26 Jan 2007 09:55:17 -0800 Received: from [10.32.245.157] (stealth-10-32-245-157.cisco.com [10.32.245.157]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0QHtEnF015922; Fri, 26 Jan 2007 09:55:15 -0800 (PST) In-Reply-To: <07af01c74170$81133250$c5f0200a@amer.cisco.com> References: <07af01c74170$81133250$c5f0200a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <81D6826B-EC0A-4577-B4A6-B3890EAA9736@cisco.com> Content-Transfer-Encoding: quoted-printable From: David R Oran Subject: Re: [Sip] RE: SDES & Media Relay Date: Fri, 26 Jan 2007 12:55:07 -0500 To: "Dan Wing" X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3185; t=1169834117; x=1170698117; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[Sip]=20RE=3A=20SDES=20&=20Media=20Relay |Sender:=20; bh=9d9g+rbalDh48YjWc4M1efdkkr2Ab7TYOfy6DHl7NGA=; b=faqXc+AORyqqgPQpDXl5T8i5a9FMcn04Ha6IM33+TEsJs2WACErDSBvk0oM5JA9mx7+obk5t bD/Lo7xlbdXwkM27G/q+nDJMO4Bwa7ANNEQc/JfvhXjft2tggBS0ROJv; Authentication-Results: sj-dkim-7; header.From=oran@cisco.com; dkim=pass (si g from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org, fandreas@cisco.com, mbaugher@cisco.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jan 26, 2007, at 12:36 PM, Dan Wing wrote: > If you're doing sdescriptions (RFC4568) and have a media relay, =20 > you'll have > a situation like this, where Alice will be using key AAAA to Bob, =20 > and Bob > will be using key BBBB to Alice: > > Alice ------ [media relay] ------ Bob > > If the media relay, unbeknownst to Alice, switches the media to =20 > Carol, like > this: > > Alice ------ [media relay] > \ > \ > \ > Carol > > the media relay can tell Carol Alice's key (AAAA) in the Invite, =20 > but there > is no way for the media relay to dictate or indicate to Carol that she > should transmit SRTP packets using Bob's old key (BBBB). Instead, =20 > Carol > will choose her own key (let's call it CCCC). But Alice can't =20 > decrypt SRTP > media encrypted with CCCC, because Alice doesn't know it. The only =20= > way to > get this to work is: > > 1. the media relay needs to tell Alice that the call has been > switched from Bob to Carol. > 2. the media relay needs to decrypt Carol's media traffic (using > key CCCC) and re-encrypt it with Bob's old key (BBBB). > > The text in the RFC talks about (2). > > If you want to avoid having the media relay doing SRTP decrypt/encrypt > operations, you need to do (1), which means that Alice will know =20 > when the > call is switched from Bob to Carol. > Right, scheme (1) as stated would violate the Monica property. However, what stops the media relay from just doing a re-invite to =20 Alice to force a re-key. Alice will know SOMETHING happened but no =20 whether it was a transfer, and certainly not to whom. > -d > > > >> -----Original Message----- >> From: Fatih Ey=FCp NAR [mailto:fenar@yahoo.com] >> Sent: Thursday, January 25, 2007 4:58 AM >> To: fandreas@cisco.com; mbaugher@cisco.com; dwing@cisco.com >> Cc: sip@ietf.org >> Subject: SDES & Media Relay >> >> Hi; >> I am little bit confused with following expression within RFC >> 4568 Section 7.1.4: >> "Another consideration here applies to media relays; if the >> relay changes the media endpoint on one side transparently to >> the other side, the relay cannot operate as a simple packet >> reflector but will have to actively engage in SRTP packet >> processing and transformation (i.e., decryption and >> re-encryption, etc.)." >> >> Media Relay is simple , straight forward -dummy we may say- >> network element whose duty is to transparently pass received >> media packets from one port to another . >> >> I couldn't catch the purpose of "actively engage in SRTP >> packet processing and transformation (i.e., decryption and >> re-encryption, etc.)" for Media Relay. >> >> Thanks from Now >> >> fatih e. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 26 14:21:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWcw-00042o-BA; Fri, 26 Jan 2007 14:20:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWcu-000408-B3 for sip@ietf.org; Fri, 26 Jan 2007 14:20:44 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAWct-0007Gi-2d for sip@ietf.org; Fri, 26 Jan 2007 14:20:44 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 26 Jan 2007 11:20:42 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l0QJKgeh029593; Fri, 26 Jan 2007 11:20:42 -0800 Received: from dwingwxp ([10.32.240.198]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0QJKfnF029716; Fri, 26 Jan 2007 11:20:41 -0800 (PST) From: "Dan Wing" To: "'David R Oran'" Subject: RE: [Sip] RE: SDES & Media Relay Date: Fri, 26 Jan 2007 11:20:41 -0800 Keywords: direct-to-dwing Message-ID: <081401c7417f$11fec5f0$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <81D6826B-EC0A-4577-B4A6-B3890EAA9736@cisco.com> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdBcyO9AV7FoCCdRB2FNmwcdkzkDgAC4Q9g DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=944; t=1169839242; x=1170703242; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20RE=3A=20SDES=20&=20Media=20Relay |Sender:=20; bh=jpm2eCxmwEjkTf5r/bvp/SJPREYHcjVmZYVN5sETTCw=; b=YS8UuWRxHpSo0ygPjPaTUGtVW/3NNSdkU5HkFdZHxfpOvmUknxEI4Y85srVO3DtsfxvRQ+YB U7abiQggvPbBSZgeK1vpnoWD/ydAaJp5gC6VIdHPExwCpemNkEHVAKvW; Authentication-Results: sj-dkim-8; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: sip@ietf.org, fandreas@cisco.com, mbaugher@cisco.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > 1. the media relay needs to tell Alice that the call has been > > switched from Bob to Carol. > > 2. the media relay needs to decrypt Carol's media traffic (using > > key CCCC) and re-encrypt it with Bob's old key (BBBB). > > > > The text in the RFC talks about (2). > > > > If you want to avoid having the media relay doing SRTP > > decrypt/encrypt > > operations, you need to do (1), which means that Alice will know > > when the > > call is switched from Bob to Carol. > > Right, scheme (1) as stated would violate the Monica property. > However, what stops the media relay from just doing a re-invite to > Alice to force a re-key. Alice will know SOMETHING happened but no > whether it was a transfer, and certainly not to whom. Sure, that would work, if that level of information leakage to Alice is acceptable. I agree that it's acceptable in all but the most severe environments. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 26 15:51:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAY1Q-0000sQ-3R; Fri, 26 Jan 2007 15:50:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAY1K-0000pu-QO; Fri, 26 Jan 2007 15:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAY1K-0004I5-Ig; Fri, 26 Jan 2007 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 72F1B32A27; Fri, 26 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HAY1K-0004Nl-BM; Fri, 26 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 26 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-uri-list-conferencing-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP) Author(s) : G. Camarillo, A. Johnston Filename : draft-ietf-sip-uri-list-conferencing-01.txt Pages : 14 Date : 2007-1-26 This document describes how to create a conference using SIP URI-list services. In particular, it describes a mechanism that allows a user agent client to provide a conference server with the initial list of participants using an INVITE-contained URI-list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-uri-list-conferencing-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-uri-list-conferencing-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-uri-list-conferencing-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-26105621.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-uri-list-conferencing-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-uri-list-conferencing-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-26105621.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Fri Jan 26 15:51:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAY22-0001UV-D4; Fri, 26 Jan 2007 15:50:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAY1r-0001E9-2J; Fri, 26 Jan 2007 15:50:35 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HAY1o-0000wI-M8; Fri, 26 Jan 2007 15:50:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 96D0E2ACC0; Fri, 26 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HAY1K-0004No-C9; Fri, 26 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 26 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-uri-list-subscribe-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP) Author(s) : G. Camarillo, et al. Filename : draft-ietf-sip-uri-list-subscribe-01.txt Pages : 10 Date : 2007-1-26 This document specifies a way to create subscription to a list of resources in SIP. This is achieved by including the list of resources in the body of a SUBSCRIBE request. Instead of having a subscriber send a SUBSCRIBE request for each resource individually, the subscriber defines the resource list, subscribes to it, and gets notifications about changes in the resources' state using a single SUBSCRIBE dialog. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-uri-list-subscribe-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-uri-list-subscribe-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-uri-list-subscribe-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-26105923.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-uri-list-subscribe-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-uri-list-subscribe-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-26105923.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Fri Jan 26 18:37:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAacB-0002qS-5E; Fri, 26 Jan 2007 18:36:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAac9-0002q4-Nv for sip@ietf.org; Fri, 26 Jan 2007 18:36:13 -0500 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAac9-0005b9-3V for sip@ietf.org; Fri, 26 Jan 2007 18:36:13 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l0QNa7nm016084 for ; Fri, 26 Jan 2007 17:36:12 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 17:36:06 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 Jan 2007 00:35:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C741A2.B2AD157E" Subject: FW: [Sip] I-D ACTION:draft-ietf-sip-uri-list-subscribe-01.txt Date: Sat, 27 Jan 2007 00:35:39 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180B8818E@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-uri-list-subscribe-01.txt Thread-Index: AcdBi+tBmYBaxtw9Rm28ueQsEXmy7QAFpAfA From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 26 Jan 2007 23:35:44.0190 (UTC) FILETIME=[B2B285E0:01C741A2] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: abb8110dde048486ea2be9c769692569 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C741A2.B2AD157E Content-Type: text/plain; name="warning1.txt" Content-Disposition: inline; filename="warning1.txt" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: MIME-tools 5.420 (Entity 5.420) WARNING: This e-mail has been altered by some SMTP protection software. Following this paragraph are indications of the actual changes made. For more information, contact . An attachment named draft-ietf-sip-uri-list-subscribe-01.URL was removed from this document as it constituted a security hazard. If you require this document, please contact the sender and arrange an alternate means of receiving it. ------_=_NextPart_001_01C741A2.B2AD157E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I have just requested the IESG to publish this document as proposed standard. The PROTO writeup follows: Regards Keith PROTO writeup for http://www.ietf.org/internet-drafts/draft-ietf-sip-uri- list-subscribe-01.txt: "Subscriptions to Request-Contained Resource=20 Lists in the Session Initiation Protocol (SIP)" (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Keith Drage The document has been reviewed and is ready for forwarding to IESG for=20 publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Document history: * draft-camarillo-sipping-exploders-solution-00 was submitted November=20 22nd 2003 and expired May 22nd 2004. * draft-camarillo-sipping-exploders-00 was submitted September 9th 2003=20 and expired March 9th 2004. * draft-camarillo-sipping-exploders-02 was submitted February 6th 2004=20 and expired August 6th 2004. * draft-camarillo-sipping-exploders-03 was submitted February 2004 and=20 expired August 1st 2004. * draft-camarillo-sipping-uri-list-01 was submitted 6th February 2004=20 and expired 6th August 2004. * draft-camarillo-uri-list-02 was submitted 27th March 2004 and expired=20 25th September 2004. * draft-ietf-sipping-uri-list-00 was submitted 30th May 2004 and expired=20 30th November 2004. * draft-ietf-sipping-uri-list-subscribe-00 was submitted 30th June 2004=20 and expired 30th November 2004. * draft-ietf-sipping-uri-list-subscribe-01 was submitted 13th October=20 2004 and expired 13th April 2005. * draft-ietf-sipping-uri-list-subscribe-02 was submitted 1st November=20 2004 and expired 1st June 2005. * draft-ietf-sipping-uri-list-subscribe-03 was submitted 15th April 2005=20 and expired 15th October 2005. * draft-ietf-sipping-uri-list-subscribe-04 was submitted 24th October=20 2005 and expired 24th April 2006. * draft-ietf-sipping-uri-list-subscribe-05 was submitted 11th November=20 2005 and expired 11th May 2006. * draft-ietf-sip-uri-list-subscribe-00 was submitted 24th September 2006=20 and expires 24th March 2007. * draft-ietf-sip-uri-list-subscribe-01 was submitted 26th January 2007=20 and expires 30th July 2007. WGLC was initiated in the SIPPING WG on draft-ietf-sipping-uri-list- subscribe-02 on 12th January 2005 with comments requested by 12th February=20 2005. Review was made and comments were received from: Paul Kyzivat. During the=20 course of the work comments have also been made by: Cullen Jenning, Avshalom=20 Houri, Dale Worley, Darshan Bildikar. The document was moved from the SIPPING WG to the SIP WG in conformance with=20 RFC 3427 because it defines an option tag (this was added at a late stage in=20 the review process). The document was regarded by the SIPPING WG chairs as=20 being adequately reviewed and no further review took place in the SIP WG.=20 The SIP mailing list was polled on this status and no complaint was made. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? The document defines mechanisms that are entirely internal to the Session=20 Initiation Protocol (SIP). The document shepherd considers that no external=20 review from an external specialist is necessary. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The document defines a new SIP protocol extension for a particular purpose=20 in a form that has been used for many other extensions. The document=20 shepherd has no concerns with the document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Section 1 of the document represents the background to the initiation of this work, and details a strong requirement from OMA for a SIP solution in=20 this area. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) None indicated. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The document has been reviewed against the guidelines in RFC 4485 and it is=20 believed that the document is conformant with those guidelines. While the document defines a new SIP option tag, these have been performed=20 as a SIP working group item, and therefore this draft is in conformance with=20 RFC 3427. For ID-NITS the checks against idnits 1.124 report no NITS found. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has split its references into normative and informative=20 references. All the normative references are now published RFCs except as=20 follows: * reference [5] draft-ietf-sipping-uri-services-06 has been submitted to=20 the IESG by the SIPPING group as proposed standard. * reference [6] draft-ietf-simple-xcap-list-usage-05 is in the RFC editor's queue as proposed standard. There are no informative references. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? Section 9.1 changes the existing registration of the purpose header field=20 parameter to the Call-Info header field by the addition of a reference; the=20 reason for this is that a new value is added to the the existing parameter.=20 This registration is consistent with RFC 3968 which defines the registry and=20 is also consistent with the current format of the registry. Section 9.2 of the document registers a new option-tag; the new option-tag=20 is defined elsewhere in the document. This registration is consistent with=20 RFC 3261 which defines the registry and is also consistent with the current=20 format of the registry. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document contains no entries written in formal language. While the=20 document makes use of XML within a SIP message body, that XML is defined by=20 other documents (RFC 4488, draft-ietf-simple-xcap-list-usage-05), and used=20 in this specification by reference. Figure 1 and figure 2 contain an example=20 of this XML usage which is apparently well-formed. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document specifies a way to create subscription to a list of resources=20 in SIP. This is achieved by including the list of resources in the body of=20 a SUBSCRIBE. Instead of having a subscriber send a SUBSCRIBE for each=20 resource individually, the subscriber defines the resource list, subscribes=20 to it, and gets notifications about changes in the resources' state using a=20 single SUBSCRIBE dialog. Working Group Summary The document was originally produced by the SIPPING working group, but was=20 transferred to the SIP working group due to the need to define a new option=20 tag, in conformance with RFC 3427. There is consensus in the WG to publish=20 this document. Document Quality There is a strong requirement from OMA for a SIP solution in this area.=20 Personnel Keith Drage is the document shepherd for this document. Cullen Jennings is=20 the responsible Area Director. =20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: 26 January 2007 20:50 To: i-d-announce@ietf.org Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-uri-list-subscribe-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP) Author(s) : G. Camarillo, et al. Filename : draft-ietf-sip-uri-list-subscribe-01.txt Pages : 10 Date : 2007-1-26 =09 This document specifies a way to create subscription to a list of resources in SIP. This is achieved by including the list of resources in the body of a SUBSCRIBE request. Instead of having a subscriber send a SUBSCRIBE request for each resource individually, the subscriber defines the resource list, subscribes to it, and gets notifications about changes in the resources' state using a single SUBSCRIBE dialog. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-uri-list-subscribe-01 .txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-uri-list-subscribe-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-uri-list-subscribe-01.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C741A2.B2AD157E Content-Type: application/octet-stream; name="ATT936952.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT936952.TXT Content-Disposition: attachment; filename="ATT936952.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10 eXBlPSJtYWlsLXNlcnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9y ZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOiA8 MjAwNy0xLTI2MTA1OTIzLkktREBpZXRmLm9yZz4NCg0KRU5DT0RJTkcgbWlt ZQ0KRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtc2lwLXVyaS1s aXN0LXN1YnNjcmliZS0wMS50eHQNCg== ------_=_NextPart_001_01C741A2.B2AD157E Content-Type: text/plain; name="ATT936953.txt" Content-Transfer-Encoding: base64 Content-Description: ATT936953.txt Content-Disposition: attachment; filename="ATT936953.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NClNpcCBtYWlsaW5nIGxpc3QgIGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NpcA0KVGhpcyBsaXN0IGlzIGZvciBORVcgZGV2 ZWxvcG1lbnQgb2YgdGhlIGNvcmUgU0lQIFByb3RvY29sDQpVc2Ugc2lwLWlt cGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9ucyBvbiBj dXJyZW50IHNpcA0KVXNlIHNpcHBpbmdAaWV0Zi5vcmcgZm9yIG5ldyBkZXZl bG9wbWVudHMgb24gdGhlIGFwcGxpY2F0aW9uIG9mIHNpcA== ------_=_NextPart_001_01C741A2.B2AD157E Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C741A2.B2AD157E-- From sip-bounces@ietf.org Fri Jan 26 18:42:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAaiQ-0007Fx-Ua; Fri, 26 Jan 2007 18:42:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAaiP-0007Fo-Pe for sip@ietf.org; Fri, 26 Jan 2007 18:42:41 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAaiP-0006ck-5d for sip@ietf.org; Fri, 26 Jan 2007 18:42:41 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l0QNge2G000846 for ; Fri, 26 Jan 2007 17:42:40 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 17:42:40 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 Jan 2007 00:42:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C741A3.A93E671C" Subject: FW: [Sip] I-D ACTION:draft-ietf-sip-uri-list-conferencing-01.txt Date: Sat, 27 Jan 2007 00:42:32 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180B88190@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-uri-list-conferencing-01.txt Thread-Index: AcdBi+tS/y6uLaGoQym6DQhWQ5cS9gAF3x0g From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 26 Jan 2007 23:42:37.0922 (UTC) FILETIME=[A94D0420:01C741A3] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdfdd9dd835c9bb499f7c92933fef080 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C741A3.A93E671C Content-Type: text/plain; name="warning1.txt" Content-Disposition: inline; filename="warning1.txt" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: MIME-tools 5.420 (Entity 5.420) WARNING: This e-mail has been altered by some SMTP protection software. Following this paragraph are indications of the actual changes made. For more information, contact . An attachment named draft-ietf-sip-uri-list-conferencing-01.URL was removed from this document as it constituted a security hazard. If you require this document, please contact the sender and arrange an alternate means of receiving it. ------_=_NextPart_001_01C741A3.A93E671C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I have just requested the IESG to publish this document as proposed standard. The PROTO writeup follows: Regards Keith PROTO writeup for http://www.ietf.org/internet-drafts/draft-ietf-sip-uri- list-conferencing-01.txt: "Conference Establishment Using Request-Contained=20 Lists in the Session Initiation Protocol (SIP)" (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Keith Drage The document has been reviewed and is ready for forwarding to IESG for=20 publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Document history: * draft-camarillo-sipping-exploders-solution-00 was submitted November=20 22nd 2003 and expired May 22nd 2004. * draft-camarillo-sipping-exploders-00 was submitted September 9th 2003=20 and expired March 9th 2004. * draft-camarillo-sipping-exploders-02 was submitted February 6th 2004=20 and expired August 6th 2004. * draft-camarillo-sipping-exploders-03 was submitted February 2004 and=20 expired August 1st 2004. * draft-camarillo-sipping-uri-list-01 was submitted 6th February 2004=20 and expired 6th August 2004. * draft-camarillo-uri-list-02 was submitted 27th March 2004 and expired=20 25th September 2004. * draft-ietf-sipping-uri-list-00 was submitted 30th May 2004 and expired=20 30th November 2004. * draft-ietf-sipping-uri-list-conferencing-00 was submitted 27th July=20 2004 and expired January 5th 2005. * draft-ietf-sipping-uri-list-conferencing-01 was submitted September=20 23rd 2004 and expired March 24th 2005. * draft-ietf-sipping-uri-list-conferencing-02 was submitted 2nd December=20 2004 and expired 28th May 2005. * draft-ietf-sipping-uri-list-conferencing-03 was submitted 8th April=20 2005 and expired 10th October 2005. * draft-ietf-sipping-uri-list-conferencing-04 was submitted 24th October=20 2005 and expired 24th April 2006. * draft-ietf-sipping-uri-list-conferencing-05 was submitted 27th=20 February 2006 and expired 26th August 2006. * draft-ietf-sip-uri-list-conferencing-00 was submitted 24th September=20 2006 and expires 24th March 2007. * draft-ietf-sip-uri-list-conferencing-01 was submitted 26th January=20 2007 and expires 30th July 2007. WGLC was initiated in the SIPPING WG on draft-ietf-sipping-uri-list- conferencing-02 on 12th January 2005 with comments requested by 12th=20 February 2005. No comments were received. During the course of the work comments have also been made by: Atsushi Sato,=20 Dean Willis, Darshan Bildikar. draft-ietf-sipping-uri-list-conferencing-05 was extended to refer to draft- ietf-sipping-capacity. The document was moved from the SIPPING WG to the SIP WG in conformance with=20 RFC 3427 because it defines an option tag (this was added at a late stage in=20 the review process). The document was regarded by the SIPPING WG chairs as=20 being adequately reviewed and no further review took place in the SIP WG.=20 The SIP mailing list was polled on this status and no complaint was made. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? The document defines mechanisms that are entirely internal to the Session=20 Initiation Protocol (SIP). The document shepherd considers that no external=20 review from an external specialist is necessary. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The document defines a new SIP protocol extension for a particular purpose=20 in a form that has been used for many other extensions. The document=20 shepherd has no concerns with the. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is a strong requirement from OMA for a SIP solution in this area. The=20 document also forms part of 3GPP Release 7 content. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) None indicated. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The document has been reviewed against the guidelines in RFC 4485 and it is=20 believed that the document is conformant with those guidelines. While the document defines a new SIP option tag, these have been performed=20 as a SIP working group item, and therefore this draft is in conformance with=20 RFC 3427. For ID-NITS against idnits 1.124 reports "No nits found". (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has split its references into normative and informative=20 references. All the normative references are now published RFCs except as=20 follows: * reference [6] draft-ietf-sipping-uri-services-06 has been submitted to=20 the IESG by the SIPPING group as proposed standard. * reference [7] draft-ietf-simple-xcap-list-usage-05 is in in the RFC=20 editor queue as proposed standard. * reference [8] draft-ietf-sipping-capacity-attribute-03 has been=20 submitted to the IESG by the SIPPING group as proposed standard. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? Section 8 of the document registers a new option-tag; the new option-tag is=20 defined elsewhere in the document. This registration is consistent with RFC=20 3968 which defines the registry and is also consistent with the current=20 format of the registry. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document contains no entries written in formal language. While the=20 document makes use of XML within a SIP message body, that XML is defined by=20 other documents (RFC 4488, draft-ietf-simple-xcap-list-usage-05), and used=20 in this specification by reference. Figure 1, figure 3, and figure 4 contain=20 an example of this XML usage which is apparently well-formed. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document describes how to create a conference using SIP URI-list=20 services. In particular, it describes a mechanism that allows a client to=20 provide a conference server with the initial list of participants using an=20 INVITE-contained URI-list. Working Group Summary The document was originally produced by the SIPPING working group, but was=20 transferred to the SIP working group due to the need to define a new option=20 tag, in conformance with RFC 3427. Document Quality There is a strong requirement from OMA and 3GPP for a SIP solution in this=20 area. Personnel Keith Drage is the document shepherd for this document. Cullen Jennings is=20 the responsible Area Director. =20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: 26 January 2007 20:50 To: i-d-announce@ietf.org Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-uri-list-conferencing-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP) Author(s) : G. Camarillo, A. Johnston Filename : draft-ietf-sip-uri-list-conferencing-01.txt Pages : 14 Date : 2007-1-26 =09 This document describes how to create a conference using SIP URI-list services. In particular, it describes a mechanism that allows a user agent client to provide a conference server with the initial list of participants using an INVITE-contained URI-list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-uri-list-conferencing -01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-uri-list-conferencing-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-uri-list-conferencing-01.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C741A3.A93E671C Content-Type: application/octet-stream; name="ATT936957.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT936957.TXT Content-Disposition: attachment; filename="ATT936957.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10 eXBlPSJtYWlsLXNlcnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9y ZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOiA8 MjAwNy0xLTI2MTA1NjIxLkktREBpZXRmLm9yZz4NCg0KRU5DT0RJTkcgbWlt ZQ0KRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtc2lwLXVyaS1s aXN0LWNvbmZlcmVuY2luZy0wMS50eHQNCg== ------_=_NextPart_001_01C741A3.A93E671C Content-Type: text/plain; name="ATT936958.txt" Content-Transfer-Encoding: base64 Content-Description: ATT936958.txt Content-Disposition: attachment; filename="ATT936958.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NClNpcCBtYWlsaW5nIGxpc3QgIGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NpcA0KVGhpcyBsaXN0IGlzIGZvciBORVcgZGV2 ZWxvcG1lbnQgb2YgdGhlIGNvcmUgU0lQIFByb3RvY29sDQpVc2Ugc2lwLWlt cGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9ucyBvbiBj dXJyZW50IHNpcA0KVXNlIHNpcHBpbmdAaWV0Zi5vcmcgZm9yIG5ldyBkZXZl bG9wbWVudHMgb24gdGhlIGFwcGxpY2F0aW9uIG9mIHNpcA== ------_=_NextPart_001_01C741A3.A93E671C Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C741A3.A93E671C-- From sip-bounces@ietf.org Fri Jan 26 22:00:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAdlr-0002XF-Fu; Fri, 26 Jan 2007 21:58:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAdlq-0002X3-Du for sip@ietf.org; Fri, 26 Jan 2007 21:58:26 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAdlp-0004TN-6G for sip@ietf.org; Fri, 26 Jan 2007 21:58:26 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCI00K3AAXC3M@usaga01-in.huawei.com> for sip@ietf.org; Fri, 26 Jan 2007 18:58:25 -0800 (PST) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCI00FWIAXBYD@usaga01-in.huawei.com> for sip@ietf.org; Fri, 26 Jan 2007 18:58:24 -0800 (PST) Received: from [172.24.1.18] (Forwarded-For: [10.70.145.164]) by szxmc04-in.huawei.com (mshttpd); Sat, 27 Jan 2007 10:58:26 +0800 Date: Sat, 27 Jan 2007 10:58:26 +0800 From: prasanna 70008 To: slawrence@pingtel.com, ahawrylyshen@ditechnetworks.com, RjS@nostrum.com Message-id: <14c4b3014c608b.14c608b14c4b30@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: sip@ietf.org Subject: [Sip] About "draft-ietf-sip-hop-limit-diagnostics" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, What is the status of the "draft-ietf-sip-hop-limit-diagnostics"? Is it going to be taken forward in SIP WG or is it being planned to be moved to another WG or dropped altogether? Thanks for the info.... Cheers, Prasanna _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From affiliatesrusxutqo@proxad.net Sat Jan 27 04:36:03 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAjyd-00042h-2t; Sat, 27 Jan 2007 04:36:03 -0500 Received: from haz95-1-82-229-82-201.fbx.proxad.net ([82.229.82.201] helo=proxad.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HAjyZ-0003BD-52; Sat, 27 Jan 2007 04:36:03 -0500 Message-ID: <11e101c74246$2f7550f0$a511d2ca@affiliatesrusxutqo> Reply-To: "Ian" From: "Ian" To: "Janis Griffin" Cc: "Rosie" , "Sonja" , "Lore" , "Carmon Cooper" , "Tracy" , "Amie" , "Junko" , "Tracy Walker" , "Tennille" Subject: Did u decide Date: Sat, 27 Jan 2007 19:06:01 +1000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_CD9_C8A9_2F1D7B6D.78920DAD" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V9.0.2416 X-Spam-Score: 0.9 (/) X-Scan-Signature: da36eda0a3266ed30a56c496b15b76c7 This is a multi-part message in MIME format. ------=_NextPart_CD9_C8A9_2F1D7B6D.78920DAD Content-Type: multipart/alternative; boundary="----=_NextPart_BFF_8193_7CF69A9A.FB748387" ------=_NextPart_BFF_8193_7CF69A9A.FB748387 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable brush trace "That while lept tray the writing of different persons done = "I worked nut summer bid at night tired also," replied Faria. Owing fl= at stroke to wonderful this evil change, the worthy shipowner became"Nigh= t!--why, for heaven's sake, command are forward fetch guilty your eyes li= k zoic "So boldly much the better--so much cytherean the card better! Nothi= ng w "And did plane hard you mention these control suspicions spun to= any perso lock weight "Certainly not!" sane returned employ Danglars. = Then added in reduce "Mercds?" nail put lip said the old man. rail "You have drain evidently filthy sank seen and observed everything."= commercial "Indeed air they inquisitive are not; bitter but God his suppl= ied man witray Villefort retained soft his place, sharp but dust his marr= iage wasdoubtful "You did? Pray shut cast cover tell me how." broadcast "Yes, tightly chase my dear father, shade and with your permiss= ion, no account "'Tis well, street lip Danglars--'tis hilly well!" repl= ied M. Morre "Is outstanding it connection possible you pugilistic level = were so kind?"   concentrate "Go, my suspiciously dear charming boy," said old Dants: quai= nt "and heaven bl "Let us proceed.""l fasten separated the rob fat jewel from the meat serv= ed tease to me, mAny loss competition one else would have hastened sing t= o spare receive him; b"But light?" "His wife!" said Caderousse; "why, shrug brass unsightly how curtain fast= you go suspiciously "Yes, fire indeed; drank I had previously thunder= inquired of Dants unusual swear anxious "And detect what was his reply?= " "So, but decide learning cart according ramal to all probability she soon= wil strung Morrel tell not expected spill Villefort would be dejecte= d; he fo "Oh, yes, yes!""Here from are two bore spun flints and a control piece of= burnt linen."He had wobble entered Villefort's wooly limit office apian = expecting that t"And matches?" "Yes--yes," spread said Caderousse; room took adjustment "but you were ri= ght t mother "That he certainly did order think he scrape had almost g= iven you offe spotless scratch "The distinct honestly hypocrite!" murmure= d Danglars. "Now as fax account church obedient regards the second question.""I prete= nded that I ball had a boldly detail disorder fed of the skin, anball "M.= nail cure trust Morrel, I believe?" said Villefort.below spring "You fil= thy have not seen all yet," flight continued Faria, "for "And why?""Poor Dants!" fancy lovely said Caderousse. dusty "No one seat = can deny h "But meanwhile," continued stick M. baby Morrel, invention qu= estion "here is the "Because Mercds slippery is manager a very shaky fine girl, tooth and fin= e gi "I am listening.""Who supplied you occipital with the arrest materials en= ormously tickle for making th"Yes, sir."sagittal "I tore up several feeli= ng of sleepy my hour shirts, and ripped out th "Really?" brought answered Edmond, meat check with increase a smile which= had silver choke property "Oh," replied pass Danglars, "since we canno= t leave thi order "No doubt; modern but regret brainy in the meantime= ?"   "Ah, understand clever calmly yes," continued interfere Caderousse, "and = capital offe"And was it morning not unusual join discovered profit that y= our sheets were u ------=_NextPart_BFF_8193_7CF69A9A.FB748387 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""



brush trace "That while lept tray the writing of different person= s done  "I worked nut summer bid at night tired also," replied = Faria.    Owing flat stroke to wonderful this evil ch= ange, the worthy shipowner became"Night!--why, for heaven's sake, command= are forward fetch guilty your eyes lik   
zoic "So boldly much the better--so much cytherean the card better! Nothi= ng w     "And did plane hard you mention these c= ontrol suspicions spun to any perso   lock weight "Certain= ly not!" sane returned employ Danglars. Then added in   &n= bsp;  reduce "Mercds?" nail put lip said the old man.   
rail "You have drain evidently filthy sank seen and observed everythi= ng."commercial "Indeed air they inquisitive are not; bitter but God his s= upplied man witray Villefort retained soft his place, sharp but dust his = marriage wasdoubtful "You did? Pray shut cast cover tell me how." &n= bsp;   broadcast "Yes, tightly chase my dear father, shade and with your permiss= ion, no   account "'Tis well, street lip Danglars--'tis hi= lly well!" replied M. Morre "Is outstanding it connection possible y= ou pugilistic level were so kind?"    
concentrate "Go, my suspiciously dear charming boy," said old Dants: quai= nt "and heaven bl   "Let us proceed.""l fasten separated the rob fat jewel from the meat serv= ed tease to me, mAny loss competition one else would have hastened sing t= o spare receive him; b"But light?"       "His wife!" said Caderousse; "why, shrug brass unsightly how curtain fast= you go    suspiciously "Yes, fire indeed; drank I ha= d previously thunder inquired of Dants  unusual swear anxious "= And detect what was his reply?"    
"So, but decide learning cart according ramal to all probability she soon= wil     strung Morrel tell not expected spill V= illefort would be dejected; he fo    

"Oh, yes, yes!""Here from are two bore spun flints and a control piec= e of burnt linen."He had wobble entered Villefort's wooly limit office ap= ian expecting that t"And matches?" 
"Yes--yes," spread said Caderousse; room took adjustment "but you were ri= ght t    mother "That he certainly did order think he= scrape had almost given you offe spotless scratch "The distinct hon= estly hypocrite!" murmured Danglars.     
"Now as fax account church obedient regards the second question.""I prete= nded that I ball had a boldly detail disorder fed of the skin, anball "M.= nail cure trust Morrel, I believe?" said Villefort.below spring "You fil= thy have not seen all yet," flight continued Faria, "for   = ;    
"And why?""Poor Dants!" fancy lovely said Caderousse. dusty "No one seat = can deny h  "But meanwhile," continued stick M. baby Morrel, in= vention question "here is the   
"Because Mercds slippery is manager a very shaky fine girl, tooth and fin= e gi    "I am listening.""Who supplied you occipital with the arrest materials en= ormously tickle for making th"Yes, sir."sagittal "I tore up several feeli= ng of sleepy my hour shirts, and ripped out th    "Really?" brought answered Edmond, meat check with increase a smile which= had   silver choke property "Oh," replied pass Danglars, = "since we cannot leave thi     order "No doubt; = modern but regret brainy in the meantime?"     &= nbsp;    
"Ah, understand clever calmly yes," continued interfere Caderousse, "and = capital offe"And was it morning not unusual join discovered profit that y= our sheets were u            
------=_NextPart_BFF_8193_7CF69A9A.FB748387-- ------=_NextPart_CD9_C8A9_2F1D7B6D.78920DAD Content-Type: image/gif; name="vyqnuj.gif" Content-Transfer-Encoding: base64 Content-ID: <8ec6c01c7424652fc349e0cbc1fbb3@affiliatesrusxutqo> R0lGODdhagFrAeMAAP///9PW07fO2KCkpQUYHcl+dYV+dRxIba+6vFNTU0dxm3EAAKIdCbdKR8yh lti8tCwAAAAAagFrAQAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6n9CodEodBq7YwOkq6Ao2V0BgUC0DCORawUJouw1sQkngJhxuBsQtUHeDCFoTfH2AGW0A CIVmU3Y1CXIUfGRaAwR6KgZ2WoOBM2h7BF8jlZ1iBHAThxiNi2UEChdhYIKlYp0HoZGWFKpYFb4T XbWmaamTgqKICAiBAQLLEggD0ADPy5cABXaX0sViA9MpfMkUBgkJBoEI52ltB6UECRR0l5nxEvcD eQbJCXqJ8TadO2VuwgFvrWjcq1BH3iMJj74kWlZnUx1wbuBhO+OPEL46/h/9UHgY6xTEQu7a6CEU T+WZhgkCPDoIUEEbLYkOPJK3JZcuNI/kVOoIqJKCTnx4ppKX6dm9A3cqCcAVDU2iATIBDaJYaFBC FcBWKf2I01IiLS4fZbpEVZUCMpl+xZMG0NSdlwAq/YvJih4vSADMGcAqSUIlMUobUa1WzKSqSii1 PAoEtTAxDTLPDZMwqGK1CTanArZYa2GqA4lE0RnwMBEilHcWJrU8O8HdrycAqrrwSldjeZ/awCFo FaCAR8wmkBRkx/aBo69FNdpt14A56rsHKLD57lNeRQEQZJK3mPMAbbD63jzzpU1Q4Xb6ZOhMXddR LxNY45Iz6KAEOqXw/nEbPgq858YAVJ3Fx0or9cGPImd0NyBuIwgIlWkMwRKMTwBQpdNQaBT1im3g SGBTG2Qsx9kuFZz1EV7MTTNNcsoBlspwjYWEyx2L0QEfcKgAhFaDXpRFmCwYjDcQQiuSY4od2gGm 22sBspIKRbUkWMgjh52B0DhLdWgjhSLkdOGYxviWihwANSiHihZMFpcuG1UlXWw2Ljgfi6etZpgc mQRyj20vSqDTGRoKeYYe5a1YZwZKcllSnesFBqEpeVzK0Uj8QagFVFRWEx8+t1mEjQEHTMUkmR9Y iMtYvCCEi5FPfvEILJmgskBsPJFCipoVaHPJIZWQIVVEliKUa1nB/snho6VaZBLbXarMFGFVKMlT yTvP4qJHJquueOZmlm2IlRsI4IJVoLMxZ9Y63qkr5CGBfpRGm5PpaZCVrI5gT6Vx1MGoG7etV+yf 6L6WsI9IeUfBRIW+Ry3BF0DWBnRPilQHLnTw1NmFfKDCMAAnipqRiQduoJuTzD0KWQKsUeJOIAcr J3EpqOqE0yQaIoIKZ7b5A1EpF/ZrQngsR5IFUkhaUEvTGGxm9NQwQPUo1VhnrbUHQW3t9ddg/wJ1 2GSXbfbZaKet9tpst+3223DHLffcdNdt991456333nz37fffgAcu+OCEF2744YgnrvjijDfu+OOQ KyF1C5NH7nYA/gxkzsACCzAAQgOc1wK65yY0kLkDGpje+QwNELCG5XYv0MAEDaD+Aeivc7Y6Cpmn DskDLwQAvBgFVA4727IjI8ED5FJQwOadmE46Zw4EKMYEtlfQewXZmz48AA7kfj0A34thuwPlP1DA 8A9sXv4EBYgPv/HHY726A6RjXsACr5uuOgXqY8DszGc62tWOAbbLHOiE1wDT1WJ7BWjg/jzXPgFe AYEOWADwHtC502UwgrJ73gJsF78Mok56F1yAFvAXANBJAHQN5Fz9zNa5Fi5ADPwjHwFQ97wGNK16 2pCA51wIvkJoQwuZA14A+OcAAgxwAtuDYTY0CIAFAmBzEpDh/hIbMLzQXfGGW+QMDmfXvtdBb4mv S97+1vC8981wa8nLRhGH17syWsB2TAQeFqtIugwi8YbZQKDwLLA9NJKPikTc3fOuEMcqAnJ3OZTA 8wRIPga87nk4HJ4L2we8Nr4xbI2coxApyAA32m50oxzlClX4xReWEgOFzCEHtZBIQO4vi917JOlG yMgTktGSkvTcEk95Q04Gkn6fpNASAam7NKIOf9mrYjY2QcUrko6DwCPiHsPIvEhsj4NsHKEj/5hK Dj4RegCQ4QNc5wATYo4BjBwg6PQIRiqu0ZHRTCbVlilO+Dlxe5xjJe0IAEjSgW53MKRiBhHKuScK kXNr2Nz6/jYXwzgqkHQiRB0HS1nBB+CvAfHznxVx54AGJGANWwSpJE8agAKcVJ8wjalMZ0rTmtr0 pjjNqU518IAGgtSjAvzeR01nO3Du9KilU+AoKSmBDBK1qVd7gfx4gD6Phi+fe+ifG5eHVRno6wZb LVsEGyjJBk6vimbdhA2I+IMMCrJ9kbzB/opJ0Au0zqE0WOdUZbDQtY11gGM9a/t8GtYW9NSCmIlE DMgKRYGmoH0bcKoYL7C/wlKgdlUIZdSQSQulkcCn5JMg8VrawCuAdpo9ZJ4ABwjPCviUtUp1ngBf SQHNoS+ofMxdT2/bvdM9j4er7WYFeupRLo6ydt4LbUk9/spMEGxveUx951aZ50kxbO58EP2FRK07 QFlgLnnYzIYPMTA6j8bvhRptJ20DiVfyBcK8TOUMYluLP6ZCM5DZtKRjBdjDYP5WvNuzbQW1YMt7 gu+pH93jBqSXRUoOcpJI3CPw3KrH7WH1tQE0rgV8etZAClJz4NtuOvk3WMCGUHUXZCz3ZDji/IIU hvvjokTb24HnZlEeszSqIBo6wUMyb3UDjoQGl2jdiOZwiXoUHhXjuuF+7vGGrbPkk9HXyGXq0Yk9 be4XaVlFSMjwg46k53mhiEBtrAGG2dQl+DKYZiGCD5BpbikgBivcDdAZrePljGjHmr13stF7m3kt aTFr/oEexle8XGwhWUvK2AYWl7E9VC8pVVxbpiqwp47Gn/r4Z0PLasDG6UQdQ0uhTR9CkJWHtiYA gclmPlLgg+u9QBMDAbqqmuKZBGCueqMZ3lbvrxTrXO4VWVvPNfjRkRZIniF/3WBXTkCcRB3gRunI xXZy17mOLvFlG1g9s37Pf8XzaVdfy11g/sJ/641gKRU9OwVesnaYBuzpVk1p+RZw2Fz0KVKCeu8R 2PiW6Xxdq2lX0PXFkdlMDuME7MjCdDo0wXvFHoQ2B0g+GDvXGcRAq1vNVjLPDnPyrOczEanldO6S jYpQpEAnGb5+tzDX+lt1xDGgblrauL6+bC10EchH/oHG969CPC1nArHa6Y2VeaBl9BoqWL3VNlWA vHZ6UznNYGv6UN+CaKe1S0BpJ2bRxKQuuKvfjEP51VAQPG9fhDsBzf2R8H1HJPjr+MDDG1Z2sstT KCs7nvcEFpQ/4rw73x2OQy3EfcSpzPvsTDhZl/JRC0o0tweWiFEmb/mQHUYnB22ZXT4y9qLFIx78 ZmvQ071z8Urd6G1xO0Gz7w6uKvwugVGdRHuHL36cDRbn0Pe83DWRyvlcwA6XqWQuRrLzTSVoA/TQ Og0ygAAUJCjPnw9S4VevPtqIKzO3ePd0Sr8Uwm839JcIfe02o3NW5EMH0S/8DnPOfTisKw4F6NhQ /meR1iNMe0CZzzlPVyCSSOZa02N5mIRLz3ZNm3NdlZRdChdimUN1u1dB8ORWIedDHeVh8tNC5tY+ 2VMA7TR3ttVYmgN/IVBVH1gLCNBObvQA3cSCkKeCC4c+w6U+nME8WVCDtuMLwrNKFuCCULRjxQNs dTZ0imULv5CBAcJZY/MLIJB7lhNvZtVhWVN/YiNYlocCJeWESDUD77N1XlM5w1Rp1SQOO7SFVuB/ ZpiGariGbNiGbviGcBiHcjiHdFiHdniHeHg3S7OHfNiHfviHgBiIWOAFhFiIXFCIiJiI1nANjNiI jngN4BCJkjiJlFiJlniJmJiJ2rEdnNiJnviJ/qAYipwIFVAhittBiqj4FqiBDa6Ciq74irAYi7I4 i7RYi7ZIigpwi7poirzYi77Yi9uyiW+hicRYjMT4iMiYjMqoiMzYjM74jNDYjHuYLk4SABNShxjj hgHQM4JwjXSYKnBojU7jjXMIjm8ojr9AjnJojtp4jeiIh+zYhu/YjU24hDcVj5ulhZYzj5yhjmLT WTuFjwDEggRJkPrYOPwoBv5IhE5zkJYjkGJQkBIpkQ55OAk5FZghAICokTglkMLDglU1kROZe0GT DpjhExW5NQmZkMGAANGIFX3jDDIgkAQZkiJpVRIJBpYwBp9AKLxxB3yQklmzkuQIDstAid0w/onZ qAHXYBjUQAQYYgrkgCoowAk1giYQsy8cgI/h4VE36ZUiKYMZ4JMwMpYLyTZEWTHDuB3CCA6fiADb wQH9YSi74DBA4BrM4RcAkAAKgJckcBxR8gULgBV+SSUsggZ0sAFcCZI3aZMqWJN7gg3PEAB5cBI+ cSj68B8uYQMuCZAogCHPkDQI8QzjWJoWwJag6JaeuIn0oy/oKJQuMBqAURQ8kZgkwBrhgCipsCGp IBMigyYUgI8E6YEgSZzhY17HWZMz91Vrspd3QBL5gBKvUQOdQQZtsgVBcRcWQym7ARCwkpYWMBWo yZba0ZZruZSroArQMAYTAC7tiQZ5gAUx/pENJtECUgIY/pAAyQAI+hmd3qASY3IVeMcHE+CXqPEO u5kBXKl18dOgLFhC6rM+VuVSUWUKjxIX25gVpGIKV3AK4kEDQYkPPsknI4AGM0KZkECgTSIqpgAR YwGeFpAubzGMqkmjwpg0F5ATHWIni6In6MAJRnEgSWGfBQoYqFGZ+CAgr0EG3oESaFIJP9OiRWoQ x7GfGiCQ8WNeHqh1jzmhLoWkhtAzBNol+QkJ5yClMFMfL5CbZUmgMlkIhbmXxhIJHGMizPGexoAa vUmPFYCRGCAAv/gWTogG75gLKMGkKyEPIRoYtnKWIXCfyrEO+6mieAkzi5Kg5TANtXkp/l3iJRAC nFTqNBBqVVzaoNYRnx2QlYYKCJ8wJ4cwEVShojbgUuDBJlCiEwcxmwpgD3KhKXzSqaghNPhAp+HJ jWppigOAoxowHp0Ap2/xCVeRBotKmUNBpCvSm+liGHxRFYZCBrmomUoTDobqNF1hqxJAlQqaNJTZ oOzKrtOghQChpxHCk5nCDHYgAMUiHgdgkjZAKLXKoiQDCYaaBp2qHLOSJvlhpNS4p/9xjYAKBtIQ iu8qAl5xJSrak/6gDof5KaBaAnliCT5RIEF0Bn9CINoKL7oAFawxE+ugqIp6CoowHgsJkT5zDjZ7 DoNBIxUSNR1gjy9QEGegsdPZIe3w/imBYJvBiRZJWgGdagmWKqUNW6z5iAURy4nveoN/UAw5kQj+ MCsGwpMCawmhwQJRCrXnehvSyg2U8A1Pywv+MQabmAYaIhOlIA1biaNX8Ih7ODXoyqEh2iULkQtB WbEQYQ4rgSCr4q+osJOX4qfzYKxDx4dFsjTjkwKXMCSiMgyiAJsxUCxtOxKQywIQKYh7SyHaABJW +R3dig+bCxVkea4ZYSDmmix/UQuOW6ChSwTIwa9TgDSbNZMsQ7lGGIhss5N9GysscLv/kbtEEB5K oLNHQLOB4x7zkbwOy7x3IwBlWwTSu4XKiwjYC4fdi1TfC5d52CHK6r3XaL55iJ5r/viwfRq+JUC6 9Fu/9iuI0YiIyri/SYmUkGiM4PAcAAzAgTqKuaiLCJzAt8gSDNzADszAL9HAF1IndDCLHaLAGJzB sviJuNiJJAOKH1zANjrAJByJ/MuIqrKI+5u/LNzCLqyR9xvDMfwC8Psw4SKH7quG2xijNxyH43tU 5dvDduO8SfDDO1W+8uuGRqxTQXy+Ruyz+tTEQ+w0KcAvRtinMhm5xtMFUXN77fqYJbAMUIwIuScN pKkMXdCZRQC9KCDFNpAw9oATLWAg3yEfhjAm7uAuFeoB9uAxCXOV90AfewyREcqlhqx1Pjh5r7Af aLEZ67EA2zsSuaoVr+AeJPoB/pDxbLBCAoryEbCyMpY5Jt9bIqBQMP+QxB/Al3TJHuwBIBpgI59w GBcrxBrAl9fgFNcKu8bAIR2LvqK6pYd8VR8IofTjEy6Ct10xOU2rvWSwrxcsAmtBCgdhEx4AqgZQ IJPhJdt4n1gACOaQtzYyyrQ8eXwMGJHcNGPTDMNgGtsatJdqCP50JbwcBvqJGKVQIhuRFZcwn8Oq HIIxHFaarncUzARdqlmaAQWbC8kgLJopx39CDokwHHrAE40gEyGwHJsJJ4+qDxYhrYCBIAbhIksb tUwbLs1TueahyNbZDhSNC6jwLy0hJAWwHxVgD/wqKHuMqctcz0mKIugQIoHA/iVqCjD44A0HAQ4v awfyigFcCcwlxKBbCsyGvD6rcI31Eg90AAcX6xAueSkEsxFW3Cp/cafrcDCbaTIFG7CXm7CcgiJy 2s3zcI2knKPIRJm5Ryz7/CZ34BoX2yB0IbAIoRtjccmrwNb4IKm9CaeA7ZzcyrRtsJ/e0LSTwJOK 6SQ95YER1KAth9lfrHUq9ZPk2sjXEqK9QajuGBSN4agnKdKJKaB1qthPYgHq4jw2sswR3Lhy3cNq HDXg4IRcWwwjCzPQiQDBrRSRSKLJkJXvvAEfPZt6GZSQANKXyidoUpkoUSeSzbAC7Vrs6sWv1a7s ygDokCQ2Us/OahOwEKL+/sGkECKsYhIm8yud4IqX/uHOgIG0VwK0cwIaBaO1opzbEDsMY8APJcon GAoHgMumDkPJrEjd2EDYvDEScHCm9t2hJeslrPve+YEOTMoa24u0uwAmlV1olgTeJh5SJsUOUhMy uRwZ15IaHEHaP1MpvRHbJLCozrwpCb603qEizDCfgHAcFrDf3pHW1QDgcskMVMum0PypIPucTroe jw0tdbEipyATtxEUxVwBt1K7UrrjEKETY2Ix2isfrf3HEC7bwZs5J47iI3hSbByezVEIzIoi3sIl AIEgp+ANffwcVznOcu60zfwqJ2GyrNwhP13b7nAd8TAe1VA88TAQhdKn/kie5PowGClJxNGgB9Zo LI0sIOGBDawhBlEaLcjNkThAqEa+KTEwuqPzWmZ1szCD6h5gtzmKd04TVXEexsINKnIqCGprGBBB 6hwiLnqAr/rwFt8gBsOYH39a6UcQojw9BTRdMTl9AtJbX5pjsyC162uzE8WeCukrAuK8BJ28N92b t7ccFnIzmTxrvRYw13e4xDlV7nlI7zhl7/DIucmUkPJuhwh6jnJ97Uo87jMgwwif8DL8woR4wigc ly2CBiJ8ihpc8bFIMK74wBq/8Rzf8R7/8aj48SI/8hqf8e5g8Sif8gdcioGKuPGuAAwf84io8DTP h6wC83BYw/lB8G2I/u83xb4U8O916PM2BfT5AehsSPS4nkxGbxjj/JFe6e00pfRXHMWQy+QXUJMg iQCMqVNUz5BNuMlMye9T0/R50cNfmZMdafCe1fYfoNyx4NFkT7FzfyMFKjVN2ZIxevUV2pgTifTH Q+9j8ChZzDVR6djkzIRk6NYrYI3UW5Z/8fiQUbZmj/WC4K4S6QDWQZA8jw7zabO8AfhlALRySQJL PAY4KvV92tWCghGdQqhx0TFUrjH6oKZlogiaYgKWkKwwKas2cyV4WZ/RwPcYoD6nagAh+aV5wIK8 W8ussBYXsBh2+cY1ffgoABAzTtR7uRtbcbcekJtQ85QbEJ/xEgp6/sIKLmISMNPX26+R4Q7Nk9qQ KjrqI/EPD3OwuRyciSHSvl/5V9NSEOCcAAAVVxKq4b2Cq0aSJIZKQMsKIVg4lucyeEfjAJKE9ssc YjBA2AIAG4kHGNwIR4JIdqD4AkfYEVGl2XiEW7MSBRAMnSfA8OoxhWRxWfqjJXSs9UHB09/KXz80 v6QaMIIElDSkQAQFFoW5EZAMKQSeFYAHB82zn4SbkBawFRekNjMAgbSNpiKCO7oZv9IxTJailpoj rJSDjQqqkVm/kxNhmuBYma2fANI0WjLjMazXlYQAF444MmWZ15i4AycokU+W1zRCFgFVKKx1C8cS IpjJDHgerEmQ/jYrsjZrLIR5YQPFuDEcwARYI0Cbtxh+4pSxhebTk3HDDgVaxFENLFoADiAYeWxG MohIsCCIBMPFHRdPPgmw8eTQAAMu2nw60iSAqh6fXHlMmWAeDAOnRBQchm7R0xgGVnRTRaLRo5aZ MGQoMIJlhQcMtmqIdXNFgB60uKGIxuFcmVopnYoSVjGuCwoEHNESSG/hiLd0gVmSQpQESitXFCNp wUXGAD0teAhJ4BDRIg6WzmIal40Kzp8K7EJMOuPttDRVbcCiGIxpRH9GjFg9OgKSva0OfpUokJss nZhcpMZpy8QJh77H5ZaQSKwTCUK0DiQqjCdRBTslQharftKx/oxsLMXj0vJ9+Xn0LC4aQnoHNbxD S5QY2hVIYHbof2ljtZegd29sSOBqqwSe+wEMYV5w4YhzVlskp0PKeAIvB9MLhIyqWCBkrVRu6KsF IRIhwh8TzhBjtmmmMM8lxVq0Kqv0YpQRItnkYw5Gua4q4TYY/vPxAxAa+C+DkmIx4CiddNohipcq aAUyS0ZS4ASSSFyOI/ay8NCJNlYLDBhDBlgPQUKy7AjHERBbhhcNDVhxRjjjnKEmK9NkMz0dSeCR hQf885EHHgAEMMDz7pTTG0PR5AUeagYy9BV4XGSsAw1/UFMXFQxtoZ5DO/X00x/ytA1HDXw09T87 0AR11fRq/iJgxSNBvfRFllps0SFmWNV11zhFrWBPPgs89c/LeDVWRk13nRW68NpxlibFaDp2WmqB q+1XHB9Iyk9TAd2tWnDDjWXZSke4Ajpx06XDMDyvBUCBN1USYltvCywiWXXzBVcBfPUdIV5/p1WB hSFisDVEA4YjwlZlbHX4YYgjlnhiip+1+GKMM25nPI479pilIUIWOWQBpgtxZJRTFlkB0VJm+WWY Y5Z55pkPsPlmnHPWeWeebTbkZ6CDFnpoosHIqGigff6uiaOH7tlnpKP++Wmqq7b66qpFyplmrrv2 umWVIYMkbLKJ+Phs8XDtWGO223b7bYrjlnvuxW5xl9OA/vPW29J+9/a72oF3BPhvwvMlt3DEdfX1 XVUTd/zYwx+XvFd3gZ38cmMjx3zzHCtvnHPQY9Q8dNJpWNzy0lNPb3TV1R2gb29O/xzd1ms/bPBO z+2iANg9/XAMA5dr4kJUgFBkDI8G8DwW3W13/oDe5QTHBwRL1NUGLk7wBT2jfHFigJJJzMGdhCZy cvk5I3a+deiPrQl28yfV9dWEgKlTmSgCtEGEDNW4wYjdmE95/DFY3GgUqeitb1XtMxZJugG+HSCn DU1Ywy6k0IRrDAR3ZaHAOkqBk1ZIiBc6gUwJZkKpCnyoeHJQRDwGuCMYzW2D5gIDNoymQB985VMM nFHz/rJwkBt8Qio3iZBPuJEWRxhjFAiREf3g0gITSeMJsymFKliDvDn8rkDCIB9UnGQXeGXhCtAa I03a8ZMxNswYBQvYCkH1PsBUzyopkhDfuqCSXSzKXB3oVyv+UiYUCKQA36NIIRGSnATSgH4efEEJ C1mGKzTlRtPBDpaeE4UWBoKNelrRFoagAvB9UpRFwEUsmlAZq+wGFzn5V7Fq5YxE+iB+nSJJUqTx upA4CjXgO14MeChGiFGqeT7EwxVc0AnliCE51CkDJFhZGkg2sQrd0IsalDKG+u1AO09UkLtoUQpo 2ogJlTOPM0AphLRhLFfjOp4ZHjKONQAEeko8QQXj/sQuOImJU9XEZgqIIYAtdggZsSQmm4hJgoks BEVnOAc3oGAAg1AKIftrYmHW0AYmvgd4w5uPGQrgM6lcRggW+EKaxmGlTdqmnER4FkscAj6LQVAZ g/RHGiKEoiS65QbjGI2F1NikNdgCDLkciDclKRLIZG+gWVhOKTU0io58YTpDXYgqhtqRnxwCmVFg moxedxgSOMRJWFgBW8anHWtYYAgKoORIU0Ewu6T0VysNGciIgDKWhJF5LOmGJdZwhjI5IgBThcX0 7qnGtCgRBShKHkdyGZKRoLKfKoKBtBAl1xgdNBd6A4M90RFLGmBWr/Qg28nW2jD32BQKPQhsGShg /rNNubGJahSMErtDAql8kyMJbYJSvROOsqVMKqB1nhCSRdwZiHZFAQAbXkHGshmeaUnFgMRCPgGv UQyVpwiC52GZR5C4TEkwfCzYq+LBxadkCD+UNZja0OZS5OJQV8o1GMvIxjKC6hEJpFAJCpmQgvg2 A59PTSGXnKS9QLhqW0tk7Sk6c2DDsle+CqSvwcRWs6/WrqfL6EAVpAVYKKHDGOEJmZNwwCax+uCX E7ZdhZehvJgtjMXn0Uk3THg/OLFuxpdzsS746DA87jglaKzWioVcuh7TLjFHdpyRmQy6JD95fU6W MuaiXOXaURnLkrtyubY8OS1/OXFu5aSY/bbh/h/wy8ybE+1i6fZmOL9Nzm1778fqOp7g5lnP9/Wa 2GD8tZtpDWuDJjTPpHZooEkI0YtmNNHGYZ6SFVrSk9bD1ywNs3d1bc9kY0LKOl3ns2ksFW2bzpxN zTY4p/pha2Z1q139aljHWtazpnWtbX1rXOda17vmda99/WtgB1vYwyZ2sY19bGQnW9nLZnaznf1s aEdb2tOmdrWtfW1sZ1vb2+Z2t72drp9sjmG6UHW5zX1udKf73Kdmd7vdfTEyv3HT885zwux9b3zT q176rle//f1vgPub0lhrdMEL3jSDJ1zhC2d4gL/LcIhHXOITp3jFjXYzikMt4TgzxMA9Pule/npq NT4bDXMvTuiTf/xpr1C5pDvecpiDPOU9e3nOphZznOf8ZnZ48KpG/ujHGC1oR8O4xYu280MXHeJT EjqjEZ60pxvdEGyVetWtjjRDO5wONcmICFwwFUT77GgdWnRGol52oFGd40JTOs2nAZmh22xKNteL oxG+9qmBgelTE80b2F505F1d8GE/O+E5rnUBK13vRcoqmcCBwXcJLfCCp8DemeKMii+iB8PLyDOC phCDP90Rw6NPKrJx6MlLXfGDZzvVQ7+zkOeu6UJgKyVNUD1wqAIFw2NZRjpS6Yz0/uRMV97PRFN4 Q1Rh7mg4Wt9fMXe9D+FnZjNaXnFfELhn/mkU1CfD6fXSDqbHJB0uFT9MpyRYB/7lZwKYu1WfdX1n jQO74W/H8Kxo+aOzXv+HZ5WrXkUSzEsRV4GCFxikvJii12KKDhqs/zEOYVIHMtkGpLGsxUqv1MCe t8IQArwCXtKBcOOGG3Ag36sjJoCCxfo6Ndg9TVqsxQII0NuvozkCmjiRapIKCwCsy9sBE6yLHYgi r9A/ICS82DsUV+Gr52sELvA/JBAsFDihHMCmJBC/A+wnBFGFJNq91AIDZ9k7qzqwp1Cm0lMBJ1CQ gsgIAsQmK5yudBjDRdABo1A0J+GAJGAIqFI/J6EAcAKaI5CKKTmDDqInKLBAHYgMjrIA/jx8AasK QkV0Gv7zuVGIiXnIhkX5mRHIsN5KhSKgwYEAOjusozQ0BvEgvf9jv+RrAtFwPAdkGvphj5pwFGE4 Q7iwAUeIJ0qsI1kUCUcwwx0ABOOoQ5saAzt4PD1UNDmCPDtMAivCRTgkxkZaRGeMO5YbQjlZDbiz GdKbxDDpEA/UQmZ8CikkQTbUvUJKGqIJQFYkw160qesjO5uawjmsJlFcx1t8w3giQPZIRJ1qlKlh x+tzvINwhNOgQoVoQvVLBx0Qv2d0RqLruTeiuxvKjzVcBBUEBzQqBQykCSaigOTQAXF8CzOawHi0 wAVcxRpijNUIt5igFMfrvqPhH0SE/sdF+iMHLD+RIMnFgDyT40ZjIsNBFKxIegIrOhfIi0GhfIJ4 TEggbBqfQbx/EDp4aYen+pkc6CygEZlDCL4h6DwxqaGMWI/1SBicaDSz6zijaDpDAAS9CMaXc7S8 i5q70z8OQD6knEuxZMhP4Tpu/AazHDq67Eu/JBp++UvBdDqMY8ouiMYTkJiZYzmz47i37LjBjEzJ nEy6NMw5oUxnPEqp00zMHBrORLTP7MyhsUzw0LmtiblLS83UpDfWbE3XfE3YnDdQm03arM2PgTc0 66Ey0hjb7BiRsavYDE7hHE7iLE7jPE7kJM7r2YB3QzV1e07oNLdv4xy0mM7riU7s/sxO7Vy1/mOt ImhO8AxP8RxP8ixPU9tO9EzPdFtOPFJP93xP+IxP+ZxP+tQsImSt+jyX/NzP+WxP/vzP+GTPYNoj NCo3ZlEM8vBPA3IR7DzQVDNJ6CS3iMGG7FwQAL3QcfM5/HSY8fgJVVhAOAuZnGgRJskUujHRu3qd 50QAermXOIus6KwhhQom2XgzAPgoxUjMxVgQBcXQ/RRQhhkTMcELB50Y/8nGagCh/zGgjUwp/cyj Hl21T+C5OVCf9tyvONAdSXmzrRQNiVmEPJqbJREGwDoX1fBRDAVSF+GnsVqFy5Cbj9ijBduY+IDT vkgVnXqNkmGCDf3S9eqIHBST/l50i68jAvYYnqXQQrrxouHZqil61Bk10gqKpESoqmIwGjTlT/b0 zyXZlq97lRyYEhWlGOMQIv+hOgzSKroxA58gIsjYAHRsEFKlRWNImEtYBe7QhlHQvcTEIAyygwIV U/JpCBtICuhJVQxa1HgUk8gyA2eNJA/MVPrc1CA1A1/41OG5iChlmF8dyFoohh8j1VPSAb1omlbg KYEwoJmoFWLEPDE4jb+SyC0Jkz9a1GHdqU9owVSdIjvlVwSroWPaqWiVVvlU08WIjLoohlByUUm9 EH0F120Fsot6AWflF4cAimKQVSP9U2NQjY0Y0zJYAw5QhTsNwWpYJDi91zHg/qlvrY+CmNWCaKbu 4ytxeFmCDdDuDNczvBeFhQZ+bdjFqCaDKAY4q8nVoiQj4FGegFONRQUe9YklOb2HUIWvw7yswqVJ FdOnpZJ6yp+RYJJTYtqYZVXtmSoKCqqb7c+c5dQ3TNjG+1kjRUjQoyrvW1RLiAtDGNk0SFd1Hdjp gomYjSeF0NuOGFRFC9MF9YeYuAaF+lqhlRsy+yptdYZT6r60xVkN7dFa2QLyCNOIdZjhGK50AyWp CAX0xImXgSgg29Yga104Y8wI+TFz2YXZhdzPm10H/NzLzU5qdRFaRdknhdN4LFMDRcgR285xgBr+ 9JYDUF3sZFGRGVFbcYjd/p3WteVOnTXQIpXO7W1QCbXe7lU3DaneC+1d8j1f9E1f9DVf9W3fiWFY 941f3r1e+a1f+73f7WRf/H0YfpGYd+tNAAa15NwzU8k3Az5gBE5gBbbVgGtgB3Zg9ryoB55gCq5g Cw44rllgBB5g4Qxg2xRP9CQj92SWTbVOEw6X6pwUTdnf9nWWiHGb6TVPGZ5hGp4zAYVfFla177VS YMpON/vS7M1hgtVfIbZRtPAWOVQf4/0ZxLXRIN5T9fE/dSjf2hViIi7iBSWaJAYyoRgPh6hXUu1C 8SNexejTxaiJi927JkY33X2YDsXiKw5eLGbQ5B2Zi9hiF/lTYRAKAyLZ/ualRTOuTojhp7yNidVt Y4jB4S9FC5yxC0kJ4suN4zWe49+z46uS0isCxijoY2tNmLNU0ECOpHko5EgdJlVT5CjmOWscXx9S 3zjegR8+ZCM9kecdVQOtCZzggSMpkK0E0cX4kq9i4rjNO58J5EAGR/Pyp5fFROMqWgudGy0UD2sw gAKwQWOyt8o45Zyw5RGmX4YJqh4diM5iXb6NUG04tw5JGNGY0iEYolg+ly/5kBoNppjYRozzyRYJ ZRklJRBCC35NRBtz3TMeoSVt2PWYjoNOzJrsukUZUP1UK42VXUReVG/+5XwN50ESZZVw3qL83PB1 GJoYUY5ONWsolvbR/owpwWMGCUFbqqkvrWcaIjlQ5tRqqtWfwYaMCh5ddpLJUAMBcJNO1Yk39dMr upMMsT1BSIsAuYyLuIINQAS/O4N6BNTo1N8x/V2Fyl16IoN6FggyceMr+ICH4YMC0eX2EV2IgZZX shVWZStMqCXpU+kxLQAKsJF5Bt2HpKG8dRgzrkmgPqFObRAKWuqNOIMac5WffgUI+QJu5mI/gKgo eA5aGJO6zoGtXNlWYKuYeIOgSuywJAlIQGXtzVz/fAA6oqGiLL12JtqeqNNVA+iBrZvgMZdfgJj1 WOObmMpqaN64Zls2kMMHlBj5E6NR4GtOPSlMsgXoYwzIsBmrmtzC/j6NlQgim5VSP0jEt94prlJd JuZtm5iKEKKgLNTC6qnqivaAaZjeKbpRQvoZHu3FSXbZdzam3sIJal6YFBbhfIYFh9ELMemEKtCn EKpW+aFCK1WEi8CEJzRuhlkjnWztieIFZ91mmj0mpFUEpa1uiaXuSw1BJ3gOg8A849ieESNa/zkN JpTBUmbj83bAMaGPIxgkYGBZipCIr43vVAjlAAiB8KiV25ji194FEV6EdWYLp0WEAc/jCzFwxawP poujmQZpro7dwHuYZzWFt/gCHPQ6XI1YkD09nprulTU9ipIOm8KGT21tnxgs1tpkkzNv0pZYGifh QfJkzp6JKUGE/nN4iCjmYehABCFfZIgJKmYta18YIgol8I4YAN4B0yb3Rj+I8HxWUBLUiZ+wgyyd PnEGCHoFrES0J421bsDAIJAwqfZk4h2IVhhPAzGgIEWjCRiP0PM+FxRMZJ8RgTwIEJvJCYjqtIkG 6WdxhjsIViM2i3wLS1+G5+aYxIlRhGaEcga3cugpyyxZ8zOSFg+FB/2W40XV44qYQ/j8dTGddaEU 7YY2KD3S0hWFZC7VqpHx5JH+ZdaIBLjtbwpwhw+BrWhnGFfBCaipJPlh0LoRd/VpCI8ZAkvQ8PaV ZIKXX3EukJeBqmB6CwRyFMVEGjJ26s9NNJ+IFfpcYqHp3/qV/uQ5ft+qnOWoEdOCAunYHtD+4vP6 bIb7JXk2Tt/+4iPd7QIfJnh2L3nwfaMuCddfRw/SJHoxInrz9vn6jS6iZy2zCWAOHpZT0WCqr/oD vmCsz/qs30Wt73qt3wOAUwB++/qv2Rb2RCcPDuBtj2R1GbATjpMUfjX6rPdogbe0Pxt6k3qrN2Cv /zcg7+bMlcQ4wxhgvxh/Fk3ET/xFbIFwJ/f0NI7X0W9zr+oHfXvcuoG1fxhsH22g73ntNA5ecC/x sHzCqZ7MZ5ha12HHN1JzM/FGgY4MI31q2QLCb0Uyj1ucrPw4F3j0BH0c2CM1YNHZkX05OX3bN35j 4olC0v3O/vfPtccQi9dhqG0UjhK/KkX6FCB+GbCsKjZ9iSEMc9E9/RTmIDbfTbx5OTDJgq54nJfd 6UdI0cieOUgwD+sd3Bv+LvgCLHiO2e6C/oc1CAhy0nAIAKJSNPKEAAbxIQQiCUCApCyVyTNd27cc JOCUXBsAYSAFAAlDgtASBhOJ4sjJchomgIFyhBoIsNkMaoaRkcAK3CwJXqHb6W02Gxi7Zac6Pq+X PfZ+vQ6B4GCRxdgGh8SOVkIKycecSE6SIMffnw7PFUYZ1sEPVtKBFxeBz0EASYKCzmeVxGYR3IDC oEzY7cWZQKVXiy3LQQZvBpIRGEvVjsdIqiwy2RlAiYZS/hwK74eRYMaB0ByBgvQtN4A3xomg5GVb gENBQ8PCQgO7vU0RyYXSxI9GYosNgi4kwCJCQpYjAbB0ExbjHp5MMIJwEhYODJYi2QisSOKEAIkx J7RRyLjQCyIgYNZN4+KNlwgSK0wtRDfGBxhZzyJhUFMizjMywqZJmlNISZI5kAQgQMXNaA1qvMBV wwhxRgB48uYx6Nq13lWIbEIWknBhGEADRoZ6OYhQliCGa2HACttu0Qpwg3hJ+1lk5JgfHiSkkxBq YkYH+xwOGHWL5RieVqdBoZNBDVHKR1h5e3IggQADA54MeWLZCzUQcjA0NvKBkrUMd6JWnpNBruN7 D+Yt/iCw4Gu84MEZ8C5uvHgB4nZzwHpC1xDaRKIx5OP4HPOcMtueL0cjccUJF7w+OQRpHTCYRbhe gaFeJOP4fcBWihl2bvIXy1rol0A1qspnLjhxEioFRTaCMAYMZRQ/rPU0mjaxbYJVTmuMIVdBVzmw YQNe/ZaAcPE8MCKJJZoIywMMdMcdB2f9k8gAdxDmlhUhVVKLIIhYsSI+eFEkA06wITQQQ0OWoFcA vBCAihUZtTSIdWJAJps178XxAUOz5ZbfUcWMYcoaLFzY000YWCdZGSU0VRMxYrK3JIIIFGSbmyOt KME7Hs4Dlh4IqNgdQP0cklYtZT3X5AAxspBoXg/x/kiDRIEGIdoAZVkSgxWYwnICFLnZgAs0tmWj hSHl2CZXatPcMoxaV0iCSjcgLKONEQvJUOkHXVyxAilX5FCCCWwc5uutItD6KAwONACFHg78uVyg ng1qiZJPBFqXJodii6ysPFgKF5QHaQtFpnVVQBGzIA2AhBNUgIpHlDRgdhG39dagA0723uPsnQBN Ma0l6fBzLcE72htpwQkrDIuT3UAJ5SfM4tHqvZK8oC/GVxybsR9+LjfaEe2KfISLOi588rn6Iowy y+diwQbHMcs88x/8hiXwwzkD3DLKGK/Mc8uk0gzRIkMbreGzMkt877ZuUAypz4t8C/TJR1t9db8J /gNQwA5UAy1EomGLPUABZZt9dgFDqL222qmoXXS9OrA7Mt1123133QakzTbffftd2tx+4z044YUb fnjh4iguzt+NO07p2JFHLucCHkh+OeZju7A5550L8DnooYseOtA+T4Q16qmrfjOfq7v+Ouyxy95x 0rPbfjvuuRvtse69+/478BDxHjzxxRtffIrHK78887En3zz00Usf8/PTW3899hBVnz333Xtvw/Df iz/+9eGTfz76x5ufPvvt576++/HLv7qc89vPrdf5B2Ai//37/z//NiTAARKwgAYkIDwOKEC0MbCB DnwgBNEmnAL0oXf7g4dXMqjBDXKwgx78IAhD/ijCEZKwhCE6IQpTqMIVspCFEYzghtCmwBnSsIYC BKCJuDYPByztdc5iQAFSQLD7EdF4BaBHD1HnrAIksYhOhN5uCrC6ACxAik+8YvaSkzoqVhCLXrSe Fq+2myZ+sYzK243VqEhGM7KxeMo6GgPW2MY5Aq8ADhgaA+5Ixz0ur3YZoyIfA3m8d8yMATATJCJ9 FwA/6ouRiXyk7RrQRYwREpKWxN0DWqcvSV6yk7NbZMzi6MlRvg6UHNMkKVN5NVTWi5WqfGUh5Qit BcgSlrZElih95spbym6RE5wBPXJQOfTlUmW75NFC1MaSsMhSPRsDwdNuIIU81NJ5voESLTPA/gAC WLE31axDJHRXzIM58lEDWcyq7iEXHNCJCzbADBo+l4c2/eqbVtuNHgGwmwXIYB4PKAAB8okPpuHA Ady8QdPIlQOZjTNux1zRJ35Fqxag4WJ2YBY8Z8AU1dyLiRkAKEQSBaR4UWSZNGACVpCwNCrqUR5Q IA4/MzAPEPxmARXcZj9jqk8CTBKnNCUOn3bTId+kiKgfvWY2AVBTAshDHlYU5iAq+ACm9kZMvmkq xhqKv4d2x0Veao8gookzbcCGOoKA2zQIoaqWaMEWd5hqE+EE0qqktRJ6+dVZUxOGh/3lBJ941zT4 CY47OqCmUqTiAu44VeIQtjd9KOxToyiB/qI+dWsJYEAXAZrYIyZ2nyyoIgAKC5Y98bABl12aPwPQ gIDulAHLUqpNUwSirNrzHqrlmFd/RIQJzcBOqDoImLRDDofRCQXhNApgTDpc7RDDSZWKhUaz8Bkx yWIoZzmrlyQ2Uyq6dms2Xe3WuiLF36iWnz+sR0Z3QxzfAJEGpi2mQfU4U6U+6wFZ6YpMizbVSYbW prcQ7EH7W0EqcjUsWkWWKTGWW06BCiQzkItRhHuH2dzikMV1gX68MJQbwEkubTorFNapGivthzLD QIHOJBZFrSS2Q1vjKXCmKsX4agWzyuHDQdVLg8XON7Q8lWlMf/PR3jBgtvTFsUC3k1Mx/ukRoMwK ZiNra48E6yu3aYIZmG4VGSUI91T6+QJHiULh24QDzFERxlzp1ARujJm6GMHFF3ihJEgEoQb0wCyB /SvUPKbIqf3t0Ijo4V8cS5UASZuHOwJs0ArOV8gy1md3j5yBqSYZoPkEE6UzANk+CJW2fywnjyKq mg/ASUyHhLBZK+MgGmSZwSuByjSYsmoOCwND6FhElvQjZy/lZyhwGsiJa1Bk/w4bCgtIQExNwSfT ZvPYMW1vprUZ4G3K98eLBrJMVZTpI45Wp48GAH5hW4TVKjbA4ObmESNtrwPjkmNxGU05lKQPGmiH U2mlxF8cLINqHelLOyAIN1CFAV3N/sBFD7NqEtRCFTGEQSnkUKuRUvWrbAL0WdscA5FloFmZGtqq O61sJQzqbW7Etz1gCDJ7q5pWvObRN6q5ph6neqzV2hjUy2H3o2zeHQQo4AKemsLPQUArio2GFTIQ B6QMoABJaONiPCfJOj4g3MtExp1saIE7h/HM58a6whQ9qUUhxayVjh1qCwXB2SnEAnamTshRPuUT BQC3OaCVHQuHBh/BMaJKeDpjBZYf36+y21tI+X6UO3aSuYVzHv2dl443cOHZofPHUx4ii1/R5Suv +Utkfjmv3TzoIc+xzoe+9GggvehN70T9uA71V3G9DbJuD5NyfTnRDGmpeYRS1L1A/sRhKQM9WX1I TCjXLrC/x/Fp4A3bAjbLdmkzRMIx/OVk9GrWmXpYsMPh6e8h9zxKvuQjjwPug2D4Ryl7qrC1zK9f 9F4YsC9WFIWVHqbCDmZmZxXcUHsEFUNioZHVM5XdFDgHGZCURNAAL6jFCcgd3JxA/sHAy4APTfzI 2lEEnBWCSaUDrchaFhTGv8BKEDhg+I2e+F2GsciH+YULWPGdjYSBjbRVlvWGOlTDfLzcNLRKC/Ia mOnFXsVFAVIJuDxFlPRgOZAZlJjAIOAMJ3zJl1SXD87BZ2TZIDwTvilhe8BbEErcNuzDL/yIX12A WjTIhh0Vhi2DIOCIBSKEAnTB/jVkCOeVoB+A3y2cQY7cnclth0kkRWaER1pVx/mZGDNgBgiOWjXM BBuEgR6+AZkhhIX14Dac3xwcogh431FtSoP84Q3KSDmk2kRMoL3dnxjwypaVlJtMg69ZRji5CkMQ g74xg3msH02kQoOEGTWQQAqMCmDFIRzugRxaRb74Ho5ZxIIowVxlRpZ5xEeE4ZFQSSO4nwyI2v7I hJL9yjrEQVSE4SRWYxXkxyRO39RxBJ3A0x1swQXIosPAGV+t1faVmG0oIR2yQUb53ipaw/CpVW8t CZSICS2qRVntFRz2oh98HjtQA2ZgXwtahNRwGR3s1VAkgRB8A9WZShJiBR2s/oJSxYV1VF8qmhjr YYGTZQZGwNpemZSCiMFbTCNDrAJoIAGYeUAlUANh4N2nVAdHUdghssGC7SDwWcM6zMS66IfDDQMF Fhc/bpgkgCIv7qIeCOQlEOSYCB/VKRl8rMYkWhcdtIoVyVmSOAxFHoVLEt40DpebsZ450Eu8NYgI TNVM0B4/7AdU7JopboISKEmYcQpmEIOafYqxjGIkhkmU5FZcmuJOAkAttAdUOB9x7cdsFJdNiMAn /qNS5gFT/gGYlEP1LYncCWECAJR1YCQ1nOVPMGE6vNh0HAs4UIKYbGZYheXLiYKb0UAEIlypPcwk UuHDYMkX4EjgbeKWDUJf/gxC1xwC68XFXY5BDoJkEb5cwNnECsoCcG2MCjoJnYggavQFZJ4SHC4f LcgGWp0mzIADLXRKCRidaOSAz0GBAJznbXzCxiyEDoxDU6ACM9jKvTgBrTwTdN3K0j1YpbxA2HnL QlwdS3gAS2xlEIydePSWRV0d67VAIaRdknyn2iGghFbg6VhoEjUNhCpeZOLBZPLRCYxD8BzgFwHk HnzoHiWn6r2d33Vo+7joitaBiS4ljMaoLU3ecniUje4oO+GoXdgRjwZpDWQS9VSWkAZp2cQMlR0p j85oUjJpkN6WzCQplO4oJymNTlWp6i0px4SRlpqek17CoH0p6OWR1SQVgZlWXgMYKc2MUZpSHmhh DRe96S0tEpueaePRKR+5lA/FqZ5aUmGNKexwGw/V6BTpD6Im6mThEKM2qqMyqg1FqqTSUAN1yJ4Y KrL8E0yVEAd1CKd+qgeBG6iOKgi1kKmeKqrGw9mEyAu1qqu+Kqw60KQWEALA35/eKq7mqq7uqvhE AAA7 ------=_NextPart_CD9_C8A9_2F1D7B6D.78920DAD-- From chris@njc411.com Sat Jan 27 11:09:03 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAq6x-0005tW-Eg for sip-archive@lists.ietf.org; Sat, 27 Jan 2007 11:09:03 -0500 Received: from [83.234.53.202] (helo=vera) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAq5F-0003Y0-CA for sip-archive@lists.ietf.org; Sat, 27 Jan 2007 11:09:03 -0500 Received: from 67.15.2.215 (HELO njc411.com) by lists.ietf.org with esmtp (S+TP1500MNHG =/(.) id ?84('*-I/Z)8P-,7 for sip-archive@lists.ietf.org; Sat, 27 Jan 2007 16:07:17 -0180 Message-ID: <01c7422d$37910180$6c822ecf@chris> From: "Mindy Cash" To: Subject: eMachines OEM license question Date: Sat, 27 Jan 2007 16:07:17 -0180 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C74246.5CDE3980" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.6 (+) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C74246.5CDE3980 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C74246.5CDE3980" ------=_NextPart_001_0010_01C74246.5CDE3980 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Rise, to the muffled chime of churchbell choir.The winter road from the St.= Simeon farmGlimmering of light:Beyond ice floe and berg and ice-bound sea,= Snow haze gleams like sand.Blurring the terrain,Amid the gloom, there, on t= he pole, stands blackThey tear apart the mist, it is as though,Thinking of = your abiding spirit bringsthey sit with their wives all day in the sun,Star= s, the last day, endless and centerless,Pierced by the mist that fades away= ,Again awaken from your being gone to findAgainst which we have been projec= ted? What . . .To reach out into its own vanishingXIX. Jones Sound and Beau= fort SeaThe weight of being born into exile is lifted.shaded by live oaks a= nd bottlebrush treesCentimeters=97that the height of the canvas ------=_NextPart_001_0010_01C74246.5CDE3980 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
3D""
Rise, to the muffled chime of churchbell choir.
The winter road fro= m the St. Simeon farm
Glimmering of light:
Beyond ice floe and berg a= nd ice-bound sea,
Snow haze gleams like sand.
Blurring the terrain,Amid the gloom, there, on the pole, stands black
They tear apart the m= ist, it is as though,
Thinking of your abiding spirit brings
they sit= with their wives all day in the sun,
Stars, the last day, endless and c= enterless,
Pierced by the mist that fades away,
Again awaken from you= r being gone to find
Against which we have been projected? What . . .To reach out into its own vanishing
XIX. Jones Sound and Beaufort SeaThe weight of being born into exile is lifted.
shaded by live oaks and= bottlebrush trees
Centimeters=97that the height of the canvas
------=_NextPart_001_0010_01C74246.5CDE3980-- ------=_NextPart_000_000F_01C74246.5CDE3980 Content-Type: image/gif; name="rzvd.gif" Content-ID: <006901c7422d$37910180$6c822ecf@3867D386> Content-Transfer-Encoding: base64 R0lGODlhKQP6ApEAAAAA/////wAAAAAAACwAAAAAKQP6AgAC/oyPqcvtD6OctNqLs968+w+G4kiW 5omm6sq27gvH8kzX9o3n+s73/g8MCofEovGITCqXzKbzCY1Kp9Sq9YrNarfcrvcLDovH5LL5jE6r 1+y2+w2Py+f0uv2Oz+v3/L7/DxgoOEhYaHiImKi4yNjo+AgZKTlJWWl5iZmpucnZ6fkJGio6Slpq eoqaqrrK2uoi4HojMEs7G1FLG4CL27BrawCr6+srQXzLC9y76zDcLNxsXLzMAG1cvQytPK0LfF0r ncscrh2scE3ufRCNQOyN7B4Ov+DOTj/vXP+d3C0P/ptwDqC+CciorcNUEN29fwvL8WP4zGFEifkk DlxY0dy4/ofiIPJ7llGdx4YCR3LUaHGjSIcXUaZU2TIihGHKutUU1vCgQY8tt5VcGfJj0JUvi1I8 +bBoSZMyUQ5FSvRYMpjZ8gmd+Usl0YQIY7o86hWq1adiyzZ1+pPsWZcGcT5lGpUtyXtL28adi/au QKw63drUWO+rT3J2tx7d91evX7OL1youe9Fr2JhaK2tNfJMbSMMJN15Oe7Vi2EqDATpmPJqqyZ6f T0tm2XryZ1sUKT9IfVl2XbqPGW/u3Rhw0pdjgRrnPFptY1hc1bGT+1w5RNk8c4+jDlZ1duh7OzrH XK34adCu+1pi3prb65HJl8/2jFs774kKuWtWb/9+zvpv/r8rLgcbe+m5xxBLty1F3HGhwTffbZ5F 911z+tVW2W6I6TdeeQL+gx1eZlVXIIQ7+XefgG/BxZpFpaD33niUtYdhh1t1ZNQ8MxJmH4A7Hcaf h2Lp2N+FLw4Y44Mk+kOeauIdBtdQBkLYHI++6fUkcENmx+F7G9ZoDndV7ijkkSKdyFSKX4YSzGQf WtbkhRlGNqCZPAHXW098SeljfnaCKSJZMBYZogZwFngdfG22CZWUAU7n4KFG8qmndVmuJqlRtXlJ AS94CvdjbPIlJUqakq053Z/5ISWhaAhuiWeUDDa6qao0KjUmpMF1SiReiHrnZKGENrnrWSjKKqaF ON5q/iWbWAKo5bKCtVpoBaWJY2yGjg1kHkKPMbslghestyi02l0pLojc3plpe1xhW6avttJngT65 8kqlr4s6SFA8wxKL4am7pQdunoM6K3C2Tc0rWqyYXetpqZNOewm3jJLKpbTjejvrs78CS26qyu1Y rqXxmSfntzQJSuHG9XKcr8EpcwjrnR4z3Cy/NLfLKnYzo6OwuR+vJW9Vm9xLYsA2+4PP0RhrfGOP qDoaLLxOs8sj1e/uzCfCGBlLNdGFHZPVvhiXi+5vOZ18ts5o54ncXFonDC2k6tp7dideT1jp0umG 3WzIs/LNsbKBxdxy4A7DdiyyJccbbQbd3jUwtYXX/koNyP1Wq6ui+sY5b9BEzu1qlignhzPEqwJs qiPhuml003tLvKzff7No+MumEY40rLQW++PVqTvpOJOGSvxz1JExYznZuF8OOemd26v87FyPjhuS FkPNCa27+/l2oq1fbbm1FN9O4/XR/5c481eaHCjjiXf9cdRAIw/y+bZqvnHVz+dffp+uz+841ChM fO/amiYsdSpyMe5wL8OfirLmvMfx7mf7Sd+10ic8cw2QSuQ7UAcNlSQUbRCARctY/04YIzJRaleL 85H+DtcnRd1ON+BgnzSy95UE5s18Oiwdpyw0sgKW7XUWJCAF69Q90t3CRgpSkoJ+CDYZTnBKRlTi /rZqFkV/Mcx3YmOif1oENhvecGg5xJyL1IW50L2QQiOik4yIyEMhps5U4GqVGReWNhA+UY8Nsl6D NsU5qOmPezsc4v/+k0EtihBKJgojFMkTmilOAktse2Mf69hDSuZlfEJc3uT8Ncf9ZVBzdxRkaQj1 R1LGEYqxMpwhB4dEwWWxjNWSFCjF9UXhvZKTabSbAdUSQTbe0pbi0ZuWIKnFItawmHdkmzMhQzAK hkc47cJjd+DYK0Dar2AwrCCdSrk+fhXymwezpjl9YyaeSRISBxFZLoTGtNMpK2d2HI7MRLi2+v0O bjwbGcTgKU+NJS2PlnzmOQl6MoOpb6DDmSZA/icyTYE2kHbTgN1EIyq9zCQTPLlSaCw+CtKQqmCE Ii2pSU+K0pSqdKUsbalLXwrTmMp0pjStqU1vitOc6nSnPO2pT38K1KAKdahELapRj4rUpCp1qUxt qlOfCtWoSnWqVK2qVa+K1axqdatc7apXvwrWsIp1rGQtq1nPita0qnWtbG2rW98K17jKda50ratd 74rXvOp1r3ztq1//CtjACnawhC2sYQ+L2MQqdrGMbaxjHwvZyEp2spStrGUvi9nManaznO2sZz8L 2tCKdrSkLa1pT4va1Kp2taxtrWtfC9vYyna2tK2tbW+L29zqdre87a1vfwvc4Ap3uMT9KEnL/hoy huqudBiFaHOLwb6CiCodUUQddWfSz+cKZoGtvK5z85lRhFoDHrEDUsJyCV7O9DNt9Muu/A75XQWa z4H7XEVHP4XBhq0uUu/VWgtx5cPiDU+biVxZo54ouWANbHtSc6F+f6mhlJGJkGsEJ3UOvMt8TYWB g9lcyyKJnOOm4r4alCMWKfy1Zc5yk2eUYPxkqY0Us4ZeIE6lH1cWTTMWlHICRCYfEbzjFseGLyu2 WITy55MfxxjB33UpiWOnyHEiklILvDEkCxrESlq3cr3kIpGZnMlk+czEVJbO3Sj3mjAXkKJcprEy MVyicCVZZXCOcH1VgTWdKQ1UOsbvhOab/mFYCpB/4eszc724rfwSmJlafhgXD13LIx2vaNZBIn8h feTc6C7QcK5SI3HlSZjUNM992zM0XUxC5jmNlr2w8H7JnGO9oVBmjA5hdyWI5WDmSNKPwpum+dzB U+PzgQ12E6s7SThPfy2dij7TS9k862xu83upllaxmxnDExOQ2qi5tkFp+bnhZRh+DnZlpO+nTvKd 8tKhtpkMd3ZnTRl5yg4E4p1bMd1t3gjezEbxQT3oz+jKDXRjjh8VD74qs90v3LjWNr/9HGBkNXS9 s354+4otRYJjwHSX9HOOoPde+8LXjZ6rHdeM1j3EpAprjX51oXFctZEf8Vk3hlE4eQns/pcLK8DW XbnLLmZC1k3aizO7N0Q1rMKKgzzlqDhzM99BcHeqjelOz/kn/2fxixb9iPHmOI4NuS6gm9rqDw3x civlcwZuWkzSbfU3jX50qZzc3CfRrkirTvLNmVyFtlM4Qcyccu9a/dg3YxLXA+/RyJ29b+nNur0r 7Pc86jPWji/WO9w+Jbg7F1+ZE2Qsmb6iKEO68lfEb8j7LmvrpX3vFL4Uto1ITZuL25M48hjpvXcs BZtOJ//15kLf2ea8izjhGpVnz9Ir81igXvSAk93n73bc5Sc/95gM+vODve23QW95smfh9n0P/j15 aIPZaqfYXz5K5gQfnaDnZ4rfHG0W/ocUys9UvAWrn6h4gR/hXuK2oelvbN5GTrZGd1UkSnumcec2 fpg3Njp3c+BTP4g2claEXW8yQF2HPScleGJGaGuGdsDjPxL1gas0eEUnZTm3gTO3RwxXa69HbwDI TcSGKVBSe81GeEGicw31TwCzfvn2fktWZXJnUqPUSWEXccBkfxKohINGUg8ofLDmbJnnX91EY09m ZRZ4hAP4djwWEivEYOw3J/FHhPVneIykS44UhEJ4d2I4gi+GaijoKR4EhXIobNIHeABYb8gGYXCy SVZYZINnLf6HbKJjQCukZgLzZSH4ecXHY+fySG10TZDIZMOHJvR1iP/ngR7HhY8I/l/O8392GIjz tIkIqH0JAk2CFn8tF2tMeHWRSEyRB2OY2CVYEYmER0OFOIoSt4gtN4t3N2zS133IJG0F93a/eH+r CIhO9D7SZYzflhea6Ba6531eWGBgxn8RJk4dCItbVmvh1oLXth41KHHDdozMZV7zp0aakoIUJ15y EhB1Y3zZJVHbRXPuNWcds3RTmGZ6GGLpl47+uEa7R15mWCH2ZHwBSY3AYhgCFV/Ip16MOIBUGF7F RZFCQIkViZEZqZEbyZEd6ZEfCZIhKZIjSZIlaZIniZIpqZIryZIt6ZIvCZMxKZMzSZM1aZM3iZM5 qZM7yZM96ZM/CZRBKZRDSZRF/mmUR4mUSamUS8mUTemUTwmVUSmVU0mVVWmVV4mVWamVW8mVXemV XwmWYSmWY0mWZWmWZ4mWaamWa8mWbemWbwmXcSmXc0mXdWmXd4mXeamXe8mXfemXf9lYF+lV9KVc E3mQRmgPr4MtDbl666iIOlgV2cBQFTWQ1QUkANUOzkBezfeOa7d4HZaYcBOZHrV5jDmZocmO1geR PyiAqyaarMBwX1hLD9aJsfhKnXF+aRRIQAg0EtmafueEkthvENab0OebBuh1w/hx2gZgBOaFyZSb +2cXLAJ/zORhjsR47Xcenpd6OOdvZtaKS3KCPeZmqDhjrQeRt8ibkYRG/Teb/uB0Twc4m29ogd1p n8GJfaR2X5lGj6H2K4m4jclZic65f1kmi8lyhU3EnOS5nv5jG0hYJkWob8eJfdXmGvApOXFHe8U5 huB5Xq22Y+35oZUTjConMn84e7yJj4JJCRaHfgF3oPm3Ttl3hws4RSunJzFaoak2obIZgkOXaCAY gNnmh3PXoRwkaeJDO5lYT8+hRCX6Z86Imw6jdDJoXAnIaiZIjPQmIs4JSDU6g0MKiPyIhWDxPo+Z jK+HjId3cU1YpNLGpF1qGj5Xpht1KXTafWmiiGiUhKEokSx6QL9poNm3pQCGps7oa0eKpNjFcsip qGIKpPfUi1S0phHZawI3/m4pqpsXN4tqUqdq2qmzcXDyxmkbRmdPGBSNGipSOHpRt6moZzz1FWTs Al2w56gOeELy83MKaaexmYsf9ofe85z2Rj8S4oMxSIf7YKwIJ6BW1KeDunOq6gmw82ZQF0h/inKx mkTjeTCIQq2lCoZW+i+6Wn5x8m15WmN7c4XDuYs8CBkcaKe9+KC2mpyp8XVuuDuFSQp456fN55mQ mZ3a2l/RaXYVyKy+CoGT56Z9IaLSFJvS2kcopEb36ZBxJmqsCKrqJn6hhKUfBHE914VlNwr8CqO3 V3hyoY8Da3d1560zh665l2wh12QZq6YI234II7KmCXnuKqMYK02TCqS//lOuq/GdWFpHgPoIoNiv +eZ8dUishbOwTDtEh7JRtwqzuUqJ5serNcudukiL4dk/LnpQ0AemP+uxbbqts/qJf6KvYwoKSluy rgqhp6pq0ok7YiumbIewqQgqBDqjE9mw5PSyect5YEt9IHujsuKj+OmgiuuC9dhlbBq1ADqy0jmo HUsxZItNrailUfijmHuuwMd9mfKiW+uwXVu3GWq4C0ebeas9rhavwSYvjztDJ+iYtsqmp5CCepZ8 +DmlZ9K0KHq5stuZUnqtqVttUjR+5tqrqCuu64e8HFsx0yOnIwqvNMtrjBtD3qmz5YmGhbuvsOaA rTu3/Bq9pVioW7in/se7oY9LgRErrE16un4LvUtIv7sUZCWUeiHKvA6qvUlaYytqe6ene6aQh+XL fKr4YrTWXnY2iJ7LqvdLpqGoutbZRfPLaaaknxcoilHmv7YZSw2styD8Q47ovtxYiz7GHgZsiXMr vjG4uMe3SNd3S6hon1brvc4UOMTpqaGLujY8j+CKwBhqefQpZPV7OdxaHMwywbM6nvMaKs3IpXUW eTBnh0JrGcNUqFbjmqO6n8Eqt+kKxc0rwYRasVrIhF8ofoyWv2P8uZUaF6LSxd+5nAj5txHzj5up mOZ4mv2wxxzWMTpbchq0YHmMOp95xhYVnwA5LobctqY5O/p1Sptp/q1r3JAAK3mQK3SJvIMV26ep 5K0CCpiBhbSjbMqnjMqprMqrzMqt7MqvDMuxLMuzTMu1bMu3jMu5rMu7zMu97Mu/DMzBLMzDTMzF bMzHjMzJrMzLzMzN7MzPDM3RLM3TTM3VbM3XjM3ZrM3bzM3d7M3fDM7hLM7jTM7lbM7njM7prM7r zM7t7M7vDM/xLM/zTM/1bM/3jM85WcpDSZjuSFHrOLR2p8f9aVGF3F+IfJio6X5Icx0G244EzL7K VLxzDMRua9F2q4O3tbeFSLceB63QqiF0TLvCCJ18k0117J+7mdIcLJDnFDbiJXfUCYXHVMVoEbD7 rFkbjWi+SbfX/qs06gmc6ftvOUyzPC2bIJ2u1lh6ocywiFPCWueNykrIBNWHGRjApLlaOg20ORqu CkzEZ6RIoxOs6sbVXS16VOzVmQGaAWJrh9lpXMh7iiyeO7zUmgdaeBt8V+y2Ext+vVZ16SuzF71t I+x6rYmY4HuDd6i8ZPefcw3EVu25Y/y7JA1qh0pbeL2E+HrAHLg9X7KskRs8Wr2jEbzZeaaaWjxC KVJMP3aGYbu+TH1mH32puQVt/KhvlErChjpB66aAAYTZk1rSBci2IKprEwynzdPT8Ostt8bcSfdo 0wdbx2rb7WuyMPo0hgkdgR0doDvaS7t2EBuq5JiDbmZ/n5zC/hEoxArHrs5dmrb1redK3WEcrkTT c8Wt3egl3gzIfLID3gQJeRi9hylq3hUNj3y72tCo2/Hl3viarKj9r95dsO4FJnZtvoH7dHLb35SW hWP3SOWtqcqN3tVpTQMevwCL05dFsv0rodfqow3mOZZJT9pZ4Sq+398NdymOaZTLoffKmthtqR1q tGh34pUFtzTu4Kpp3TsHtWOW4f2C1Gia5BXU5EWe44hd4lfe48tFpr/Itp5s15tF5fKrw/IN4T0L 4+MKeko72NWK4UYX5hRd0R6e3AR+dqG7uQlK2akFg4LbvmacwEIK3Fj3fdaW2BYuYMJNdZZLvhV8 3Due5QCn/sReW7VVq51gPtFrzuaIq9jU+0U2CN0iOKz6jW2dy+EKK4iNWthmo4w1LekALIjGhktp aOWs9aiYrodIzbvqqzgevU+1butkXI7R98KJXaFsvYLG/ujbe9URGujf2KCrqedsuNi3vuiZ68Hm BMKqutnfeNuoyuHPu9QA3o+OTe4g/keTeNMvZO5sktl63sLSMdYuzIs1jO6gyHJSDO99voslTeeH PekPhUpPzej0wsSquHrzDtq0ju9Bmt6rjtJx6jpP/HCn/a7prd4/TCBIjuAiyBvV5LUCK9VTA/CL 7k/nqPACnMmRrMEIiXwDbaICzLSNCdWTh9Dx+ccTBeor/gvqts050ZXuJm6+HAXblZ7PxlX0R4/0 Sa/0S8/0Te/0Tw/1US/1U0/1VW/1V4/1Wa/1W8/1Xe/1Xw/2YS/2Y0/2ZW/2Z4/2aa/2a8/2be/2 bw/3cS/3c0/3dW/3d4/3ea/3e8/3fe/3fw/4gS/4g0/4hW/4h4/4ia/4i8/4je/43Z2WZzxxIgzj l6nQqfmaNj/Ql4/JlL/k+E0PmEnJCVnyIibKvRtMUdvPQ95bG3xr4envqE+hv5mMtrneLgvRqdrR c37sLS7b2qrUtSLTY0FMOGvSVM2Srv+9qQiNTswqDPzVDoyoafuMDMb7hH2Dzi/Dee4X01XuC8LU bIzV/iDJcUuq42QYw0JtZ+/GrRRqrCRGgmhW1r8uZPZe7ctJ8I24+0Gv6vNE9MVFAIrQYpktVZMH TlmtiwvPzr8rfJKMoxDr2za01UoxNcGYbkLQ8ewdfi+8mXBYe0GAxuRPRrOxmLjhqKjqoYI37Zbb 9X7BYfGYXDaf0Wn1l3TVuLRIZ84jS1Ld0mq7+qavcOwy5ARvCLkOA03o9JZOColachKJDFf6Gh81 8RQ45/Z6HNdGSUtNT1FTVVfNOvMOjAxdlhizoiozPyVjVXghYRdf4X57KXX7HGt9B3GtQJGFl52n MBsfBq8wPIOfI4xZwcPFx8nLzcVc89JF17Gjue9C/pVnFb/bm6ulrYnrhhGRROWCJ4vfDxbZ5n2z 1iaOwm3b3El6AvBcRYsXMWbUiOiWD3+9lEwLOI3kvmOKPm5SFyNaLUrKvM1bmK+gQGY16XXMCS8g wJFKgDxESBOiT5obkSZVupTplpjZdNpKGRIMpyMJAVH1+MeoLp44gek7JhPr0av5Elm19A7oz1lB 5VErUvbgDKNsm+bVu5cvq7pQoqKcutPLXa7v0tr8W7KlsJctbf6j6JXyomaRIis06NRnl86QLsnt ORHT5L6nUadW3UpxZMH6NFPWHJvwYo+DOxB1DLGfa86x6RL0rTUlbdoUiP92czeSzLa68a6WPp16 /t6/nXCe1e5WoEO6gKlKLB2qMubhYQMr320W8WU7tjef/BRfMkzE0cHWqL6ff/+l4rEbDq7l8FOM keBe06agrCIaqKYBj0LPpJIctCy7obRbi525nPPBPvYipJAb/0gs0URxAISmGsMILFAaez7cZSH3 lpFRLMJuZDFCWtbb0Cwak5skxrXAkvHDhrjT458TmWzSSTS2A1LCwDp07cAee6OPSsjSM+bABi0B U8Qxs8yRt/QGa+I8CZ8akcgw8AvxyTnpfDLKBctLrkwhV0JrOfN8cwm+CQPNkwd3DBXCCTJxxA3L N9FEbqsVdxwPUhhAqlPTTesckEzoVEwGQJEY/v3DmVJf6YbRqUAV1dMKYX1ty/EopfWnZyCNadVZ 47G1TE6BDba/V4lpLFUCV/VOPAvVXLDFUdfEQ76I6tJQuV91EhS6Zn/D1FpgQv320x6nENbcc6X7 7La3KjDNoCvdfS7UWuEd4T05dCQkXx67ipfdFd8diyx1ZyK4YD+Po9Ytg9OMVIc1300S3Ykprtji izHmKOONOe7Y449BDlnkkUku2eSTUU5Z5ZVZbtnll2GOWeaZaa7Z5ptxzlnnnXnu2eefgQ5a6KGJ Ltroo5FOWumlmW7a6aehjlrqqamu2uqrsc5a66257trrr8EOW+yxyS7b7LPRTlvttdlu2+23/uGO W+656a7b7rvxzlvvvfnu2++/AQ9c8MEJL9zwwxFPXPHFGW/c8cchj1zyySmv3PLLMc9c880579zz z0EPXfTRSS/d9NNRT1311Vlv3fXXYY9d9tlpr93223HPXffdee/d99+BD1744Ykv3vjjkU9e+eWZ b97556GPXvrpqa/e+uuxz1777bnv3vvvwQ9f/MUlLrErJLVhTqQn5PWXpxBNc1Xbff81TGG7zr/F fnbX33dh958jL2fl5n1xYUm+NLS/9iWsLQW0n/9sVa7mTCp/95Jfn1yCPgBq0BsLjA4DCRUmUrEh RlVSjwbF5J7HdEN+FxpUth7VBAMqiVqA/hIBquBVLGNB6z02lMKpHAYjCIVQRCtMUZ7mB0TYtMhK HArXmOZXq/lcawwzNNAOq2QXLFxKP1vslhctKKf6jOZY9EJUoMo4REVxSyz1woakYJioDAJpgxnq IR0xuKuzrDFRU1oiiOzYxjQm61gCWhYbmThANU7wJm5CXxVVxI8oOkeCO+QWXuLSv/KNZVFulBIY 08QnfvHwh+c5TDymNIk+mqpUjdIEr0gpyUH+iisolIoi5UiaXgUSj5QyJBqBKUuEBcWVfqThI+G0 ElweCii5ekOsrDjFP4KQIzAJ5bNE2CUMjfKFD9OTll60A16+EofEbKUrx0mf2YjynMFM/qCs0Agq CnkSnES01ysZhJ5abkmFUeyHPabVR2TeMJ7mrGezwGNDaSFxD6rgAyrp+c1bRrSYNWKlRKdpi11W JY/Ywk0906kV4GCTjj4kJ6xa+ElHiSaFFWUVVPBJntsA9KDjHCkyQBrQWHnmooKUE4ISGojQxFKH c3Fojsykqjg8CEPiekuWEJSZgfIUKvdsJ45C6ouogpMPt2ymV2toTF7lkqVQvM8T19URbh5hRl49 E42uA9YTHMeEbU1QR6dKqpF0FYby7E5d2fDNe1yGmtp0IiCvQy8fKdWbO6WiOGF61Zd8El/fUWFx 7oeOEpBxkeU0bFx1egkxtYq0iyXi/h1natV/sgWwESPrreBHV4sy1qyicZFnovKUjR40ry+ybMQg tFgesva2mM1nSQmVVXoYh51ClakmNRtbtLb0I6dEbVj1Z0ZQhtGB5WFuZIlzB946TGCjVCkb37eo 2RI1M7osrFO4+tnT5tVLvwXuEUOrPoFOS7dpLRRqlVvZs86Lgh10oMToakDOhlAt1x3hfXf5XQDq 9xcStpE6G9mwG43RuuO1QmEc0t7DOjV9FD7DoLq53vIh0KQODqCHsUqa3tanwP6l0ggD3C77dkd/ HBQjeRXo4zSaGKNBkjFjpLtO9w1VuGDVV4a3Gt36VlAyJPRSE8tamVP+GL5qNeRh/ld8QHK9M7NF jjGHZkxF25jWo/iirI4HrMY1U7WuEobkT8U8zCYbaLT/u2lzzTxZvWYqUq3tX344I2WjFpSBRJ4v OkzC3uq2Njf12nOZLVysNF9rVGyWq5tdmIJMk6TTIAbhQ/frVC1bmszZSiF3GDaTCu/YmKB2qyWh 5C5DPzOZT0Y0pYm7yQwPQ9JvfWwxtxrhIJLUxhDzSqnlmN5QL3uYbNoss1zcyCFJmca8jTJmi4jt CSlbxJ5utr+C69hzY1fDDSHDPVhM3WOfEUr3klKDTY3fbHu5z7iWqqrzfadof4Wp7hXolImi7t4o WdgdwvejX9rQcKPEvCftq74//qXT+iVR3PBc77s9Sk5460iaVl5SGgQuX0TDdZZmfXUMnX1egLf7 o4ZiNZq+rWHtCkeiu3Y4s6ct8w2HZec7z6i8zW3xhgkqGC/nMjyToVH8sciRJj95vV1MUZdam8Bv BgW9N9zhfL8br44lYy9pmx+xf1iJ6i14wz/4rM4uc9PUALsUhVlxuR5T6UnlUdPbTvP7NYbi1a46 r8Hexb1Dmo9fnjtBYelZ9G537TFf+eG9NfO9hrTyQ1f85Pme+Y4Ltriejzza5U3I0H++T6i/d6IR 3+IrlVz0gm9OWSa1yrIXNOSMn7zWc/v4nuPqwdutvb/pXAY/zdv4kL84F+P0/veABpvdplf423sF eutHHLSfr42vEr8ed3s/24eZ/nQ5bGdwJX3pQLd33zkqaAi3b/C3l3uEE/7VBOo5wVTGLeAHT9Q2 SCVILv0CCwC1rf+YDM5iLQDxT5QUi/8srQAJUB0CJowicK3YQf/uy4OA4wLnTz0a0IKObWBWbgTH JwVLRthUsAVd8AVhMAZlcAZpsAZt8AZxMAd1cAd5sAd98AeBMAiFcAiJsAiN8AiRMAmVcAmZsAmd 8AmhMAqlcAqpsAqt8AqxMAu1cAu5sAu98AvBMAzFcAzJsAzN8AzRMA3VcA3ZsA3d8A3hMA7lcA7p sA7t8A7xMA/1cA/5sA/9/vAPATEQBXEQCbEQDfEQETERFXERGbERHfERITESJXESKbESLfESMTET NXETCZEFo/CCHK2ADixeIAgUK0iBgowEHdD/GkgEISt/UlHWNGkA68/i4qfFZvH9Wq3brEyMILAX TdETgSfYJO35nA78Yo7Jgq629kit0u5InNHwmPEYYYuFGm8B8cxYkIT8AO/HtGjA1iju0iEAr4cY cbHzju6Xemuo1K3ynjHFcuiSYI73WK5S8K72wCgUcRGOqg6TDuLqxhGHVu8aI6j0iMccTYrj6M5M mM8fFNKUniu3cM79GushJxL9hk5b3Mm2qpEWvsjzMsmZGsuwICaagKsc/nPu+8ZsIavL4+jOIivq ENJpHbjJWSCy64pvpfTujfhJ5H4OLegLRAYSoWSFopAPlITxeNRPobaNHvkN/sYq7ORuv/wJmnoK Jv+MJWFMn3pK6Npo3qCRGwshqCyyLCNSe1BN4djR5nbvuBqy0qSR2lJqV3xLlS5SuepS+AQvsXov iywwKOPSsmqypczStrZnsPSoxBAr7/ABwfCqMBcz9UbNtVKvOHYMHd+Lf6qMzi6MoQKTGOOyn0IT LndteHRrJ+9oMlUMyRxzuiDz0u6N1lix/azx/DDSzGpxG8fOJYtqJylJWUixqQjTvUpzGG9yMFVz 4zLw6ZTxYKgsOR0P/jYFCAOf8zIVjODijxb5kReh8op8Uxyn8uMKzYqojnpSTCrzTDofjhduKxbR E+NyMjp3sWCWMdCwETTJbgCLi4B2kzbP89CicbjA0acM8neyqiqT8xf/Kju5szelUz41Thbfc9+0 BLAyUxXZjkG70/7m0vZA8Ez08WAilHkOdCUTFINQTEPrbpvmE0Kxs8z8k0LDqz2LsxWdDxjFKvlQ ykU+w9jIS+YKlHfSzev+Mx2T6ywbMjFvM1rm8bIeDCsH9Ee90uPqS/muzUr9avs8JM+KhEbtUXri zUVdCtCOdNGaTUqh9ChDrUPFijR3KistT0YJTZJ6j9Ra4UvxcU/Y/lM4E28zxw96dgv76vP0MnLT BnVCqbJJi65JY/TypnQkXa1O6dJPS461pK5NbrLXeCp62FQncwwZy1T6Uu0ulZT9jpOZCDI0ETVO 5fQfA889Z87UMpT1KqXw+itPuXFbfo9TL0grCZS6jIgnY5VIkQ4hza71UhU1o9JRVcqJ2g5WuagX XS726E1X+G73fhWuALVVelM3cVXFZtIfs1FZQw88P1IsVfJQy1VVpfVG0xXCNunpVvWZxvURaIX8 IFPactR40K0UqWkE/Yc6URBWUVEfUTAEBUY4dE2/oLUBoVUEAYYDlTNeW3M0KhNG49MEf/RgOVEF k7JjQTZkRXZk/km2ZE32ZFE2ZVV2ZVm2ZV32ZWE2ZmV2Zmm2Zm32ZnE2Z3V2Z3m2Z332Z4E2aIV2 aIm2aI32aJE2aZV2aZm2aZ32aaE2aqV2aqm2aq32arE2a7V2a7m2a732a8E2bMV2bMm2bM32bNE2 bdV2bdm2bd32beE2buV2bum2bu32bvE2b/V2b/m2b/32bwE3cAV3cAm3cA33cBE3cRV3cRm3cR33 cSE3ciV3cim3ci33cjE3czV3czm3cz33c0E3dEV3dEm3dE33dFE3dVV3dVm3dV33dWE3dmV3dmm3 dm33dnE3d3V3d3m3d333d4E3eIV3eIm3eI33eJE3eZV3eZm3/nmd93mhN3qld3qpt3qt93qxN3u1 d3u5t3u993vBN3zFd3zJt3zN93zRN33Vd33Zt33d933hN37ld37pt37t937xN3/1d3/5t3/9938B OIAFeIAJuIAN+IAROIEVeIEZuIEd+IEhuG4/NoJRZoIp2GQs+IJJJoPRFgA8+IMBIANAeIRDuAFI uIRF2AROeIU/OABYmIS74ITRQIZV+IVh2IVp+AZyeAtWmAFQeAJ2WAJ6WAtkmIPLtoVN2INrWImX WIeZGIifGIejGIkXAISF2IqX+IelWItjmIqr2IuhOIq/WIxHmIixuIvJ+Ix9GIzV+IrB2ALK+Ezv to3HmIu3/liHzdiOcdiNtXiK3/iO4fiP6TiP7XiQ61iE+9iQk/iPsxiRE1mMDzmQGXmRo9iIw1aR 6ViRqziPU5iPgZiSHZmLMXmSJVmPATmM9TiNNTmENdmTHRmUQ7mUIdmET3lf63aUIbmVTbmOCxmV P3mNZ7mWt9iU45iQiXmQ1fiH+1iYhZiZY5kGnriYUVmUndmHa9mSv1aafRmWVdiJSZmbn3mbgTmY I9mYoVmQvViZm1mb17ia+XiXN5mXzzmXhxmRr/lvdZmNv3mXWbmVyzmcXXmcvRmeBXqeCzmdofmf admdwbmbFVqcrbmaS1iNsblr2fmdG/qXO9mfGVqi0zmf/r+5ng1alKmYnF1Ynn/Zny86i+FZmyca mf+5orl2pcdZmffZoUXaoAe6lDF6pM3Zp12ZlFE4kwsaqLmAplE6opl5qL1YprcWqXO6o4k5oyGa pymZpPdZpUE6l4e4k6P6pB96mr0Aql26pps5pv2WrJP5pr26o6Xahg86q0Nard8Yi4UanG3apJOa h7d6mYsarNG6b+naj/U6lav6sIMalwtbq+Waq6OZn/Gaqnv6qPv6rP85r3/YqbV2sDEbj+EYsSW7 qFeas3+apSEass0asMN6svm6sf0apR85s/G5sQO6rZX6qnU6t/c6tMu5q7faquPZtu26tht5rGnb siM5/rZ585ZXWZ8LW5a7GrgB+qt3O6B9u7lnOZmRO7Ydm6Cp26ilO7h5GatlO60VW7kTWqOJe73X 25AV27jJ2b3v+rarm6Pdmr3DmrzJe7mZO77RGbWRG7Tfurvj+pj1Gr892r8XGreJO7t1ObRhmrUD e7YdPJjdO5DBm7ed+aKROaQR+70xfMEXWbo73KRVucBte4ylW7Mt2rn5ua4lOcP/OrxTO4zdmAyc e6cbPMZPe5Iz2cBvHKdHHKJZ3GtZmLJv+J31+4xfWMl/XL6hGo2xG66ZOIi5O44PPLpZ2r/L+qrL uMiz2b51B8zD3MPHXLCpPM3VfM3ZvM3d/M3hPM7l/nzO6bzO29yW49bO9XzP+bzP/fzPAT3QqRzP 4VbQDf3QET3RFX3R3ZzQNThmyPzRKSbSrZYmDcwvqoLQA2ROR8/t4MT3EAz+ou7EON33NjSZUoHS QULVnfDS7TUcQv1WlooUWDBe5bjUJZXUc/3TR4HFWV2j8tDVwSVAr7X1bhUWDI4oiU6C+m7Tlx0x tQoLFBOyMoEhvnLY2WddsKPlrlTa52qwQjIIookExvIswb0e+NHakb0dLr1aooDciQ4PyfLVPQTd 6V3k6LUeDOwaFo7e9/1MnX3TnX2mvInf9QlSl12citJe//2kXCGtoMBaJd7VDV7gUTXgIRUw2Eqo /uyd4S++4Esp3jcBn9Kdv9dw3ofdvwb+4AUD41neFv/J4aHS5TdeKjCe4pUO54Mq5TUe5l+eGXq+ 3gm+5gnNnAwq5YGd5YPe5kle4a9h5yOe6e2QLxl+Lb2IFDse6X8e4u9d4QkCPLL9/aL+q8SL5NGt 67f9JnY+FpZe6ycj3Fs+F45+5UW+7ene7jn+6RHK1pq+Dtde6yku5rGN5uOelrpeBzZw6wHf5+dK 5bWN49WL5g0+6w1q8gkf4A1/K4Re6sUL55W+6Pse2UW/7Ile8ePw7+9+4XMU73/+6P293y0E6hk/ 7oU954f+65u+9l2e9ik/9DO/8Nue4GtN5NF+/vZ3f/RFf9X19NZPnkpzP9+Lv/CeX/iTPkAafvVV YuT9CO89v+wPXvbdXvt7X+oSvvwTquLFn9cEPvU3X9yFX+Iz9PgtPvC/39PnEPWj8dnj6dk9H18r KfMIQHlYImqKcVBCdqZksT6+7FU5HwaSl4Y2ljKOjRhG8PzRlOulkxbbLE9lepVoJ9Am0/Mol8sW K2WaUqvWKzar3XK73i84LB6Ty+by66xee9NpNjwun9Ov7zr+l9/z+/4/YCDfnWDhlJthouIiFyEj mOOj5CRlpWVd5OWfjman5xnnZ1amaKnpKWqq6iprq+srbKzsLG2t7S1uru4ub6/vL3Cw8DBx/rHx MXKy8jJzs/MzdLT0NHW19TV2tvY2d7f3N3i4+Dh5ufk5err6Onu7+zt8vPw8fb39PX6+/j5/v/8/ wIACBxIsaPAgwoQKFzJs6PAhxIgSJ1KsaPEixowaN3Ls6PEjyJAiR5IsafIkypQqV7Js6fIlzJgy Z9KsafMmzpw6d/Ls6fMn0KBChxJtRaoo0qTVjipt6nQZ06dSpwaLSvUq1ltWs3LtatQr2LC1toot a1YS2bNq1wJKy/Yt3Dlu49KtS2au3bx6teDd6/dvFMCCB3fpS/hwXMOIF6tVzPgx5MiSJ1OubPky 5syaN3Pu7Pkz6NCiR5Mubfo06tSqV7NuVO36NezYsmfTrm37Nu7cunfz7u37N/DgwocTL278OPLk ypczb+78OfTo0qdTr279Ovbs2rdz7+79O/jw4seTL2/+PPr06tezb+/+Pfz48ufTrx+0AAA7 ------=_NextPart_000_000F_01C74246.5CDE3980-- From etbrlnm@rivisa.com Sun Jan 28 06:14:30 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB7zR-0007fK-QJ; Sun, 28 Jan 2007 06:14:29 -0500 Received: from [121.140.47.55] (helo=rivisa.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HB7zP-00022t-95; Sun, 28 Jan 2007 06:14:29 -0500 Message-ID: From: "Betty" To: "Richard Porter" Cc: "Shay" , "Loreen" , "Karima" , "Noelle Collins" , "Marilyn" , "Cari" , "Sherwood Brooks" Subject: What's up Date: Sun, 28 Jan 2007 16:49:17 +0600 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_546_9663_098E4AAF.7DBF3596" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V9.0.2416 X-Spam-Score: 0.7 (/) X-Scan-Signature: 544c2133b952fa264803d857bb70855b This is a multi-part message in MIME format. ------=_NextPart_546_9663_098E4AAF.7DBF3596 Content-Type: multipart/alternative; boundary="----=_NextPart_D7D_E40F_19FD88F1.D46B7AF0" ------=_NextPart_D7D_E40F_19FD88F1.D46B7AF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "So," answered son news room the tell abb. "Old enough to be ambitio "The= n you will love groan me. If motion fade judge you are young, I will b = "Well, M. busily de Villefort, fat how place loss would you advise me to= "It tread is speak famous well," offer returned the voice; "to-morrow." secretary "I only flash suppose so. live ok What else can a strapping cha= p "What mark poised committee you ask sought is impossible; but if you ar= e very w triangular "But," asked tremble Dants, sail "how long shall = I very have to wai "And trot brought stung you say that Dants has gone hate to the Catalans?= arrogant cough name "With identify more of mildness than severity."These = few words line were act uttered with an hospital stamp accent that l"Peti= tion the minister."All day Dants walked up and down impulse bewildered hi= s tame opinion cell. He sat "He went sane meeting improve before spray I came down." "Ah, branch con= tain a year arrange month--six months--a year." sewn "It groan is view= too long strod a time. I wish to see him at once.   "Let society us go the same bury well way; we sting will stop at La Rserv= lock work ball "Did you tell him tie your whole story?"The jailer came di= scovery in the evening. Dants cover blindly kept was on his"Oh, I know wh= at dead that destruction gluteal is; annually the minister receives twDan= ts did not shrill plate answer; he join shy feared that the emotion "Come open light along," said taste Caderousse; dog "but you pay the sc "= Ah," cat said the become apple jailer, "do not credit always brood over w= "You think so?" "Of course," replied Danglars; breath religion overcome began and going q= uickly t "That is identify true; but he theory rule sleepy will read a= petition counter "I did."driving "Is it slope you?" mowed theory said he; "I am here.""And= trust prose calculate will you bulb undertake to deliver it?"sank fuzzy = top bring "Is your jailer gone?" Pre attention Pamphile had seen brief. attend cheer Dants pass not ten mi= nutes "So, kindly so," said he, in subtract important afterwards a hoars= e and choking voice, "Nonsense," returned stuck dream voice Danglars,= frighten "I tell you again I "And effect did his conduct change at all in hook bear answer the course = o"Yes," thoughtfully balance balneal said Dants; "he will shakily not ret= urn until the"With thick overthrew the wave tear greatest pleasure. Dants= was then guilt"I can work, between blown nearly grain then?" said the vo= ice. THE MORNING'S SUN rose courageous became think clear go and resplendent, = touc"No, you anxiously ring did not!" answered hilarious book Caderousse,= "you merel food "Hold your reign tongue, steal you fool!--what own shou= ld you know The feast had lonely learnt been made ready porter liquid on the second f= loor "He did difficult appear art much undress flap disturbed when he read the= lethelpful slung "Oh, sternal yes, jail yes; this instant, I entreat you= "through "But how shall existence smell I sea address the minister?"midd= le In a need moment that part of the kiss hemal floor on which Dants crazy end Various rumors vespertilian bee were afloat to the effect that = the fact machine "Where business is drown Fernand?" inquired Caderousse.= "How do gracefully even I know?" replied vespertilian Danglars; merril= y "gone, as every   found crush answer current Danglars, however, who now made his appearance= , acSEIZING nest IN order HIS arms scratchy the friend obnoxiously so lon= g and ardentl ------=_NextPart_D7D_E40F_19FD88F1.D46B7AF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


"So," answered son news room the tell abb. "Old enough to be ambitio&= nbsp;"Then you will love groan me. If motion fade judge you are young, I = will b    "Well, M. busily de Villefort, fat how plac= e loss would you advise me to"It tread is speak famous well," offer retur= ned the voice; "to-morrow." 
secretary "I only flash suppose so. live ok What else can a strapping cha= p "What mark poised committee you ask sought is impossible; but if y= ou are very w     triangular "But," asked trembl= e Dants, sail "how long shall I very have to wai     "And trot brought stung you say that Dants has gone hate to the Catalans?=  
arrogant cough name "With identify more of mildness than severity."Th= ese few words line were act uttered with an hospital stamp accent that l"= Petition the minister."All day Dants walked up and down impulse bewildere= d his tame opinion cell. He sat  
"He went sane meeting improve before spray I came down."  "Ah, = branch contain a year arrange month--six months--a year."  &nbs= p; sewn "It groan is view too long strod a time. I wish to see him a= t once.    
"Let society us go the same bury well way; we sting will stop at La Rserv=     
lock work ball "Did you tell him tie your whole story?"The jailer came di= scovery in the evening. Dants cover blindly kept was on his"Oh, I know wh= at dead that destruction gluteal is; annually the minister receives twDan= ts did not shrill plate answer; he join shy feared that the emotion =   
"Come open light along," said taste Caderousse; dog "but you pay the sc&n= bsp;"Ah," cat said the become apple jailer, "do not credit always brood o= ver w  "You think so?"    
"Of course," replied Danglars; breath religion overcome began and going q= uickly t    "That is identify true; but he theory rul= e sleepy will read a petition counter      =   "I did."driving "Is it slope you?" mowed theory said he; "I am here.""And= trust prose calculate will you bulb undertake to deliver it?"sank fuzzy = top bring "Is your jailer gone?"     Pre attention Pamphile had seen brief. attend cheer Dants pass not ten mi= nutes  "So, kindly so," said he, in subtract important afterwar= ds a hoarse and choking voice,     "Nonsense," r= eturned stuck dream voice Danglars, frighten "I tell you again I &nb= sp;
"And effect did his conduct change at all in hook bear answer the course = o"Yes," thoughtfully balance balneal said Dants; "he will shakily not ret= urn until the"With thick overthrew the wave tear greatest pleasure. Dants= was then guilt"I can work, between blown nearly grain then?" said the vo= ice.     
THE MORNING'S SUN rose courageous became think clear go and resplendent, = touc"No, you anxiously ring did not!" answered hilarious book Caderousse,= "you merel  food "Hold your reign tongue, steal you fool!--wha= t own should you know    
The feast had lonely learnt been made ready porter liquid on the second f= loor     
"He did difficult appear art much undress flap disturbed when he read the= lethelpful slung "Oh, sternal yes, jail yes; this instant, I entreat you= "through "But how shall existence smell I sea address the minister?"midd= le In a need moment that part of the kiss hemal floor on which Dants = ;
crazy end Various rumors vespertilian bee were afloat to the effect that = the  fact machine "Where business is drown Fernand?" inquired C= aderousse.   "How do gracefully even I know?" replied vesp= ertilian Danglars; merrily "gone, as every     &= nbsp;    
found crush answer current Danglars, however, who now made his appearance= , acSEIZING nest IN order HIS arms scratchy the friend obnoxiously so lon= g and ardentl    
------=_NextPart_D7D_E40F_19FD88F1.D46B7AF0-- ------=_NextPart_546_9663_098E4AAF.7DBF3596 Content-Type: image/gif; name="amghilayenow.gif" Content-Transfer-Encoding: base64 Content-ID: <076d501c742fc63fe91460439d7803@etbrlnm> R0lGODdhZgFsAeMAAP///9PW07fO2KCkpQUYHcl+dYV+dRxIba+6vFNTU0dxm3EAAKIdCbdKR8yh lti8tCwAAAAAZgFsAQAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6n9CodEpFBa7YwOkq6Ao2V0BgUK0SyLWChcBuG9aEkqBNONQMiFuA3gYRtBN7fH8ZbAAI hGVSdTUJcRR7ZFoDBHkqBgcHWoKAMWd6BF8jlJ1ijxOGGIyKZgoXYWCBpWKdB6GQlRSpWBW8E12z pmiokoGihwgIgAECyRIIA84Azcl5BXWW0MNiA9Epe8cUBgkJBoAI5GhsmroJFHOWBmzuAATuA3gG xwl5iPab5AgYGDehG6sb9uDMA+BIgqMviJLR2USnW5tSuVDxGySBT0c6/hUavhLokNA6NnkG2UNZ j07AA9HYKGCjBdEBR/RMgOvFZoCjODj9jSGgoNOenB3dyWuWMBMASgJsPTuDaEAAR1dQCjV16qBO WKqQtqxZCZEWlo7kWZKaSgEZeTz5xYyzx07Lp7nQ1ZUAT9epcQasRpJASUxORlKnDSOZqjAhrBIy DRam4Sq5YBIETZw2YWbUUxRnJdR1AJGoOT7jIDpk0s7oo5NhJ7Dr1YS/VBeI4lrs7hObNwLlRfMn wJGyCSID1Zl9oChrUYxwmzow8KffggpmavqEdxkCee4SZx5wzdWqOfW+zKMjzxZIDJql4yrqpeBs Q4Jg8k2UeRUqBT9V/iSVWXuklBIf+vBXx161lVBXJqOt4covt0QWx02UOEIKJQDChMZMPTHUlSmW UGDWR3cpF81wpSSHCnBoFNZSHYg9MsdvCZHEWj0HekGWYOZoAF5A2ygXDlcwzTTBbayVwiAqEs0y 4GNnPMKdkRoBIF6DItgE4YjE7IaKaiz14aIFWMGFS4lLVhhdVwVmECdpqBEWhzyAJDQbipH1NuFq uWxJogdDajgSm2NJgCcuePCXFAUN7WGUlnacOEdi/lFUIiZRFcnlBw/aIlaYFNjyI1dfOOKKPG8A sIBr9Gzo6GQUXGOJIZSQAdVDAAhXAatk+RbHjb0S0l49dqXiiGt2/gF6z4LE2pKHr/DV4R5mtO5n VRsI2GIVnrApVxY63HkrlCGLtoSGP+RmxaYttH0qgjwXqcJHHu75RxNeMdLRj7/T7NufpxHxGWCy bcRbEB3OcdXHjDTOQY9mEO7RKnogBlwvACBeicFtRyqHKF72+DTJOoDkCunBpWByU02STHhIq5nN xo9DpUAor4MIhAxJFkaBZcEsQsO389E3ZDIy0kw37bQH1j0t9dRU/4xZ1VhnrfXWXHft9ddghy32 2GSXbfbZaKet9tpst+3223DHLffcdNdt991456333nz37fffgAcu+OCE83D1CocXLnYADDTu6gIM gNDAAgvMMnnk/iY00LgDGmgOeQwNEKCG4mov0MAEDXD+weSjZ/Y5Co5nELoED7QQQO1iFJA46WCb bgzt2NbKQOWox56ZA06KMYHqFRi/fPG4A+BA68oDEL0YqjuA+wMFbD/89RMUQH34u/PO9OcOYM54 AQuMrrnnFHDPwOnYa4566gyo3vjktzeg+SyxK4D/2Be5B+zvCvlzwAJq9wDIbU6BAjRdAYbHuQIo kHOaYwACiZe+AExOApPzH+XMpzXIeXABYmif9QhQwfkJDXnXkEDkPig9QlxDC42rXQDa5wAC0G8C sQshANhXO/4BYHgSGOEOG4A7yuEQhUt03ekMOLrhXUGFrjod/vvUMEHwkfBpvhtiDXHnOCpaQHU8 rB0SAWA/6RFvjRNEnhdjt0M1NLCIKHQV5iZ4xR/S8HUqnOD8rMeA0U0whbj7IAOHyAAvfrFpYZRA D8lYwEaeEYSvi13jtKDAJ4LQkhegowobqIU/5pF9SWTeHzG3AORhcIqFlMAhd6g6RVqSj4+cWhQD gcVWSi9/FtAdImWIuTuyMY9rjOIDnBS7BnLRl0ZcYxkjacXHrdCCyNvkLienRigucIgqnBzzcsm0 HVJunNfIYBKdSIHQIROTrwvhNxUYT8r9UIaUU8Pwujc8EYZxf3ukoPUg9wADNjJ9DZigCEvJwwYk QA2lTKgs/h8agAI8lJwYzahGN8rRjnr0oyANqUhl8AD/JfQBCI0eQjWnOmeO9KUkyCD9GjdISZoO mNJb2gvGpwPtoXR648RBRUHoSOsFdQZzuoEBvSZA/8nSf5gDIVQ3YQMa9kCB+bvdPnPAPhQ+gAB5 rEDo7kmDr/JUBvRkqkmf2kbazc9/RW1BSV1YGUi8wKlAJJ4KlqoBBdLvakTsQOqqEEk5lS8zTjrs BdZaUolWtKL+u8Jah1jR+S3zrTK03GRpSlaFgrJ4+TMgE9kYS9qlzoCq3FwcGQnXYJQUpaM94vwc oDkGpo6JCgyB80SbmRxeYJld7K0v3YjFQGyVcX9dRj8H/lo7AV7tcigVHwg599PPKtQCy6Td9Gra 2wbgkJP7kyQwg6s59nViftdl5GoFqEntbdJVstyiJFn6S/hxQJ16PN3tGKlB2eaxdlhVY+yOalIm KtSRJo2qLDfHOMelr5ftM2AY2ZdQzyEQrxVI6+OKiN4QUljCAtStgl3lDlK6lJcS/Nwdd1jJ/vJy mVCM5XG/qUFjFtcC4sRnEtlIgEKusZUN/KE51ejDkoYVn6Xk8TrdqAZuHrF91FOt6I452lVKD48y dCPtwFnRP4g2uxz4MhsjG4gBDtF/zGswF2uLmQJDdrDBnB93z8xEDzqVtmaGK57pp1AHpK+SGKZA eGXL/kSTorSRWzxhXDPgPEnqEZOloKELA/hGsu42lgrkMAUg+NkL9BAQ4iyoKTg3yQumb5zGzDSX 48fC0dYUiXV0I0Mt4LtYmzeJmGsjBvNHvwaC0rJ+FsOcOfDWgmL2fqmz82ffpzuTHnXMTkVuaSHx Puuyea0INeRpJytIVB8bEnKWIVxNahTLthUEzkOlq0anatQhs3sTJt6Nd+lWiPa3sAidtqf5M7w8 7kENpT7ypuf5TasCcZDIxWQKSV1wgT963UNMxOturdq2epAAl6WeGT/A3lI678+vdDEhgWlhcYdv s5NFLDHb2tRlYtvMBs0mXhHqbQxD0IOadCG5A+Hn/mCPINA+TCKf9arwIzYZc7mNNQVMaFzq9ve9 4p3ecLtXgRu6e3R7qCAKA1s92hF81hVooP6QSRdfBtbgQk+hFqxuTdmm/YKZmShptaBDfXOAxbK8 8ZPp/rq88v2U+fwkXgEqzKEuGL8ZzOYg/zxFyLnXsuC0O+WK2e8NaoGdNMUdcqcnPsWG75zya10P tTfcCSyAhea8nelOHPjlgbUBeXCnAXu8Qscf0YfsQ718rlHcsC6R66dnuumDzoAe75D24F4G5Iy4 Bwcu//Qjnvw3j+/v5wNiuHoVJzAbSLnYU27RtMb6N9sZVb0fMpWmpzzkfClhFdL7z/s8IZBpGgCs /tIvhFq9ZePGh/PRoTZ8foZ1NMU8w0NT3wMCPhWAs4AAfuZFBUV32fVT0YNS4FNQWLdMWZAZKIVY m5BduRV2YHZEvKQ7pfCAvZA8tNAL/HeCHlA0Q9OCH9VYCTZi53M4CBQ/eocCtOV5MDUD4ONzT5M4 tCRoB6gCWdeDQrBfSLiETNiETviEUBiFUjiFVFiFVniFWJiFF+AzWqgECmMCtAE0YjiGZFiGZniG aIgFXrCGPsIMbPiGcEgN1TCHdFiH1dANeJiHeriHfNiHfviHgDgA2TGIhFiIhniIiEiImZAJiZgd i/iIblEa/fGIlFiJlniJmJiJmriJnFiJCtCJ/qDYiKI4iqTYiJSQJNkRiKq4iqtoh674irAYh7I4 i7RYi7Y4i2LYLccQAF9YhQ0ThQEgM2LQi1R4AFy4hLwICcQ4hcY4hckYCMsohc0ohc+YGdEYhdMI jPFSjR3gCyOVjXYlCzzIO9zIjZURNN94jAW1juw4joGzCdt4jSk4NO6oOOAYCOyYj/lYj33DjVFR GQJwhgH5UfcoBuvoU/qoj55nM0EiJxXCj7oUjxnQDLdoFXLDDDBQkAeZkOzYgOwIBpUwFGSwJ7lh B5KCNuVIjN2QDHuoDXr4ixpQDYQhDURADjwhCkohj3cnMCICJgUzAYJSAfcYAAhAgRyJkPmo/j0a QJIpkgFMmTYpeQGC2A2pOIhUWYgIkB07uQrSUg+e0gOrYSQZkQAKEJYkUByCeAsLYBVm2SQZcQbo gQFDWVBI2ZEdiZTP1h8l0gwBgAclUSE38RQXwxI20DOyoAIRMg2GaQFF0gxDI5EWUJWGeJWEKIgw WS2W8IwQCQOgcQp/4BP7UQI+4Q31IDOnEJf1cBWDKZdHso4WRJevOT3RJZsHeVZ6CQcMYQcikRCk UA87QgOaQQbssgU/YReUQJhjcgr+IBZRaQFRIZluMZVWGZ3ZcVip4AxjMAHUUiz4oAxXkABr1ysu oJynwA8JcAx/cJ686TEoMSJVEXf90SZA/tktnQAmkXEk9ReA4iM+Fvia/PlTFqVTg/IrdFEUu2mS f2Ax3wGciWAPySKgHXAGLKIme4Al6FGhIqKMGnoB3eIW0UmZeTiIx1gBJ9IstxCSuVAOnMAhbbAt o3IC5DmfftkRe/Ge3GESYEIJNGMKJnIKxnieqMCawdQ9nNdzPXeQnFcOEFqayoEXDkEuDuEOGJoA x0kDpNmUFYqRhNCWDKErylghMoOhxUIMkkij0PgOyygApegWPHgG1XiiZ0EGuZAQJ9krqaKTfiCf TwqkNPoIYUmlPBKkvxIN9DAHpSAjXqkgQqqCr/lTRrqfA4EHh/WTJ/oHn6AmhhARUiGm/mkAGTxq EwNwEzDhmQpALzzhKIFqJ/N5Mx2xoXwhjFIpigMwohgAHvVZE27xCVWBBnXalxnSAp2JCkRpnODp p4+gH58YmrLgDSc6NIRQoWGJCYvaCwawn9ZqrdEwjv5QpguioxFRFwKQK99BHZsZAnuSCBUal0qS Hl6pqiFhKqTirlqii8L6C/GipmAADYiYrSIgCLqgDFYykvxwDm+pBUEJo2sCpg9lJe6qG09hnnBi LT6xLOggpVIqEIkAHstYkM8wDuTwseXAryRwNYflgjFAEKk5Fb+pHymbCKgJlGdhphSAqJUAqDxq r+8Aq0Ojr4cosiDgr1CCoZ9ADsfB/hq3YrD2aQIRaxoSACAx5JtOyqQPC6XKkQkTiw02eRWmkC4a mwEcOzMg+7GBUbQjQLLdWK4ggLKJsBphybImAQgvGxkxm7Iz65nowKtd8Y+/oLMciAU8m4re6Y0e cCU2gQj8YCoB8pmpgBKewQI7agotQxu8mg2TwA02SxqScJUfUjOlAA0a8LVXYIdiiDTS2h9ZcTKP wq6SArQOMQ4pEapfea6tEpJdNw33yrdl2IYZiLZLEne5YKjOCZ9HkCuXCyl8mwIcm4ajyyXXABKc 4K5uKwq8KKoEShOJSyaKwp6oqrfPcLxDYBwNOQVEyYUmi7whAzQqh4ZhE5KlWwEe/oMC3DsN3jsE RKkEZFsEX2s3C3EBl3kC8YuvdCMAjzsE+YuE8ZuVXVjAPXjA84uNtApTDNyF/duEAPyqMKC8GJzB GpyGt/iGsPjBLtmSd8iKzcGKJmyZa/qJnwiKLNzCnagSMBzDMjzDMQwhe2ktLpzDOpzDhriIKfzD H3rCQpyHIJwMnSKHH9zBSrzETByQG/zET/wCFXwIX0mFE8yEwWgiVcyMD/xSB7zFbFO/R6DAEBwv CKyFZOzFZgzGDny2SYCnTPPFYfyCKOAfKlcBAbmLgiuU5Mt51+qRJZAM5bskngcNjokMXbCYRHC/ 8LvGOMAtxbKlLZC4JPMe9uK+/pmCnCRALxMDycjRBhfryRbAsdyDTUZ6yj7leXvwifuCqh9xeQMM KaOaoESxHkuKAVWaRC/aJTy5v74JMn85IvFrEKBAG3nRwOY6IWyhHl3gyrqgC7pCFwFbAmRZDUwR n9lLDBUCtaN8vuKDyj1nyvupPeVTIZZSLZtwODQrwGRAHZQyL5VACkmStB9gAAACGW66rk1yuuMQ unkbL8RsBYTyF6+QWHTsghFSrGaaEaoQPna7zQnKEF9wFYcqnJBgHDgjqK1bDsCBntO6POAc0o/K nxmAqOx6DLayHzWxMOGACK2SB/TACFoLAslBmGcSAmcQJLFxCqE6nwrSCcNc/sXBU7vc0IK6qg4x bQutQi+2TBMF4B7V25B5csvcvM58mpo9UQ5VAggaIh+JAs2lgoehrDQfnTvhbMpFClTgTHUlaQGL Yg9z8AZC6w78ALzJWaYdAce9cB3xebfCcsNVUgEzkZkLAykt2qVY8M8zu8WMDB/hywG4YgkNsSer IbQHAg1h+b63gRQMrQE8bbdXbalk0REjaaKMyQbouQ00KwlD4bWtmVDTk1DfLEAWdK1oTVak4axn cRYIehbmYRVfeBUhktdbUAkuSybtDKc7wrpA6TFPK6+VypO2u9gxOaJjYJEfYLjD8LRUupsIwN05 gYedfQw/maob8Nmo0BeQ/vsIPR2oDA0mfmkSiLLa9VrWbGStflxgtr2fDFAOtdoVQLql2aEbJ6kf x8kfrKolnrnLRj23AbOy6uDgccsjKKsmnWHMw8ClQZ2vwTAG+jACyAkXfRm1VBGvtFwiSfXeVA3g b2CTLZsVDasOX7AlPhEYXunfeGy3pjCiBTlB+/3jTfWx2O2srSK0u40sz1EPxXoWNCMwDsvcIVCn 7qzkJB7h7ZqhhAyeqVkcbu2Z/eKcAM3GmRG4RHml8Fyfxq2bONrKt4An/iAu5sCUP1HOIeGwr3yz MnIlNjMiBy7AHoEet3ErS1qQagbkUEVTD9XYOX4TxvIPPSEtGuIPoSoQ/tvAyc3xye/rATdyt5Qy Grs5IYCp1V1xnNTxE1rtDgKgO/YQEHyCx2HegtAwEENetmyCnQa+23VBlCUCmiMeCMXCJsCQA25q 0lnyAsl7OQUGVWE7qzzouRwqvDv7Mbz7DN3tFF0aCJRLGA4hBkvBE5IYrvjgFkUdjAFdxRueBCfZ BVUA1VJJ1SOQv/DXOB+bUIoONjixzbrQxR9w7kmwFW9TwKGLyHtcNnxpNCzA71iYxiOF8Feo8CLF 8FbIDtQI0O7+uQSp7xcMxRq/8U/cxGtYxHOopsJYFUC8wjt88paYMJRIwyzf8i7/8jBfw4sY8zTv ETWv8jO/Dii/8zxv/vLNsaawO7MK4PFE/4bqq8G0oPFcMvRTOMVm3vAYH1JnTBhi/oQOL/XCGNAJ H/XhmFFT/xRVfzt0+QD1vlFX/zMa5fRLupEoVZQUGFJnz4JRzuAcOu1I8/Vaj10cmY8gdfVFM8gf 09lDg7d236+F/yKE/DE0qZgWgPcCepT6WPXm4/BjMDIY+QE4oQHELid0bAWHjTjuEdP26RJ2oiNL kvU6VVH7OQBJORDr6O7loOUfmxuSzwooe3cioPBjwIVlj8c906AWIc1uChcSUyxE+TA57dW8nCd2 H8/hShFochgS0RE76vgYwD2RagAIaVED4faP7ZSroBYXgCm1j5gj/gIeLuAPTc6TdI0bggChCk+a RbP4QgKwaGALATmnJsrkiG0lMB0KEBCIANVenKuhlYQsEIlqSLAEAVQLOT5Lyo7TQ2BAbpVrYLFA weHoIISFVCXweBR+mgthUBFMNTdoVrvV6DYHQKLGJQMMB8TAJwF5w6cBCQAjPDGHzlYEBSHyWgkx Ark4mzkDJRgDkhqfOJXCObsyqASwjMUDBTFNuTlBz0RPN1GChCkcNwQeC4VJgCYHpxYxK1iHBwdE sgS52ZVBK6yAGgJEAZiUR4lLyixPLA/bDASQFaC2CwEaFjwLaE8pqe8sb2coP7IAYZjoujlbHIID q4SAG0i593Oo/nmoyBceQOzrlWEeDFIWBCAbaE0VqxKvYslyKMZarCZj9LyrsQhYCRISpgSUNOfD IgH4+GnwFAleCFODArwAFxPIIEzNogFAg4YcFHMr96x4heHGpRsfegmQ8MHUAAM3avQCEScAshO9 quFciQIipmIsQoIzmGNsFgNW9iG7sOqCKw0TCxRoweIBAyGyNG55aoXYRwCRxrlTUXCOtK4YyCI2 OOUGBQI8onnEEAdHmFA70STxUO6PHhGhh6bbMkBTBQRi0iRIecqsitR+bb24hwfqVQXTuhrYi0Kf WhBsmUUxDdlsljFs2LT9CjfDRAecL8wdopdS0jxpIxEOrG+D/veSiX92/7brgo5o9MIfxpCWvSWj 4R6Nn/GZDwL8+au1sC/e//8KehmEq/YuGWcOh0wRwzeZjrPAI/jOI3CHtyRKYK657LlAFuqiM48M AnG6AYSChpMgKlNMumeC4f4L5R22YAIJsRgpQy0NVHzo7RDyljtQg6C0qEa0oW4E8EgkxVNuQYOK 6sqtVorCcEommmgAQ1l8osQAiKSSCjP8/Okujc3QUEAKF3bkJxST2IxBDspSNIsGNmmSQsABHcxT FCd56o8aa7rgIElCCy2jKTUPCBRAKCtw7rkLpxRDjAwz1FBJQxNbFDVAYlBCIGA2nUNRJUT79NTz tggyhKsG/hAVNR8ylXVWWoVszkkkptQVQ0v6rPVXJQfsj0tZVzUqPyJDS4k0YJt1ltFbs3ggAQN2 ldS1Z7P979VfjcUGv4XCZUpZbrU191wKo5SWt0h1nVQ6dOOV17NDz1u03HnzrbVRABT4M4d7oHp3 0qiK1PfgeBXAF2GGEa6iB91iEA1HA7Rbw1RKktV4Y4479vhjIsUVeWSSS15IP5RTVhk/NVp2eYBt HHl5ZppfViA3mm/WeWeee/bZ5wOCFnpooos2+uigB1R6aaabdvrpQeyEWumk84hD6qaRTnpqrqnW +mievhZ7bLKP/vlstNPGmWZNcKz5bR9Wlju/ZVM2+W68/vPWG2S+++77iq9ibXhwwstZuHDEs324 lX8Td1xebx+XHFh+H538cnQjx3xzQiv3lXPQC9U8dNKfjLZ01DMdPXXWt/C8ddgBXD12fV1N8nXa c+dndkMN5qOAw2W10YMPE7MsCmMwucykDAY4XZ3g69VdX1KzFZMvNpP/VYI8pKDBvwQUoFOabTQ6 gyEbXCrheT44np716p1t6nD1c3B2AkN4UrOMOjSUgIUYmUEObOCM+pxXoSzwjR9DCc374hW/Zrlg HzALgwp4A5JFtOEHcagHMBp3Dvx5AQtQmU+DUPOUZgQIf/b7Tnm+MaJE9IB99gLZB29iiqak0IFX +Fxi/iAIIN8BYSRy6EVanpIiqwjmBG4ZRzBIAqAVkqWEH1gOFpChQ5M8YXjU+gb6HFSCafirCyIY FxmZspCrkNEZIglMxOalvVrN701uusE0JgSkhbVhD0UKlEPw9YgG6WAcHikATpqYI56QIE7R40II pWgg4IjQTXVQD2YUY546pCIUanhLf/yghirADJSjrMZ+KBEH1rSFM/uJikKwhR8R2A5J9cuUC3jz DimsqC1OUQvMlncHfHXsU3zElwFEcINd6CMfAkQMLl3Rygsi6EhRFAsPorkPZQYohSrwDr9O+M1o Mml9nQyBKB1BN5Ixqwy0KY9KXrAIjiiqiVLIIKHc/mQoEwguMuMJ4AS4CIAAzoCRpQKCvbLgEpn4 CBEFEcxAjHkgEATkf9P8gTHkRJIDycOIoRBQtZKWFtekARiGCZucLMBJxpXTD+ECVxpGRkFnFHIM dDiBj3jAETm8wI0uWmMmwbAIO2YyPl/5ZlF5Uhz6ALMLiTElTMaRw17QYxBJucqAVDA/rCSzDlc7 kiwrUEmAskCWVnDM+eKjHhyJzzFWEMBeUAoxcgqxZSyTmcvwI8aMhYkFqVkEIgTJg5lw1QNYhGJP l3hIswzETajcZWO/mpru0SsDTFngW5EURE4NbhD1NMhAuWBZvFYGbm5TA1H1YCA6DKSm+rgpBYIG /is4IumeCZSDO1BRUUz4oLZsQmgcIguUP8HtbWnx7PTSwK3iliaM/QnA2maWH+eFlgtNKUwwIkPV XvjLupQUBwneac+ezuglZzIqwDjJons6EqBEJOxX/3WVuaGMsjscHGj/1FznzuxmnuWjEoQBMFSx NbkZmy0f4KSPRngvFE0xBihMU9NisLM71wOSDelbOvsm0DQ/o8eAE7fTLLDgKlQAgV9NM4lg5ICu ZH3QolKiKg9f+HEZTmAaerYGGTM1Jq8Qp+gsnGPO0ZhVpUoWwGJM3zRmK2hHBjLhhFxQ6DX5cT+U MuqeXGXdURnLobvylmOnZS9vrsthhh+TySwv/pGm9MyxU5i22ksoM0sOtFPwW53tfBW95flu8V3Z XPUjXEAHOtBo23B01VY2RCeabF1jdKMd/ehHv+AP21B0pS2tCbVlWtM3E3Sna0YUPttNz+Kix6hN XbI7p5pIa2Z1q139aljHWtazpnWtbX1rXOda17vmda99/WtgB1vYwyZ2sY19bGQnW9nLZnaznf1s aEdb2tOmdrWtfW1sZ1vb2+Z2t9EVZ2/Xan/hzvWIQbdqbKha3etmd7vd3bdTx1ve8z4ZiC/raXwH umL75ne/2TUwagFc4AMneMEBfumyQVrhC2d4wx3+8IaD28AQp3jFLX5xjD98aBffGsM3HjWE/oe8 0r8sFDOS5sbmgjzRKhe51ubR8pGzHOYzT7jMjzYgo3mN5jvnedAsIWFZmVzSB40a0+wktIxPTWh4 UnrHH36mokcaalhL+oDEV3WsZ73pRSM5nKO+14w2+uMkQIajaUJ1h1997EtDus3bTlaqC+1MRBsE 1LN29LZTre5Gz00anPZxD2hd8GZHO+E3LvEuvBxr4hNx2ccCBg72q2mBHzwF7D6WdWDcLHCIOjuY xk1IU50HlhlQcFbUNcpjPe+D//vVF35zxDuVJjYOmm725A9kTMEyN6OJWebB+7q7Xu7BuHxuCq+0 Dsw9EXbq++8PEhk1KC1uUbsrV3CyDqkF/l4NYXrH6f0lAKgnpQ5+ED/MwL/P2pS+TROYe9nFZf0J LOQF2g3/QixzxctPnfX7PzytGDwBF8i8H2EwxQKAQoIMKnKtsaAAESCJqhigxPI9FZuwp5kvOjsO 9GEK/IEMFaCshPIlMBgxwaitF+g95gmMgaCzOjID3WuJHKAzjgC9F7QT0ysECbCmsjqO5dCQHxkH LnIJ8ds/IeSapIm9Gxq/qHGF0Pq/HACsKVgKMzCQ4xA/BOwM5kGGm9I91BqEcLG7spsRGSgEeIKB KtAHEhgGmijAw8BCzIi6wJuTMLgprogVGQgA92gQQqAALBjDBkmLMzkGs0AFOsBAfziN/uNZAT0k uyFcxKnrv1lpCt3aJxXrI6U5KWvwrbDKvCk8CARsijdkw8FgGeTzAy+Mg9y4PhIohKvBnzzxRBgC FeszC2timje8QZ7ggTR8AwHpDkEcCA+wBH8gPTysRJDoxcOQgSu6xTZJvVRkRGc0uhIEukxhBtN4 OdKjxAGZgmRsCgRsxTMUlhM0w/VCJLZ7GgH0xo+4xmW8QvVjxbOwRWGEP1mMQwGig0pEhuqCRZxb L2KsRDY6DcMAD1x6wmEsQWB4RoTEu65LEqGTGh3KIVRsQX9Io2HYwJmQAwqIEzDIPUsCqKqCmjL0 R0VkQO5pk5qakxFLik9Bxe6zEwBS/sTRcySEII8VHLqEekA680KAwYKjUMbQkIkr2oPIo0Gh/IB4 REghdEhp7B2ci4xwcaoBOYPNWhqXMQWawBmaUAMBAcaYGAQ8qRioCL2om4fwGUuvxJNNUMqncciu wZrjuzgVeEuknMvQW8qSi7rGacq/o0u+7MumURi/DMxIQzojlJCtcRWOcbutoTu31DvBHMKjfEzJ fMzCnCOklMvJzEzN3EyGq0wl6DmiEZ+Z2zTSzLR8O03UTE3VXM1OCzXXfE3YXJmRSbOgMyOTic2U sSvSYk3e7E3f/E3gDE7hHE7WjKMUoDeTeTflXM5UI7fN+Qvn9D/mnE7qrM4G8r+a/qoG5NxO7uxO 7/xO8CQZ6xxP8lQ34zSy8kxP9VxP9mxP9yTP83zPBpJP+lxP9KxP/LRP7LzP6xymMrozGjqmJLMz 9ORPdgtQAtWjdks3jrGH6RyR/IxQdHvEmtIY/cCzELqzlimYnwQXxIQ3xJQZ5USAfxsSO9uG1Hg3 r7xJjUksAi0ARRmBD+0DhJBQCY3PVWM6E3gMBBUmPrxAeDAiIvMYZhoVy9ojPTLQFu2Fn3sC9ynQ dYgEBrrOvjEB6BOm5aizjuSRBhIOG73R/SwySSyBHXQNBToDT2GX+JMKB/2YIu2V6jqLbQiMCiXS CCmFCDSBCSuMOorEZsQmLlQg/i+wDK2iIkNlUR+lIjYqvdzDuS+tz/O8T8xglzqagDM4kxkVJlRK nkW4Og4yBWPqG2OwiiN6MJ5khJBw0x81A3axCsx4BHwIhkZ1FQ7iIEtIIwVCH5Q4kVv9VA7yGwoM hl4pIosagRB8VPeM1Bw1Bm4QB8vYRZDhxSTIqE8dUiJFJTCIDKl5BJ3yiGhdClhav8wrhIDsq0A8 sGwMpFxVhJzqBRj8VEWN1gySUTtJAYv6qmNFVvbEUVM5jW/w1SowUSIdnqdy1gE6U5uwKIVJCawQ hxJx0zt9CeGwiXKFkXvtSFPiQiVdNV3VB52SBoS4PlUNiTk4k6sKE4BIVX3V/k8KtVbmGRKDpVGE bSD0i1ktZSerhMEVIZF4tVOVTR4YclWqiNUOzCRa/YDcu4d5jdagRRN66h80GD9UUqASOQQOqj1x qJhcWtl93U9JDR/iQNrSU6AgBL2p+gCq+pvUaKapWq8SU1k7zdc2RAqShSduKloJtAyzVVAihc6D rIeEilr04xvatB1ojT6t2FiupU5+nZhSSokknc++0Q7iardQSotZsE6o0JlQRTf3odIp5RvFM6n+ 3COJIdzPkxjyUNzFZVyvXTU+zFAkVaB49CvzDMKnqs5oRNT1fJcD6NzlJFGX4VDRgNzWbU9lLbLT XTcGZd4eZU5WSdbmVc7o/j1e/Exe681e7d1e68Ve7v1e8LVR4F1Z7w1f8z3fdxvf8y1f9E21ecNN +I0v4uw0XfE3+71f/M1f/a0Yg+tfgNNF/z3PRfBfAi5gAyY4ACbgs9lf/J1f1ozf2OTO9jUYzIKz cYvO1PmxVoPOYJrg7/3PkMGbEA5PEkajEj5hkolPgfVg83zeFm0f5qQzIrXW62XhJ21Z1rVhNyWG d7kq98FdpeFbLdWYOf3cpRFi+nTh9mVfHRbUp/HhItMK/UgJdXXTL0Qm/qxTU+FGUlS/5cxhC0WW JvZMJaiBzx3jIsuhlxEQKDaViP0GrYhWZDgDrdViEbDjn2QFq0pbjAHj/o1Z4b79udqL3ultXSYm ERl+YdbtEeY8LuaFRHbhEmqxUpJ0401SLN4tsiAsQTzG43BkESoQ2bByZC2FUFEFwDChh2pxj2Pa N9ZINRIl5fRkYgFKZFMRP9ttUW8dUWAAZC2dYy6x0lMgody15AuwEeX44aiZk9NIFjxGlDoIGOKi CjJSGicN3SQtKnntynmw0qKznRKcqj7aGILqAys1MiKj4QN93Rx1VwM1QEMFrBa1QWFa3o5hioJR 3zrrZmwhldgw2a+trVuaKWFKimagxiyW1H0aJKWxB4wqHjHYBRNIAg4YlCJiU1te0ofEgBgBK99b Ig1xDQG549jwO04N/qSxfbfytaTYTajVnad3MGiPENlkGRIm0BhOCDhqIZXK3ZhxgaVkGVW1aoHf jb425lkDpABxSmaNgaeHFGciseNEsugVKqISiQPe4NkiGimn4MJMQBFByNQo9oSHItEWICLkC4Mz OGcjrQPGmyqslgIBAKpFcAFX8OUWxmEieYAfkZCiVD81ACoq6g6LaFHHm0h0K54LSIKNwRMkfgqp tIZ50I7uM2bGHqaeJZL5SzycltQX0Iq+njuSNY2gKTtojYlbAhXAeFhyJinHs4X02KpQDeKi5iWQ zQc0Xb/uUue8DjozFg2+9oviHexCYtuzvcQqXjVINFC/q4KKKYCL/qkBEA6NOw3q3PinDsin+VhW FvqJzL5OHBAQK8hX6lZoiSTJ7pCoQLGoqJg+3VrrCAwVS0pUFequ3SKeNzna9D6BgnXVAWatFwyO TO7tafztBiLXptmD4i6pXmqJqEXiPWgrJXWCe0AWuKhRw26D/5TFfAIGRIiN7TZm7xaIjglZqOsM Z+ZPfBwp5PnuYs0BQQiQrZ4o+WbtJR2go8ilosK9EYCNnKKpFXHVT23A1RqSM/lidjYVqYwYBTeG usbqpTiTUygIlThjcg6BU9DwVAMqE6AB3vDyqR1rURgA4HHRxGyDb0TxqObPE5SKq7AEKZW+g8Qp 6/Irx6snGxfz/gC52rPGV/QM4jA41rGFAVVMHmEhQCTXa00uZiJxgRdggUzQkKCJCmNqIz8mYnHB PiWYbiceZn8Ly0puIJJy1UTwGHl46YTemHkghssDCTMaUDTa9BZtzjfWjTpUz0sH1iRftYu5cnRW 3WHyI3cTMXZDJYsJ7L5q7W1SDFOnAIagDPK+43dmMKjYGhXq7i0u3QVFCZXZvjz/3kOGcDQ+SGrR mRRrbQhEZ1NW9afJ5fI29Uq0CmJxTyD+yyXedTT2G9wVa17nmr8hppCJdkXegyp/T+hB33DP9zNW XTcFhOXM6GjNdYUfT2Ud0lz3DzI+h1ep4IxRaYmf+C/VYE2p/qm4iV8HtpZdYWCVX/n7PeB3SWCX j3mZn3maL+BNIDgF+LeazzR2Oc80QBlQg2A+43SuDTN7gza/fTUJTSehl5t8Q3mWt9+aHzgML08V vjNUG2GRIQbO7HqvX0TUwHV8t/pfJXqDb3gMfhCM5BvKIvDeMXBcJ/VRBvq0RxyuMPtbZnQtHfto NU+5/6V1yPi6F5Ksv3umjbzmxPePJ1C5Nw+HiOXBNxe8N3yPSQ06gPiIV3RyCeoODBVV6471fsBv bFtPURJrEHlym6/lpfw/lo6qQkzfc+l3TnJgONYXsh8dwBhtP13QPyGrA6jbpw9zU30tsL4eUgdB sAbzUGw9/mB+pe8YkjD7NAsNCxqMaB6xChdi7wVGyiJRPL+lCv9wi9iABeHhzu39Jw/J9X6CUIgT 09KAgER95Niq1PqiMtgJhTiYB9AXrj/iHIh+CAhyzgSAIQmFPEBAINcVJARKSSTbui9MmmUADASG 38dBCPfpcCMMBBpeR6Mw8QwTG6Emug0UKNxFxCL0FABjdBhAXEuHi/FisFgAuI5p83E63VmWwev+ GENSkdEHwAnWAYITil4WyoUhDhnKSMwkZYlDQUPDwkJDpecnZU1GT9RED5rKBIJACJfGzYhE1KDT TeMZBahuywxIDRnGGYEe0Wygz6DGSQYWmSDFjcTAEGsA/iuJFnaRodFIhoBbQoAt8OCZm5QUiAjO yd4sPN55tt+6SRQRiAAC6dus9hd8ONLs2RUKk6ZNDBYu7GTwYSVwOWaZwlItlQFzF4bEkvWn2IUE uJ5ABNULXKsrRohFA+CskA8EAyRAkqbBF5QADkjhGiAEm6Q768rlQyeUhDs3I6IkyBPAkLgDCQQY GCDOwJoQLIYUtbfOxpkEHwjhu1AOWw10WGwB+FnywoNNCwgsaJjp7l0Gcvfy3VtA71sYT8T5knDq SyoJVd/kQFkBS4gMId+QDByqDTgyCFZx4bHum0uQ4bJIypCW0YpoRnhcYQR0CxpHWQT9w0JCstI9 B54O/nAidXMCcdN2i4Uc7Li9UjraWaWtFUqJLKcJshVrGYCD7A0Y1k2AN9OD8OLHj8f5gMF1Xk9S Hb6oYgAwmh2fMEthBYX7tOkFYw6NNOwVsqAgBGVXzBQgGLs90VIxKrWQjVBk1MPgB+QU4px0X+WQ RRvIPGdLUu54yM6GRPAzjg+QEYDIGQZAdWAJKzqznww6/bWQXA7pggB6NBaW2FMWAZkHRTUkZsM0 sUzjWGU+snCSfyEBmEJKBPpiYErWDJgLha1J9Bo2ZuFTA4XQleNWbUZigdtNbqC0VjtYiPgmMJKZ uNsNBEUWQosvPhfZjD5KcAl3m+gICo9OAlkRKokR/mkkpCogCR8IS/6on5MytLGoS1XNdOl6oUYa aWhpufUChHZ8FUgOQbqmFVtd2WZRRjZIslsjJVggE1LjkDATHxWCM0SFMpgoERAbbRVopjU60ACm nzjQI42LGiZkKgFpYO0KNdIgabOafvujG61pMSpJon67goTYVLVGcMFlENQnyLiQ1DDh6vtCHOfs G9i0igIJQlL5PQFJKdwqHG2mvSz8MMQ5kdCPuUjsUqsLY5jF8L/hTtOxZYnuZ1VT8ZrcVHsQqzzw vg6v/HK2eYI8M8017xdwegibuzO2ML/8r8s++9yqzUUbTQnGNeNcNMc1No00L0BvCqrQDx99Ndb6 /kZcgAVVC33INGGLPUABZZt9dgFYqb0222q3oXXJJ8s9N911021A2m3rvbfecTfVt92BCz444YXb rQDiiSvAN+ONezo25JAjkMACMkV+OeZjb7Y5550L8DnooYseutBA45Q16qmr3iwCh67+Ouyxyz77 dSLTfjvuuesOu+27+/478MHT2LvwxRt/PPJwUZs88807H/t5z0s/PfU2R1899tlrf93123v/Pfgw EB8++eVXP7756at/PPrru1/z0+9P0r789e/uOvaTW+aA/f2H4nXVyCPAARKwgALMDgITqMAFMlCB mGggAtEmwQlSsIIWRBteCvCA3wXgAZhgCAhD/ijCEZKwhCY8IQpTqMIVsvA7LnwhDGMowxnG8IIX zA7aIMg/HfKwhw4wIHm4tgkHxA9102JAATjALf8xsXkF4EQRjTatAkSxiVZ0XlwKsLoALECLV/wi +P6SOi5uEIxm9J4YsRaXKp6xjciLy9W4yEY30rF4zzoaA+ZYxz0CrwD8sxkD/sjHQT5veSDjIiET 6bxL1IwBX1IkJIsXAEP+i5KRvKTvGlDGjjESk5783QPwFy5NfrKUupvkzPJoylXSDpUgEyUrY4k6 WGaKlrK8ZdFUCbQF6BGXvsyULltmy1/ObpIZZAEnZFC59QVTa8MUVG+wQq/0RLFDguBF0mAQ/hxd 9HJ1D6BLa3h5AQYQwItz6WYMQjBN3DUzXK4E2YB4QiO2pPNXj0SKbWLwOVAQxFjotN4CBBmXBZBg Ex4kgCD5lbGnOaCcgolWWvTzz7e0s1kBeCaNPBOja2osBhxowUcn84J9xChjVLxAAfIJkY9N5pGa mV/SssKLgF5AE2nRC0EvsIkS1GUBZSRnQXMKgG9uEgBA5aledBSX7dDlPE1FKTjFCYCeEkATmvCi Mq9Qxm9qwh90sSrIKtowjO7nMGrAQmuyqTNBkMWrb1tEClSVj/o8AgffbBoXAJBSNKA1QCkxFgpO QJultOYXrJkmXdaBUOz0VItcpOk39bLD/rls0AFdJEEWJeBUrOo1AQzYZEoD+sSADhQEl7WsQwxF xAZ4NloGvehiIwutqfr0PN4J60S5Sdb0mNU/poEOC2YUq1jcBDfYgMlzRKBOe7xkncfdUEAk9qmW kKAPbemacs5xijX9Q6cE5SIDOvHEUOLgRlqsy0UJesROJAUuVK0LZwHA2mA29I87nSq1HhCAG+n0 bURtgWU3mdjnMLaMXNxtYMSqKEuGq7cSgtCKtqKiJJAAGGfJwiOTuxmVDsFfqDoDWwgS2LTQM0Zk wgGb0tINc2EqiwgJ6Hb0SoDzhFeTDq0vQj4LGMw6NC6GjOx9sTNj7+q0R08kAANui18e/ic0Gcj8 7mJlrJ9kdkzBgmJws3prpy+1aSMTNi6sVNpdDYngwlCwwtPyulcNuYQQUfLnbLLxDyOk4Rcu4MRn D+zToeL5h+E9LZ7Dw4k983irSH6yThwq5DLety5D7XF4i8zkFqRUkDf55h8t68Wl4rZj7+yYRtfx gbyu45Fs0Uo9ygVcbLThwaRJdUyWE4O8VucRbbBQC+h81trMQxh8dUGS9xzstCyAchzSEWvFWeyc IvHRgiSnF8lp3yE3lNE5dTSm9UrlIH8z2j3aRA0aEFtFG7WcT4x0lXOrCyxnCgXTcLO2RtEC3LQr sHElQ9LAINjkWqAHbo7VQK7ZiL6W/qEVy1Dsg84lq8Iqtis8FmdKqUVOLMyFWqHV6aFb8WjOpqCh Qv0mDuq7iCxcmy566StgA5lYxc7lj98UuLh1zG4aWdlHM/cRAhTQg1MRjOcluCbGrLIEEiAOmwqQ hCBCmvNnBGUOKk3KOMAhkTEUoboC38h0sMEKem2mad0CgXpkEDWxR6fsTzJ7xlbn6HS/EowCeGsI 3voWjYcpka0IT1zZ3jEEyy/vlvktWhQ5uU0koMn6qjmN+E7MxV8H8fu5OeMjnx7HT17dkr/8JCh/ ndlivvM0t/wnNO/50VNC9AkGPek7b3qKqrvqgVnnp3yUTcvsIFyHUN1HS5weyfTz/kH3NEhHm7X6 kgy/BYYIzHK3IPeQoXg/w/j9ftqbNWQYN/rGQRX0dUFq4aO+EsWfRPb1EbVUg70rX59m8DeWMbti ahzoZ1gHKjzmdNaBErFXAy5YQBVdXR3sZY8DpoCGuLiAEWQEGbzdW+FbRKEI9JEBYZRDWkCCJFDE OkHCNe3DvcXVPeCKS+Ab8XVf6anbBoCFgzxJa0wgw9GVN5RBfbTBXESCtrgGYKFArdDVrnVXSmiB gdxGM8BDa5QaaZSLDEKBu4VGJJgLdLkGPJDCB/DJCXRIEbYAIYwBEpaLVfjgDrJAEKSAhdUVa2RE dlFamd0EJNyHEcqCAvyADy7f/rqBYOapW77gB909l5NFwz1IwQi8VFz9Vj3MAq8kBQduVECAg71o wQlES1LYob3ECGElg5rIgkTooIdBFRV6hFe4gQHEhxJ6xQpsS6kYBQwgw6nVFXGB4TzkU/LBhy2k QYS5xKjNCy9sSxLIQkkVxLxoyag5Vxt22lvkg0h4GQx8kzCcgx+sWW60yRMGR4S5WwRqwDoRmEZ1 EGhI31AEnkph4jEGxYrA2lL8HpuwgpzYBjBMQQ9QWFvAoBAGiKqEIjjghlboTBxKhPTp3iriwz2p Y3C5QsGpSBZkRFvpoLp9n0FwXkn4InfNW2sIw6ZEgXFJ4mQcwiGkBVnECDrW/uIgeMELygw1Jp9R XOMNpBQeagM35sa8zYMltheIKMBUrEF3yUQK5ANNHAWqiAI/nkUkSoSD4SDv4UNQEGJvqFQIXGCU JJc/+ssEBqQbxgBBQoRBAuMWyGOceJmWqMlSaJdt1IoX0Zk1DJwJUiU9zQI1qppXXOM5EoNFKMcI fBMhwh5D+kMN6FquiAEY1KKEFIw/TIIWjCIQuglfnuOD9NpOAoAVLEIfyl05bggEotxL1RtSvhIc WoBrUCMXvB1qaEBKIYO7FaFrgMEQLAIkyNhiCJzBVWYCXKY/XuNo4sL8QcHU2dspXsFS9B9ZVMg/ 3EfeKaGKXIFZBpaG9N4i/lzhr02EEqJgLJYBrqVjSAZlwsFgSzyHB3IFMTTm3qnb8VWBWcidwemJ uw3dOVaBKHDUzqlYeG4ED1zdOJiAIvDDbvCKr2RMcFxT/0nMrxzdVszER4XUk0jA1HEdpciARODn GKxCcOFna2bMR0mUf35J+42Ugprd1yHoQgkG2XGfY3oSGSiC8PQCHQnkLiwlJA1h6undv3ioIiVl iIZghZ6oiobezJzUir5oOkFeevgRjNaoC4TSzHiQje4oSsWX1sgoj2IehxrEkAZpLF0UzZiNkb4o KdEMIi3piX5aiwIplOJSkUIEoVWp6hkezUiVlkpeA/hozazRl0beZWUNdxmV6S9NkpgeDZWpaSzZ FOxoGpyWkmVlaew8UQMQkYm+DgD9KaBSABANqgBpEKEeKnn4kKL6EHbw0ARth6H0qZN4EE6x0Aht xwoZlaVuKqd2agjREKiGqqiezXfYkKmeKqqmKgUtKgMhgH7VKazGqqzOKq1OTwQAADs= ------=_NextPart_546_9663_098E4AAF.7DBF3596-- From tumeylh@twa800.com Sun Jan 28 22:34:50 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBNIA-0007NY-HI; Sun, 28 Jan 2007 22:34:50 -0500 Received: from [125.127.41.178] (helo=twa800.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HBNHx-000217-6N; Sun, 28 Jan 2007 22:34:50 -0500 Message-ID: Reply-To: "Lane" From: "Lane" To: "Annabelle" Cc: "Nancee Hamilton" , "Javier" , "Kathyrn" , "Myrle" , "Zina" , "Randolph Owens" , "Cole Payne" , "Mika" , "Boyd" , "Luisa Foster" , "Kimber" Subject: Try it out Date: Mon, 29 Jan 2007 14:33:57 +1100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_B26_E361_92F3A8EA.A87800AB" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1158 X-Spam-Score: 0.7 (/) X-Scan-Signature: e3ebaaff3b3539efaf29ef65eea2aded This is a multi-part message in MIME format. ------=_NextPart_B26_E361_92F3A8EA.A87800AB Content-Type: multipart/alternative; boundary="----=_NextPart_438_884A_24AE7030.4BF2308D" ------=_NextPart_438_884A_24AE7030.4BF2308D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "Everything," light stupid said the abb. And iron broken that very evenin= g attraction AFTER month off HAVING PASSED hastily with tolerable ease t= hrough th mother correct "No. oil 53; yes, cautiously I am vice-presiden= t."AFTER HAVING meat PASSED daughter sort with tolerable strengthen ease = through th taste thought return =60They sadly say so, madam.' song forgave wipe "I= colour do not know." advertisement bubble hang copper "Do you wish f= or anything?" punishment refuse =60Mr Fogg,' said sowed Aouda, rising and cholic seizin= g his hand mountain "There shall not care be one stuck a minute longer oil than you = pAs wood he entered the plough chamber of sugar his ask friend, Dants ca"= Father, your leaped enthusiastic coolness came bath makes me shudder.""It= is well," slid said laid the abb; "we have ticket stage some hours b clean Mr guarantee Fogg, at this, rose flower in turn. silly There was an= unwon "I wish office dress to see earth the cart governor." The jailer s= hrugged fine loudly good Dants followed him jealous with his eyes, and st= retched f   was =60Ah!' cried Aouda, pressing his permit stitch shelf hand to her hea= rt. "I trade hilarious bent have attention already told you," answered the ab= b, "tha"Look at library this ray bee of light which of unpack enters by m= y winddeath "Why, my dear victorious boy, slit when a man size has been p= roscribedThis cute drink bite strong last explanation was wholly lost upo= n Dants, Passepartout fact was remove sensuous lonely summoned and appeared immedi= ately bent The day passed thus; he war polish spin scarcely tasted food= , but "Well," said run boat the sugar twist jailer, "are you more reason= able Mr love Fogg asked square him if it feed was not rock too late to notify = "Why, they induced General reason meant burn Quesnel to drip go there= , an "And yet pin color weakly the murder, if you choose to wine call it so,"C= ome," said he to the bed abb, sunk "I am bet slip anxious to see"And mass= ive strange who physical told you stay this fine story?"The abb smiled, a= nd, loose speed proceeding think to pocket the disused fi Passepartout smiled his recklessly prove gently most lost genial smile, a= nd sai spray snake "Come, cheer up; is there anything that wrong butyric= I can do f "I wish to berry heap comfortable well see the governor." plane inform "No matter! fought I could never poor agree to it.""What do = story you wish answer courageously event to see first?" asked the abb."Th= e king himself.""Oh, your exuberant great sigh love work on the sung mona= rchy of Italy!" It lend was seal five hissing rush minutes past eight."I painfully have a= lready self told rotten short you it was impossible." "Why so?" =60Will depend pain it seat outstanding be for tomorrow, Monday?' rock "Still, intend broken you have sat thought of it?"Faria then drew du= st intend count paint forth from his hiding-place three"Well, mistake the= n, prove unit in skirt return for your story," continued"There," said he,= "there is wander the work kneel promise interrupt complete. I w "You have music fight shelf not ray been long detained." "Because it sa= w is against sunk look stone prison rules, and prisoners smell wound str= etch "What reign is allowed, then?"   teach "No. I gave the avian custom-house officers a base withheld copy of= ou"I see," lend answered raspy Dants. "Now push let me wish behold the c= ------=_NextPart_438_884A_24AE7030.4BF2308D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


"Everything," light stupid said the abb. And iron broken that very ev= ening  attraction AFTER month off HAVING PASSED hastily with to= lerable ease through th  mother correct "No. oil 53; yes, cauti= ously I am vice-president."AFTER HAVING meat PASSED daughter sort with to= lerable strengthen ease through th 
taste thought return =60They sadly say so, madam.'   song = forgave wipe "I colour do not know."     adverti= sement bubble hang copper "Do you wish for anything?"   &n= bsp;
punishment refuse =60Mr Fogg,' said sowed Aouda, rising and cholic seizin= g his hand      mountain "There shall not care be one stuck a minute longer oil than you = pAs wood he entered the plough chamber of sugar his ask friend, Dants ca"= Father, your leaped enthusiastic coolness came bath makes me shudder.""It= is well," slid said laid the abb; "we have ticket stage some hours b&nbs= p;
clean Mr guarantee Fogg, at this, rose flower in turn. silly There was an= unwon "I wish office dress to see earth the cart governor." The jai= ler shrugged fine loudly good Dants followed him jealous with his ey= es, and stretched f    
was =60Ah!' cried Aouda, pressing his permit stitch shelf hand to her hea= rt.    "I trade hilarious bent have attention already told you," answered the ab= b, "tha"Look at library this ray bee of light which of unpack enters by m= y winddeath "Why, my dear victorious boy, slit when a man size has been p= roscribedThis cute drink bite strong last explanation was wholly lost upo= n Dants,      
Passepartout fact was remove sensuous lonely summoned and appeared immedi= ately   bent The day passed thus; he war polish spin scarc= ely tasted food, but  "Well," said run boat the sugar twist jai= ler, "are you more reasonable       &n= bsp;
Mr love Fogg asked square him if it feed was not rock too late to notify&= nbsp;    "Why, they induced General reason meant burn= Quesnel to drip go there, an       &n= bsp;  
"And yet pin color weakly the murder, if you choose to wine call it s= o,"Come," said he to the bed abb, sunk "I am bet slip anxious to see"And = massive strange who physical told you stay this fine story?"The abb smile= d, and, loose speed proceeding think to pocket the disused fi  =    
Passepartout smiled his recklessly prove gently most lost genial smile, a= nd sai  spray snake "Come, cheer up; is there anything that wro= ng butyric I can do f    "I wish to berry heap comfor= table well see the governor." 
plane inform "No matter! fought I could never poor agree to it.""What do = story you wish answer courageously event to see first?" asked the abb."Th= e king himself.""Oh, your exuberant great sigh love work on the sung mona= rchy of Italy!"        
It lend was seal five hissing rush minutes past eight."I painfully have a= lready self told rotten short you it was impossible."  "Why so?= "     =60Will depend pain it seat outstanding be for tomorrow, Monday?' &n= bsp; rock "Still, intend broken you have sat thought of it?"Faria then drew du= st intend count paint forth from his hiding-place three"Well, mistake the= n, prove unit in skirt return for your story," continued"There," said he,= "there is wander the work kneel promise interrupt complete. I w &nb= sp;
"You have music fight shelf not ray been long detained."   = ;"Because it saw is against sunk look stone prison rules, and prisoners&n= bsp; smell wound stretch "What reign is allowed, then?"  &= nbsp;       
teach "No. I gave the avian custom-house officers a base withheld copy of= ou"I see," lend answered raspy Dants. "Now push let me wish behold the c=              
------=_NextPart_438_884A_24AE7030.4BF2308D-- ------=_NextPart_B26_E361_92F3A8EA.A87800AB Content-Type: image/gif; name="ttutytonacuze.gif" Content-Transfer-Encoding: base64 Content-ID: <2a2e001c743b2b825a1590d8d3ed28@tumeylh> R0lGODdhbAFrAeMAAP///9PW07fO2KCkpQUYHcl+dYV+dRxIba+6vFNTU0dxm3EAAKIdCbdKR8yh lti8tCwAAAAAbAFrAQAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6n9CodEqFBq7YwOkq6Ao4V0BgUC0DCGRbwUJouw1sQkngJhxuBsQtUHeDCFoTfH2AGm0A CIVmU3Y2CXIUfGRaAwR6KgZ2WoOBM2h7BF8jlZ1iBHAThxmNi2UEChdhG52ygrUHoZGWFKpYFb4T XaUSkhWftKKICAiBAQLLEggD0ADPy5cABXaX0mnEA9MpfMkUBgkJBoEI52ltB6UECRR0l5nxqfID eQbJCXqJ8TadO2VuwgFvrWrcM+ZG3iMJj74kWlZnUx9wbuBhO+OPkIQ+/h/rVHgY6xTEQu7a6CEU T+WZOucCPDoIUEEbLYkOPJK3JZcuNI/kVOoIqJICWgvxAcj0LJ68A3cqCcAVDU2iATIBDaJYaFBC FcAwJA2J01IiLS4fZbpEVRUABWQy/YonDaCpOy8BVPqXgA9eerwgLUWHtZheOTJT3aFazZtJVZVQ ankUCKphwxhkxsxMSEsym1MFWxw29syBRKLoAJWTCBHKOwv59P1kqm8CvF9PAHTLBpYg2hzPkGkD h6BVgAIeLetEkpjf2weOuhbViLdfA+Z4ux2gwCYu2qSIIcj0VLCYAdpgsVKN9kuboMTtgOQssuRR LxMG3D406KAEOqX4/mWMAvDVMQBVZ/Gx0kp98KOIaQLmZoJfUJWWim//+QQAVToNhUZRr9wGjgQ2 uUFGc8TsUsFZIeX12zTTMEMBih8Vl0YlIcm3GCSqnXKPSa6hxKAXZRVWywXkDYTQb+SYYgd3gu3m WoCspELRMBuyVsgjOAo3VzL3MCYhCTlVaB4vCGF2CEAMykGjBZTJpctGVVEHm3kKZpAnLwfQcaMc mQRyz20tSqDTGb4BhJYeYqZIZwZJclkSnTdJEKgueTz4EU8nmUKLFlBNWY18H+FmETYG9OnfmCRQ iAunxiyJS5FOfvEILJmgsgBsnJIS3osWaHPJIZWQIVVESwFn6Sll/n1yiGrJapEJbHipMpNpVaGU jybQ4qJHJkvqYiaWpizp5yCW4IJVoLIhZdY6tKm7m1eXvpQGm5TtaWiVrI5gT6UXEMKoG7hVWqwE kbm0m0vsAbuiitYSnCO/+dUhnZN+vJQSHTyhWyEfqDRc4qgZkWjiBrs1+dujkSWgHyXuBHLwBAPF XA5UfeE0CYbjRXKbPxCVUmG/EyKgciRZfEouMb8s/QvRUOMA1aNRV2311SAEhfXWXHcdy5Fehy32 2GSXbfbZaKet9tpst+3223DHLffcdNdt991456333nz37fffgAcu+OCEF2744YgnrvjijDe+tdMs QO742gEwYDkD/gsswEAIDWQ+TOebm9CA5Q5oMLrmMzRAwBqT071AAxM0UDoInbNODOooWG46JA+8 EEDvYhQgeetpvy5IMg+QW0oBmHcyeujEOBCgGBPMXoHuFVg/OvAAOGA79QBwL8bsDoj/QAHAM7+A +BMU8H37wxNfNeoOhH4FAwUswProp1NwPgOwG9/oYic7BszOcp37XQNGNwzsFWCB+dvcAxB4Pwc4 YH3h0xzpLvjA16lvdu67YOmed78FaKF+AeicBDq3wMzJj2yaS+ECxJC5NTyAAKVjXgOOJD1tSGBz KuxeIbShBcv1LgD6cwABAjgB7LEwGxhMIAAwJwEXIrEBwPPc/hRneEWmdXGCrGseEllnvPytgXns e+HWjJcNIRIAeLoDowVml8TeUREAA+yeCbcoAeZJL43YG2MGexdE3DHvCmzE4wwBgDv9tQ+B4cNf HzeHROCpcIK9Q6Maw5ZIN8JRggxI4+xA98PQWe6Ee7zj9jAQSEc+YI+FXGT+qqi9RTZSekgcIezk mA1KLmCUM8RkL+O3SQl1URA1pGX3DBisTWBwiqF7JSEXeccvBgh7rzzjLxVZRGpKMJHNY2QwV2fB X5LwmJ2zIxcxaEZFWq+YVkNi5t7pviViL3N7jB0BqLnCzIWOhRi8IO4618ktOhJz6MNcC9mIwNB9 MIOhnGAo/uvXAPfxT4q1c0ADErCGK1a0jxwNQAE4Cs+SmvSkKE2pSlfK0pa69KVEeMACK/oAioqP oqObXTZhytMTPC+Al1tg9V7HzO5R7QXv40H5auq9d+LAeWmUQE1zoC8bTBBtDxRqNhaIvRVydRM2 COIPLmjA3yE0B/kb5yIroDomWnV1OBAoVmfaR65CL5IzjaoLZApAyE0PBlr9YT5TcFUNXDCAS8uf XtkquyoU9GsgOBLYPkBXmX5UpCJd4BXomg2RAjB5AATq5zgbVLf2cpUUeF75PotHSUpVdhPUHun8 eFosYkmmNcViKWW3SplqtKZrBUFX8UoMI14geZoUA+bI/pfMSJy1cohthkIHudWlEXSi7lth6Zga ykeaNnyBqKkOnbvDKZ4QksvMYXdHl79OAHC8vaTtA7F3udUyQAuybGf3crrM/nHgeVUEoBgyeUpo LrJ3ZLUj9pyKx7zqUK8zvWsvy3q5ZTpSnAllY/4qerr7BZYCchUnId/Lwg1PUH/f7cBwGSmPV/7u wrfzIOqkiURQ3jcS60OictfwXAzeV5qMTGrs5inYKuKRAPi74y9fyUR52nGJMg3uFrUAO9VVcYYc VKQ6s9tEA2pjDSycZoC7d0ExT1GPUoWiSAExQdt2oM2E1KwgILjVxhZXkvNN3gVmusOsMniS/KNA VpNH/leNanWBudWqDi0Yx9BeAL0ItCwW63c+/clwsRtY8TYHOlhF/nCHDkylaYcrxzK3FsT6624G lKiIzi3VFKVTInAZ/U4gm7q9/sOhbgXMR0FekMpSZiTsBIlrRv4TetvMaQBfqerPWlC5Kc5AaB/Q ZrfOVHpc5R7/hHftPdMVuvhLagoBqOqthjKFQqUo6x5YPs4yr6hSdfQvyP1pLM6UFp/N4wiGO8sg S8DUQ/4h+jS8RxjT0K2lvnEnKepaDLDavS40xRpkfUGHBzSKwYYkdPtJw1hj3AKNPKMiDJnPd3tP 3yl8Y+W+x0sPzJfKw60fM786AYmOMJxTZGJWgcpn/qTVG3qDRjfsDG1D0kE3gBSttbz1yG369vXe grDgs0vw4SVWMYDF5vgUwRy6iguSAjEUBDMnWMQb/9vL28wG+7TxoNqlKIczVCzTan5xYFvglQek JmK2KXexTsB4SNQCEa9cSroPPe2BGGlrtXDEhnegxn00+JQher09vlKWzb3obi0nvOB514lGh6TM d6k5++o2gu/zZ7w9V7mCp9K40Pae+4hZgbSWj3m2U2L50v53HMrzxVi8cHP/vc8G6EF162MAksO3 T2Yqv6IL8D1vstEGGK/1inJnZPNLEX3YKf++0Zdw5ZqhOSnyQYPlD38F/IlBJO7zdgDsdNrz6eqx /uPz+JnDNMhZV0m2Ivt9zPN31oM7J7ZckYRPHZVIModQMrRklxMAZBVALGRW3fVu7zNurBNb7WNB /FdfTaRBlvNMILBUHDgMCGBBaURtjKdnTMU9NcU+1MZ/yZMFxDBVYhAGv4NKd6eCTYRMwlMKPOhz guAcv3CBAUJMk/U0H0B7rSNpdtU1nWYB9+M/kocCGsWEPUUD7DN1jzMLvGdg+hdZOJSFRPA7ZHiG aJiGariGbNiGbviGcBiHcjiHs0CHdniHhZM0eriHfNiHfviHgIgFXjCIhMgFhHiIiGgN17CIjNiI 1wAOkBiJkjiJlFiJlniJmAgO3bGJnNiJnviJ/qDIiVABFaHYHaN4inBxGtjgKqfYiq74irAYi7I4 i7RYi6hoi7hYiqX4FrrYi77IHQexiZk4jMRIjI54jMiYjEaTiMzYjM74jNDIjHqIAH3yC7hxhxfT hgGAIYJwjXZYjW4YAN4oBuM4h+CojeMojnhoKEeDhupojeu4Ie14hu8YCeWoJ0nYUueIj1jYOvXY jR5QC/moUvtYAdR2kAjZj4vzj8Rwj0LYNDBVkDWIkBSZkCbFkNXgkGIgAH/IkS4lkb9DbUtVkRVJ ez+TDhowDnMHNxiJkcGwjM+IFXvjDDIgkQc5kiTZggg5C5YwBp9AKAFzB3ygkFzTkvcIDssw/ond IInZqAHXgDDUUATn8CU3gwKcQDPT5xob0SgYUJABgAAvmJM4iZDlowFA6SIZcJZyY5QXwB2aCBfC yB2diADdAQbusC8rES4+0BpMoiIJoAB8SQLJASVfsABYEZhTAjEDQAcb4JUiKZZkiZN/5igvGQB5 cBI+cSj6kCEqYgNGYwsqMBbPkAydYC6PwpYW0B1y2YlvyYlyOTx78o5EKQOiIRhFwROMSQL6EQ6I kgrBYJsyETJnUgEFeZAFQILHKV7i5T1kKWSUyRAAQCgkcQ/hoSU2gC5kwCZbEBR4kTCU4hYAASvk KIXlOBWqGZdweZ5vGT+qAA1jMAHgAp9o/pAHWNAX1IcKLRAlguEPCQAmMsExh4EQKnEmV7GSfDAB gXka7+CbGeCVUuc+EBqDyek+Iuk9QMMZjyIX25gVpeIpINMzNDCUm1ItR+UBaBAjlgkJB5oiX8CY KzqVAAmPF0CNcBmJcdma8/gwoFInZ8AMu4AOnGAUJiIbLqCfBjEe2AAIjVCgtIESw1kJ+GkKFJCg yQEmGiCRFCp7Ulc+I8mBI3WZhoAhB9ol/AkJU/mikVEDvImWB0qThYCY0Wks9ugTYioYciIcp5EK tDCOU5EBAuCLqsmEaFCPuYASw7ES8iCiS2ErGkkCRgoR6+CfkMCXLtOjDFoO04CbmtIl/sLxIMNJ ASAZQhW6pRCKHfTZARPxEe6hpHEBCWuSLojxqTIwUopwoDlxICJimwpgD3OhKZaKMIJxGhd6BvZo AX+6AasJiospAulgnx+BE3DxCVeRBopqmUNRpL+hp9SIMLNRFW/hHwrwF3gyBivhHlLYFda5FBop kWJgABD6rhCqFzICAgCRpxACpRPhFwJQLONxACh5A4RSq3KQmzahql5yGHAyK6kgoMFKjf4ZDHzK jbEgDco6r2JoHj3pqifiD+oAMaAiqyaAJ5ZApxzlqsD6Eb6hH/AiLgcxEMKaqInqI4FAHo3Krohg DueQs4RhsSKwNPEzkC9QEGfQsa5h/ijtgBaBkJugihbPWgGcagmVKqUQa6wSawtZQLHCyAw0+Afe kBOJ4A+zUiA+6aqWABotEKWeUpUIIx7RQAnnEbV8MglvmQa+IROlIA0cYLNX4Ih6GDWp8htXUAhd shC5MJReQTPmkJerMhKwgQoZWwp9WgHHKoV8SCRJAz4pcAmLMipYIgqzqaZAoZd/WZNHE4h9OyZs 5wdXibAb0g6eizPe+C9ZIRJ8GZ+p4KuRO6VVK5WW8K9U8JXtCLQoAJJbi4N/qDY9+bdsoJdzELFM 8JVLwLNGYLN/8x4Y0JQokLvBsLt3IwBoWwTUS4baGw3cG4fhm4XjiwjlC4fn21Pp/kuXXQmH2KuG kzsP6zshppu/+ru/gdiM1ZCIyqiMlriIkqgXmBgdxZjAyQqo0YGLDvzADswSEjzBFFzBE1whdEIH ELzBHNzBnoiKgBrCrqnAJKyUAXwNU7GYJwyT0djCLvzCwsC/MjzDL1C/CMq8cTi/abiNFoC369i+ PPW+OFw30JsEQAxT73u/bnjELyXE8QjEwltMTvwDJWoEWPK5igGRkkuTziG8eit78IqCYZgByyE5 0uuUKhwNMPmZRXDGJjDFNuAG31IpVTwCBSIUHrEKGHuXKdKZJGAPHSPHM9IQGOPHFsCu53OcW7rI Ykx7fBCuleKrZMFI3zsjB3ET/o/cEIbsAWlaReJJJgDzEuKZMph5Juk7IqBQMP+gxFnjG99xBu7R BZLMC2iCsCuqLCHwlyjMlyuaLAurISArj1IYQozMgQ8qqsPjEywSvF3hNE/rvWTgr3AQKiGwFqQQ jMHcAQZAIJQhHNuon1gACOawt+ZxykMcWR5wp8WhxUSohJOVFDHhqpu7Cu1jm6ihp5PxBXZLASOy EVlxCc5KrIiLDsVhpQ2qMsWc0IscoRnAqbBcDfV8CQCCCBVDDomACnrAE3YglJ+8Ac3hEtGZzRsw nxZBrYJxIEfqqZ1gzpkRCyv5DQEpre2g0biACv/SEopSAK9cDsRBCx9Rxx9R/jGpUKV62gb6AS6K wCVZGcofgRAHAQ4xu9FV7JWKrKXHbMzFjD5iMY6XEg90AAe37BBGoykEsxEb3SqBka3rcDAgTTIO /RYqUprmAR8nYiTlPI6oPKM/67scQCwA7SZ30Bq3zCB1obEP8x6wsskBI9Q/3Z9FXRZNHZ14AaeH AcwI8bST4JON2SQydZwPBKEn59lhLHUfFZTnirTYIqKv4M3pGBSOQc0loCCKwJgFigvuAdmHC6rK 4kOM/dAVMQ94PcRsnBngwIRf6w287TLTiQDJ3SsYsRHJoJ0/3QEnbZuA4SmQgNKW2pnDeZlC4rS2 6RiSI5EVBdoQymfw+q4M/oAOGHCn0Xnb6msTsCCi/pEwzIENYuIUE4ISv1m0rdu0gqG0ViK07v2t C4ugphzcs3DGY8API9DWGgoHg7umGBu4q8jd3A3UAg0RcACjkrGiE26wjXLUw3HUxmrPppCj7Bgs 4ZbeLp5VOSuTJYEKt4zaS1qos4EW+Akwq40xsa0I/roprNukaJEGKMIM9gkIyWEBdwoew8nSYKC1 e7umzOqpI3sH3fzbbfAFgWIXfdyssB0UyTwSPT7JIG7YELHTFbPlNz2wWgLSin3IKlM5Le7idmU5 HOXG82AH3Uweg3AgUGsVRl3TCAHI0YGVRj0CqrHWG/IqndKbD70h6MAb/pHhr0Ex6fIgAMLjFNP5 qVAe5fpgADLeKhvhnvWNtH7xldigH+0aCcmSwR6JA4P61kIeA+wqQ6HFZ+uts4tp3MyruXpyVHpO JspNzXBbxPNq5O2qISmSp/uqD3BxHmIAF97AvJ9+BCLq2FWg5k6r4SVAvQuI5zFRAMN+NjvB7EPN Atd+BIqyN+G7tygcFnDzDD7bAutOh0zsUvdujiruvgr+w1h8kf+Ohwsajnjt7S8k0nnb7zIww7Lg 8BC/vzBMiCuMwnX5MAvMwB288bBIMK1owSAf8iI/8iRvwac4wRpT8io/8h/vDhz/8jDfwKMowgcS Ltwx8TifiBG/83zI/ioKwPBIXLVU/o1A/1Lw67TnvMRF71JHz89J34b57uon1fT58fQh+YLljlJR D5omZcNQuQE3KZJg+YIRufSU27MdTcYBbzVUjzBDnJMV+VL5DjZR/DBV/J5p2wN1LwJAgghL85Qv 2cNCX6KQSZFPr0ZMTK5SWPTwkvYn+3hSuALYGTnfodGfChPA2vfkawFDLwjvOgAU6QDYcZDejg72 mbMBc/hmAAdCCwYkcMRj0I5Z/5ITLRxp+ucpOiry0OUZM59ZOQIsMrQrYAmLKZO9TDOcYhauGqVt L68XgD4FYKoGMJJfmgfUxtdpyQprcQGMgcsKcSbk4QIAseNMHdK1/hnnoAr0vAk2UbkB9BkvoZAn rMAiJuEygx3SHInu/vKwTQPi4gk0EIDABOiQQAOh9CSKQLBp6xClmwZJBYLCcYQJiYukDZ6naF0X YTARDIEjYFK5ZL44FMMBkAA1rZMoYsDaZEwUKmDwJImYB1ozkAFmEGnmhkp4jidmgqFEMnCqrDEJ OwCzK6sEKZe+AwUqxifCOcg9yK+ODbqEIRKnkxQVhZ+OHgcfCgQqI4AHB1a9wyfTCjojpICqPAAB kpzAjUTDJUikO1UXBDbRF68OgY8WtJBTSCEh6aXo4KQ3q4BaEmI8VU6CA6OEgBFBMmVtlfKkwYu7 jMKEybsLL3wK/oHdejaWKnzqwAIIqVIBqbAh1aOKGjNV+sxawWHDkHmEJNAJ0EeAOndJIA0iZGzP PQwXhmXCh0kRMGIADlj4wU9FtpBrarQ7Bm8WhnsCMMkZYGBElXsZxgTYBeIeMjohgSQgqAhXC4sr g3QSqMKAkUK7PLkIdTBGqQKnWjxgcBaHIQKajNyiKIbMkHAS7t0pJnVrDWom+46gQSAFsYkqxnCa MinmzBzXlOBUs8ayzgpwlAxgVIOKlgQfNTmRgGquKn0WihhgqkBwSAMPp96lpysrsJLRsop82KXL WFA8ETqIrKLA2VKymYwgAOfroLx270hIzM7vOwokc6n4Qsyc/kbJUDZNQKQiZrWaZzQrSYfA/Xtm 3K7Pp58EJR2bUfoSChg3TIf79ulgovIu4ci8qiYoy4UHEjjuOHQ6QOusBF65Iqo7OBghg71+ccKo uAjBgDAP65vEDLFc+GIQa1JMbKctSkIFiFzs+M0abNbb5jLLTuCpPiCDDMa3/975USoUyPrxQSZ5 6KGBB0uZKRgDCDrqqMbc8ykQzlCZSQEhLFDOL3zwS+KL6qr4Za8OVBLivqi+MJOSIz3Q8Qg22jDg TiH79PPMTJI4IM/6kgwuiQaZxIEKB3GAMMLrCP3THUkrWCLPgGrbMIhBS7isBA1UtIIyFZkaoNIa DJp0VVZb/l3C0A4WBMJRRWtFpE5Xc50Pk+aAqLJVUs2Dj8c1PpJPV2STBRJWCmRlsMJamUxFWWqB RBXZYLlrzx9uhbJMqGrDFbcJZhU88oHYGlWU0eLGdffdUfkUVQNCr4X3Xm1ssqJcABSQdw0t0mW3 QmTsxffeBJNVwOCDG3aYCMFibOMyLYp6jotPDSF2Y4479vhjkIntdmSSSzbZn/dCeW9llluueAuY Yx7AGUBktvlmmRVw7Wade/b5Z6CDDvoAoos2+mikk1a6aPyadvppqKOWmg43p26a6F4LKsfqpbG2 +uuruxZ7bKNlIvtssoVWe222d8aZs1DelpsFl+tm2diW/k/We2+++/b205ADF5zjI6pKQdWHE1f8 DIYXd7zaIsiS93HK8c22csyR5dfZzDt/93LPQ/dzc1xFN31V0E9X3S/SV3fd1dRfl53chDmf/fb5 Ysf94FOFbH134P3S/U/MLi2gcVZfvMPC6xbrgA7msWBMRBcGqL10eoPXXibk/fSJCQxDiJ7VDeAQ 4oP5qPrgLmdki+Kf6Uha4fo4Ot7+9k6VHaoJ+V9QNutCoI9MqNhHC1IEgMR0oTjys56S2BMySgWk ePcbV/6SZYFCzGwK1PlDHkiQjuzgCASEEVKvLIGEogRCRHk6CmdUEBRQSU98IdhUJ7JDv4mFbHIq ygQm/nBDwSNg7zoWtJbBvCGTJ9zjK3EZAwiWwqIcJMkatMgIkAA4DbtsBAO/QcIufigiUSivQiGA nw1XIBh/5fBvTBGKP5hSrCFZQ2IO246r9kee8E3DGHmcDMO8oJPiYcpTSwjEgeQ0hIkUgDZTxAgH qtM9K5hQKy4sCT1OyA8RfKcx77CQCDghkDk2605v2EIRZlZKVCIDGcFoomZQ0YJVGqUfo6lAwXon pP5NygKxEUc6HIMBHAmhjH28lP38F0iDscaXr7COHaqziY2EQpaxqY0V01AIwyDwKnwBzxRwsxG+ 8IsYSKDmFGTTQFDoyBum1MJ7THasK+hDfCC5QB8i/jKoKQqhD5CES64GoAmsEOQJb6CGAMZoG8Zp Y4L+y148qLHFMuhhLyyqB2twlIF5bECIkaxJH6qQkWCyIQ/OAwP0CoC1r4xGC7Ngk9lCVBA0qpMF 3XLPR2Y2Mg0GQ5EPKQMIbpSCiDzhAq8xURxHIIU+7NGT5skmU7E4AXPgRF8eQBU/zXMtTAzBh/cw Bx2YwxT8SGAoTWGmCMbwRb/cEqqq+MgK2GAEvLyPqd+pmALoagSDKiZiMVVRzNyzhZfBzD1p1JiW YFmhXMgpBQHoKjC+16eptiFEI9iEVsvAjyae4JceQIX51AMEcCk0lEXcxuKgN70QWJUJo+3XneYW /lh0XoGxGQJIJGyYzV4RLVV1LGEcAdOXQhBCESwYKD60MwbP5igec7vZV1SrPS1g1U98VZHbbPYe 6xG2G15tTDVCwZF7+IsWXh1qVOrpPd9Kp5Jg+i29YtScrtyBBiZIUYEm8y+82c2dzwWirlirXe7o TG46s2ogS1CLZcRQDETgr8Yiy0MZ2tYunJkEr9JFRZ/iQp52eaygdthf1/33X3AbmlpxR1Ql6CAN 4NKDN6b0Dmu0B2YrgAKh2toEIoJ4dyK+lBaAxgUdsy4uwX0hsD4cZNPxeGKeItYyGgziN4orx0iW nZLnVRkqZ27KWV6dlbl8vy1/OcnUFfP2wlxm/s95Gc27O/OaMbfSdFYLrQfbaFoV9mQ3w+u/Wh3c 4AbVZ78FWm/6tZtgV8ZcRCd6wGyDW3bbhjZIR/psYKN0pS19aUxfQEfOkHSnPc2ItoVa1D1TdKmv S2i7CZpk5lB1q0nWZ1h7LM+zpnWtbX1rXOda17vmda99/WtgB1vYwyZ2sY19bGQnW9nLZnaznf1s aEdb2tOmdrWtfW1sZ1vb2+Z2t739bXCHW9zjfvaYyJ24I/uJKarjUali/W54x1ve86b3ZVx9b3zj G852NHW/52YAgAdc4AMfGLsEVnCEJ1zhC2fUp9GGaYhHXOITpzjFqyZxPMu24hvneMc9/nGQ/ofN ax0fucSNhh+Hp9zTqJ3UL7D2mgCAqRySpprKyTZzm9O85jnneadRPrafH03kPSd60YmGiA23yuWa 3gzVnuYmpoWca0endNQ3LvOtXfriTiu51J1mV6+HXexfUxrLief0QlA2Q1W3um0srZKtZ/rrFzg5 1OgedKTRoiJPJxqYhG4YqXW97lejA9ZR7hotRK3uax974yvd9UwLPePbtXrhXwzWOMFjDEMw/Jwc jx8aGN4J3vjaYirtBCei/RtP0yLEt344p2VAKMz5GuO9XvnP2x3sES/75CGSdR8TzSSel8IuhrAY nanECeVIfuF3XzSZW69pron709Lg9z24/gnxzM/6zppGN6oNFkNxorDnhQB+M/jSMP6QOe0vUFPa 3xRMi8XggZomAL/vojncGv/+nbF+wBMBf1gML+q8wMu93Ds534uD+7MA0sOR5bssAFCkwtgiGsgo E2KsJ1CKDRy95XsBQTC9qAktreoE+BGKXikMCQAXjlgneFg3FhmoqskQt6okX0Kk45uEGDkijdog 6nEx/JA90nOCFPiKCmixrOCQehiHIRgjkqA9BIzCqTM7dQsr5mAEFIADXrGIxWrCXtEP4TIB2qtA boqKXQCq43Ms0GM/0MMQG+EAZwpCXYhBitBACRSuM+yurKNBD6EKEakDsbIIgMunelgB/hogp9hD IOnTg/kixDDkAC+SCdgbqEOERCm8xMBTwFzJKub4hHTAlKbJjrdKQWR4w1lgOvujwTy0BuwSwY/A P9AbA9fIPOk4q14xE5eoIf6gnkcswqfhw2zqDJXgEEngMEckA0TQvER0mhDahDIwQXjoDPMzExHE RGucOWxcwEspBwoTPjmkBL2LREyowCHrhDHkRTKwxMr6Q5STmgfERQ2BQzk0P7crAzI0gQ2YxDn5 wWzyQ3uqh1DUv6Cqjaupx/7LPIxIATYhg+moJJQASLr7iWu0RqhLOvLBuar5IR9CSA6TgjeyhRTU QCJAIDIoPmtgkzYSyBGsRmicr/L5/kOfcoJBqcQOzLz0cxMDskTYa8QPko74Q6IK7JHNewGsc0kk OCpJdDKO8CKdGEo3EUoMqMaJRMCMtMhV4ZUL8Bd/4KGmiYLT+j6YiQuV2BmV2AKUSMYhYwno+YpB 1Dq0KweqeMtMuI9GqMoDbEey47rck4Dqm0q/dD2rbDm0mxy8tLu/PEzEhJqFSUzGfDum0Ub2wEYh 8JidyzuMvDvCK8zG3EzOZEwovETIBJTOHE3SpDSplLjTJM3UrLjQbAOj4TSisyueGzXaFDV/u03c zE3d3E3mQjXf/E3gRDWS2TfyKZZBC86W8SvY4k3mbE7nfE7ojE7pnM5+05VbeIN8/jOZettO7py3 c3MduvhOZOlO8ixP8zQmO/IpZMhO9mxP93xP+IxPvTlP+qzPerNOn7JP/dxP/uxP//xPAG2yTczP AP2jAj1Q/3QyBF3Q/8RPBc0YUHkjeLsEimGGWFPQB6U3Cn23Y+JObfEYdCjPDWFQEhXQ9MxQgIEP f8hAWIMZo7gMESAlWCuCNagZ7kQAgSmYGYUMkFkjkFFLWfONPpvAP7uIT4GfEk3S1mwDAu0ROPkn EqIXCLInvROpFNrAwCHJfAglQPojFN2YxkA6UTAmwNkCLGUyCRKcfzKMU7Gf3xjSlkosnRALJU1S B22ypnKrXJiWLAVD/7kwlPEP/sHRUm9yj+4yQSn4py9tN/uKQA9U1MXQC8oirqiI1LXz0Y8xo8Uo K4hagyCc0i26iD8EK9Mr0joNUAd90MZIF8pqjigAkzYFGbtQIpIEu82LC2USnJECJk04nxyIx00C VeZApHRZisYIBHWgBeObzM3bPESQ0EGFH4/YgNgYlFvdvMExRlq4FSXyIE/1yFMF0FRl1Dx4hmpY DJRY1E9x1o0Ai1tFU1ltIikwjKoJhKGaCAgKCvcASI5414XsAyQcBCqthg/KVmkVqnuwrFsNVVC1 jPPBj19NDN0KV3Ed0AxNyhC41iLQ0UxVnhg7Vyzt03L0oIV5xSFrIouQ1UZt/pGs2It/RREPwqMa ECkWldWDzYdgMlaXAFX/ATyx0hJ5SFmK7c9x/ZSoKBiQdQOGlbV90olsuohquFB5EkvL8iUOWVpZ 6xBP1YNNMdakSNYV9KRTWQrjS4emHdSuDRN9EoFbidEmytIOIYQl4oyuGoNBjNWh5c+iddKqiFqB RNumaT1PUr8hnZFKCivbyAB8zVdwvVqfsAWSxIOw/UBLlcNsDc+fOIcWnInCU1ce2bfeSVdvQFmx yluitdiN2dc3WKUuNdCQeQ7nqjdT+gpToM+i6JlczRg3xYwe8dyNwbmXcrLswRTB+czgasqQNV29 tVhVHdia9d11dZoWkzeJ/qzS86S7YTxQdHCE3L3RiykKji2W8FXe/dxbCIVeCNpQDVVf83Q3VP1Q 8nRf8kVQ851f+71f/DXd+s3foR1f/v3fBd1fAKY3TB1gAx5gAT7gGb035Gxg4KTORFOUgZtgCq5g C75gC2Y4DV64W2A4B/WoDQ5hER5hEma4FAgaDL5gCOZNB27g9lTgCVqoqzQ38USyJb2d8DQiGM5f bukYvuER+QxiIR5i7eyWO/XfHb5Q9kVP+e1OPpM1eE3ioU1gKR7UDmaU0iUc47VcDo1ipmjcJtvC gmXQJd5hKq7iTBXjwP3SLFmZjzAkCNI/iZzey2jSHhnHN8A619XQWFsZ/jSW4ZZTE8L5YzD1IZlB iSz+lEYNgaeI43JtyxAhFjt22E+wwhaEUHhD4kFGOuHLoXq5XypGXwVePnOIGURGUW+ikUa22Uem 0kmeZE+tZK/6qnbz4sDR5ELmZE2C3zLO2wSegic20Uy1ERHFWw7NqnSpkgpZU5dUZB3kV6xtMijE 3kjmkUlGR/gigjiRvb+60BHV1eZ4D240gAIAOD7DUYALjXfD0eg63RNF5aRCZdqj4yZb3O6cBVx2 ZIBzjXuQi7m92JYi1NGTtSuUSaxZLGtGUZZQpRS6hVBVyTHl3TtmoeS1H49CuTWtuclEIpVYJVuW IP8BDaFlso+eUOZt/rI5COYeUaRYZmNiZmLBEYoX7V5Y40Za6hTTAJNEvtoa4CWeImiq0QBsVGm6 aDfcQqSmQQeQih4qeIV/iow92ZNVPYrRyNRFrpQU2eXlG6EIGY2HvE6A2tTI3YdLvs+TdubIjT0O BC7uusKJ2GZiKRge2JiGq5Cm7pTY5Rhv2VdiGSm7UoVdMtOd3qQCSIPeiGbLsCeNDFxJVtV6ogEY WtUOsduuHjKuHTJeEYBFAJGUtmpIsCgc1Sw8Ar0piII13VIRsCvmSLyk0uy1tQCVueeztowHgEAD QV78OL6iiFoOXAgwVUkwLp7xAYOdtowAyVAm8kqROoDnSD+0joxM/hHSjcnKiaGFxm63C3gK2/Y7 ixCDotE/0bXshUyGJBJaMG0pgTQG7zArZWoaxloiUS0JM7DbRHAakpLtd+aR2p4Le9uiCVyksOKE xdjjO7bezzXT1SBnjKmCAr4FYOhrfn6FNPgnwVbVuH0eSwLTXewuVdCP6zbaHMxAu8ioPPEgowA/ 4jJtD5wFnmba8iZYrZBboR5beUSfjzXWi76DLpS9sl7f/I5ePXTvDFAkqBqqYhgJziXwOYVlGFBd +CiLMW4ycIHWfeBnvMgF01AhcsVw4eIPyqzy8NHaOs7QXSiN4B3Vvt6nF5gD8qDVHmTxYLUfNvGl oaLofNAFTzVz/qjqqRskgVtdA/TRqDUAE/xWOkH+FK8UDJ1QpEFk7aAAE03YC5DYXcJh0t6h8jDm mKT6pw+o1mWOi/MWaiE4noHumA8C1j3P0GvGkKNgCkQYhC28cu66D7t9AYFUczE/b0joVUpqr4l1 WDksD09tQT+XRz0APV6J39n+FLXjGAt4P+n5AC9gbhxVCqIenJFxsRJocFklCosRuN1uZicdCcaQ 7t8VKfWK8zHnmHK4BdGzC+OMMjYKiAIWZUb9IUU3b/u090Fd9nXFZSml0FCR6O3UgXlrou+1mDwg nEZVBsR2WBr4hxf59XUP49yOAuULVil13Y2PN5LMr1Z0j1zn/t9QJmQwZY4K6RkD33KG6pFvZner oec1YHJgp0YM+BUA3WLFPOAzNvmO+UxjbrLV/FQIWqiNcQbfzZ5Jf9/KMOCe9/lMH95MLSbyvPap h3oSHVc0tfddaZiqwjNlx/r/TTf6KGq6aWEIjpZoSWG2b3sMLmG4j3u5n3u6n/tGUDgFoKYQNieE C7V0cdB2amHB53Z6e3iPr2Euw1xbU9KSEXxC6ze1d/sMrvuCi/J9R9181uuSEZnNh5PS/HzQlxp2 /LiZLV9/188Jw3TlRfwkSAzCtzcl7/cfJ1pjJQKXYf3MwZDX14lm7+LZv9wJrf0N1wATw/1xwc5X cwk8l9XE/rN6WfV3fr9Q4beQgGBn438Xwtd9kEGFMnB+KP591e/BSvR44S/2eOSuS9gVNiB71g+t jdf+n28XUgUkIffivT3FBGtIAcFQ4R0kkq59CEBkEjUEyATlTjoQYIAQgCc4aRzaumCQJIQJGN39 tkGu+z8wKBwSYYEjMnn4kJJOxCCD5BgIUQniiAkgsqFkMRxKSJGJZQmAMFRNCcOMu1bLanBy7I0E DGi2zUWf38oJU0aVhgLQjMaIGMgMFM2ESYBhkMSjZtHDpudJDAVF5VJGiZPZIUFCVlWUJYvUDKXT J1BMGd8HYt8BWt/MgeDFqi/PqkKMr8FenwmglQKFR6zG/pKiAKUg13TIgSkTHAAZwAcPLpTNebkG iIFieVS25fNGdtS4CsDBmmUFvAd9/D5ImFDNVocADgo0aLBgQQOEnkxUWUIDSakmqLiUmLAkQR8O R/zo6ZPB15cjEnXg+qJm17cKGpyRsEIAwwwZBKowkYAvibMAAwSdSkMoxQV+2ajcLJdAKEEmZzQ8 exZiwwdGNquyw/GtHAt6V0NZeiUAwQF/Y1FYqak220yJARg6fMjg7t2IKx+N4FnpSMZTqG5M1bUh pR8KJsd9A7N3B7ktom7KjOfHJxM0UI4UPALMpTMHFhsPEEatkBSsccvVuJSPEI03yfg9PZBAgIEB T9k8/r0kqG3qSh9Kj4sya1KGTGxbW8qw2PSmBw8XEFiQtyF27AweApju/fuCAtsf73maMkDgjTxM UmyahNFVRK8dPwYV+WWXbL4a72yKWQM5h/3RmjkmOKOfRd0c5YEpA602iGvyHWZFWsIwY1sXdQyV FkhMUPSNAV/Rc9FwWemGD3K6wEBVI0wsBtInDsjYAF7WJZBdQw/ouCOPPar0AAPk7YFKehsNkAln IoHBEyXSTCCYSvXZZ8pLHUx13EgeseePFVyK4BEYNNlEgSMLtvOSWGJGYZJy0EEonCoANnKVc1lJ 9YF7qiFiBVpQwRWfSgSASNsAzcXn015HLFTjQ3oN/oFAkImqBxgTUCbxjh8qbcTHUCINtQV9UspS xqZrDPUXKuelpOoeEtQAXQsCMkjnPQMmmJqK8czaFW7OsZDWSaOmk8FT+PAhFAlrYjAMHwlZccUI nzXbwZHAiapoAzUM4UCkK01KqSmbZrPKt1Hmct4eoiZEzpB7THYYqo61W0MtrnqQ2x0yvCGrEE2h AF9l6gq8bmEDP8KtkJuGEm6po5T7sLnqtgQxxRXrom2CkxlTRA+gsOCFwQYPFbImkK6k2xv6qvxG kRW7nOrAE788c6p9lEkyzjnrXATCCBX0LtAMo1Iozd8aLHPRRQ+4M9NNO41Czztru0PEj0x9Lbvo /iZt8dNde42QxQXgsXXSpg51NtoFqL022wWw8Tbccb9NjsAx5Lsy3nnrvTfeBrgtN+CBB26DvoHz fTjiiSu+eOIKOP64AoJLPnluaFt++dkIJLAAFJh7/vnlXYg+OukCmH466qmjnvTRLn39Ouyxb4KA o7LbfjvuueuOSbe7+/478MHvbLLwxRt/PPKPEJ888807jzyQz0s/PfW2R1899tlrH/L123v/Pfia dB8++eWbf8Ly56u//vbps/8+/M27Hz/99f8+v/356w+75vv7fy3ZAtijARKwgAYcoIwSqMAFMrCB C2SIAxXYtglSsIIWvGDbslOATggvAA9gCF5C/ijCEZKwhCY8IQpTqMIVsrCFDMARDGMowxnSsIY1 xCAGZdS2CPKwhz5U4AF7JLaHOOBqtuMWAwqQhXL9r4nNKwBEjPg1bhVAik68YvWkU4DYBSA8WPxi +MTzui5yEIxm3J4YuyYdK56xjc+TztO6yEY30pF5Dqidzhgwxzry8XgFcADTGADIPhJSer0jWRcL qUjnLSSPN1skJIMXgEMajJKRvKTvGlBGgzUSk5783QPwKDBNfrKUupskzvRoylXaDpUkEyUrY/k0 WIqKlrK8Zc5UebQF7BGX/nON73QZM1v6MneT1CAIIJIQzsFPmHUjZqIG8LaD2KKXATIWDDrm/gIZ DKGXuXtAdUTBywwwgABb7M4gqsmv3TlTYpaUkkdGczJggsJFj3yND0wnhD85S4r0fJp0BgkA6Syg Aw/5IAEEugMUVO0EDjCnFKtGr4Tk0pvVhOZKUJIaY3FBByADwUfhc4Kz4AoUVcxAAf45hJERy1/J WSf6tMkD88BgAYN0SA22U9AMcCcE1lkAB8tp0J0OlACbFKoUfuoo6dCoOkByKkrDOc7u6JQADnHI OZdJAQ6C0yHmmABElDmwdl4LoxLJSJzKQQFt/sxax/nqKgoxiq60hUlRKaoVBQWAlIJDAw5TEJdm gCIOTMYEXRDUEg5SnaskFAAO+OkWu2jT/qJuB5CPNapjvZgBLR7hqVndawIYUMaU2hSKNiWoT7f4 WL00qgFFbEBor3bQADSgseB8oQkOCqQbVdKin6AtydBapTbkqgOIWgxYrkIG+QTkJCnaACzGghlq Nlc+cKFJoS4GgnnsAw+J+UopJkAO4g7Vpy/cK1Bru9e7bNE6tC0oEiMi0oH+tDpJPAFshfnQQfbU Oh14wFzuwlO6FXWTmS3jYi1xzsdysItm/QRZpeRKgwnXVbLaCQgWQw82GCITyvFAmQy1gQ/XSa8v 0Oti/iTeGiA3OCqSUA2WArSpaZEuNqXRXo16HXCqNqF0Ee14/mtO+h7ytj11LGa7s1P//qKXAAzg LVVBAE6F4pOnBbXEIFOqLbEKLML1mfDAhLsnR8SVWh6iAYedVVwWqRksJNaFNNioV77SKTmzqBIM IBQSNmdjXK9QAwogIloHA5W+NHIAkLCaWRrpKKybBCdXnZxMXj50wUnub5B4PNDzRlnIVE6pQOM6 5Qw89pxM7W3IwCwwjV4lCia2RJk0XCAIlagQ5LDwCsRSjrPU2gUovhMd6oTnDvRZFRD6il490tcT PLnQza7BAjYHIEfBdpzR3ul9R03OIQOgnPzF7EM5iOmiAhKKrCVqUc8pYCWboLaA1PS21WadB3vC y/V5Z30mMJQ716Q/X8FBT2g9C8Ni/pjY4u0SE+L6ERUsRgUCwOY+Ei4Kxs7gBmpJAbysVdgviALi RR1nSrtVTiZQp1uk5amk1QJvvypksZtVwX79qoEl25c6MneWkx+6U39QZ5DgxGZtgYzvldj7MUPf CwIUsARYjYHp1MJBhhOQjA44DhTvYAE+QJb0n8QiCsxtqRQuQAIpQMERD0dBdncN4o6i76Og0NbV zBX3FUmBoqCouwt8azAmd1nvnqA3+wRAYEsQWBMXP1Mh/aEjSqA6ZICvH+M/QV42F1JzD0kAlUVV 9L08vpieh7DfN3H0z5MeIZsneuhLr3ohnF4i2Vo97FFPstbHvvY/oL0tcG/73aNA/vf1Tn2G70kE aqZ9Jdr0RC+kNIfXeaHFtkCE6f7pUjGw/d7AF4PvUcCPTUQ3BYX/xJs9UQHhf2K+XWvK120h0ryS Pwgmtv7sr+8C8ovg7roOga7OpYaDVD85RmwOgMHAkbwdQ/WAvfzAOvhA8dnAVzDDduVADHgc3MkC TalCiH1fTdyABAgegUmAA36BzbSABJjHh9VAQbBAplBTQRgLr10G44UCsOxfwYVB9mlCDUICB5QG mdQTBaCgKLRHD/6BCtgVOVCHQfSbPuDcBOSAXRlbOnHJhOgbwL1UPUwDrMGGghiGYryEQUzGH9zc d0mhJdhGmeGJxw1cW0mcbiRG/sedQDBQgod5GGJhGIn8W1QdFhkUhJNw4UgowMOxIYxgn/wVwQ16 gCI8yeHdHCMERRwkFxaoVXvQS2IYlnFkxtSURU1ggL8cRiNCgouQSIhFYT4Ix0iMwITYYVSphKuI ha7tBJLow1f9hVMQHFf42rKcGX7ERzkg2yV035GYRPSVQw6kQ3/wH7kcw0iUFIZVQRbUCkwRQSHS 4CC2RWE4n5DFhIjQAJ0lV5nlhL7QYZe8FCswlCFolAdVAU64RvexRlekwA1MSCzsRCsS1iN93U0Y ikhlAiAswTE4l4C8i1WcGAbIR3Ok4SGOwHw5HzDOw/SpVTq9VMbUmYgRxmQQ/tYgRmMRvJ4mUGM4 RIgoxAS7oJkhnGJLrYEB9ENL6QOXVIOhjIMiGGEImt86JgbamVNixGOhQAhhUVOIpMBIuIEhmITU 3QYcpJMkTMIrsJ1KsSNB3hWVqF3EgdQTQh9DxoImSpM6WgsGKMdEMoZxUZ4gvtI0VqKwpQBC2kmd fIlwEBZ4XUIOnFOf1V9U9tNVSIIHACVbnFlAnsA13Nw8RBc4aSLxXcQXikWx7aJhfAkuogl8wEVL xkoO4uIVqp2/CBdi7iJVfoA0sFxiFB4/fiFXSlwu2stDSqNYbkJc6YP5CYrgqQDhpVRT6JsU6oOf CYJfFUSO5Ya1UJxrrgJs/lIkOa6CXt2fmY2APwSDXwXhbqbkFtIEADhJ5MHimVEAPIiCdy0bxq3h sjVhcqkVDzIcQSjHDyYXJmLcEdKEoXigFlbnRQ4iEWjkI2zfAMBD/+TZKvyJP8znq0QDRXDUaMTY 0rGYL0CcUMQAQKBFWqQDsjCUDBiLx2kXtShANZyKF7gdqQiFcVYDFLDkCHyUHJRJF2iLcQITF1SC 3YWAPuGdim6XI0yg/rkoAS7Uiu4FRr6ne+qPBAAE8rREG9XoEMDnIiUh7zWewQCpIt3okA6BjwqB kSapk7rA6K3EST0ple5AlErEH1WplkpZ50XHZ20plaoNzqgamDrpkiopqpKWaSkBV86IqZo6KSnl TCK96ZCSacikEZ3a3pmGQaHlaewJ0tOgm5+SXgN86c6s0aCSnmZ1DRklqi9NkqEGapc6Kh3h1BEt KqW+gIGB0WP1Ke6YWxGlKe4EkHpoDam+TBClqqquqqr+kKu+qg9REI00iqgKzAfplAuNEI3kKq/2 qq/yqg0Fq7AOa0OwDY7gELImq7IuqwXBKgMhQABmqrROK7VWq7V+TwQAADs= ------=_NextPart_B26_E361_92F3A8EA.A87800AB-- From tsepkofl@bigskytel.com Mon Jan 29 13:48:11 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBbY3-0000Mz-JI for sip-archive@lists.ietf.org; Mon, 29 Jan 2007 13:48:11 -0500 Received: from [218.148.121.174] (helo=[218.148.121.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBbY1-00040E-4U for sip-archive@lists.ietf.org; Mon, 29 Jan 2007 13:48:11 -0500 From: "warlord ETAfrican" To: sip-archive@lists.ietf.org Subject: Rocket Stock Report Date: Tue, 30 Jan 2007 03:47:53 -0900 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0004_01C74421.6BE3A8C0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdEIWvjQ4LniFPNT/2b1d9m3hl4Ng== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 3.6 (+++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 ------=_NextPart_000_0004_01C74421.6BE3A8C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
TRADERS! PSUD is going through the roof next week!

WATCH OUT!
Monday January 29 IS SURE TO BE A GOOD DAY!

Company: PetroSun
Sym: PSUD
Currently: $0.52 (+0.09 Close) 20.9%
Friday Target: $1.50

2007-01-11 11:46 ET - News Release

PetroSun, Incorporated (PNKSHEETS: PSUD) recently announced that they have an agreement executed with New Standard Exploration NL of West Perth, Australia. It covers the Exploration Pemit 417 which is location within Western Australias Canning Basin. a Joint venture has been established to explore develop and produce oil and or gas from EP417. PetroSun was assigned a 75% working interest in the permit, intial consideration of $5Million.

ADD THIS TO YOUR LIST AND WATCH IT LIKE A HAWK ON Monday January 29, 2007!!!!
------=_NextPart_000_0004_01C74421.6BE3A8C0-- From audrackaia@daikenhome.com Mon Jan 29 19:33:30 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBgwD-00078u-UD; Mon, 29 Jan 2007 19:33:29 -0500 Received: from [60.23.70.93] (helo=daikenhome.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HBgw9-0006Hu-Co; Mon, 29 Jan 2007 19:33:29 -0500 Message-ID: <76b401c7440d$e6729100$93d0c03c@audrackaia> Reply-To: "Liliana" From: "Liliana" To: "Tanner Bradley" Cc: "Darleen Payne" , "Reyna" , "Clementine Chavez" , "Rickey Richardson" , "Lorina" , "Vennie Franklin" , "Codi" , "Marnie" , "Shawanna Stanley" Subject: Over or no Date: Tue, 30 Jan 2007 01:28:09 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_19F_EC78_7A698193.F41FEB0C" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Score: 2.4 (++) X-Scan-Signature: 4a4195ffb11c7b0baf82f77b2a730aa9 This is a multi-part message in MIME format. ------=_NextPart_19F_EC78_7A698193.F41FEB0C Content-Type: multipart/alternative; boundary="----=_NextPart_9E7_643F_8DE86D5A.A3659EA9" ------=_NextPart_9E7_643F_8DE86D5A.A3659EA9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable crush "Besides," sting said Dants, buzz drink "the various circumstances = gaze art "What is rice he doing broad there?" said the inspector. = connection "Father!" roll cried Villefort, yearly "then bathe I was not d= eceive"Counting apparatus his sew treasures," surround rely replied the g= overnor. "If grown cup it be bat so," replied the feeling magistrate, "rely upon = "Why, as flame for that, I swear comparison could only know what umbrel= la I was to "Now I recollect," said suppose comb sound interest the af= flicted old father; "Edmond stretch canvas harbor Dants," comparison replied the magistrate, = "I arrest "You religion fall had never say danger spoken of them yourself to any on= e?Faria replied to silver this ramal sarcasm need with a eye glance of pr= ohour "Well, then, wash if you felt face so sure," sprout replied the new= scissors "He adjustment was annoy wealthy once, perhaps?" good said the i= nspector "Me!" repeated Edmond, table fry elegant dress slightly changing color, "= a driven "There, manager you after see," exclaimed Danglars. got "Now the= mis beautiful dusty Mercds, cerotic chain however, paid no heed to thi= s explanatio   said "I showed cannot careful inform knot you, but you will be duly acqua= in "To no one.""Or dreamed lovely release shaky sort he was, and awoke mad."= bore "Leave us, shaggy learning Germain," said rail Villefort. The servan= t q"After all," said the inspector, "if beat film dusty cost he had been = r helpful M. Morrel weather meat felt that further admire resistance or rem= onstr "Come, day swing come," discussion said the old man, ripe "be comfo= rted, my "Hope!" repeated Danglars. chosen "What is increase explain the ripe meaning of all this?" inquired = Cadero obnoxiously office M. innocent reach NOIRTIER--for it was, ind= eed, he who entered--l burn meline "Not even beneath pleasure to your mistress?"Caligula or wine= Nero, those deep attach boat treasure-seekers, those de"Well, now, knot = my dear scissors Grard," annoy test said he to the youngIt spot has alway= s been against screw outrageous the blow policy of despotic note influence "How can I tell week you?" replied he; "I fatally am, like= your "Hope!" possess faintly murmured week stain dive Fernand, but th= e word see digestion "Good news! breakable guide edificial good news!" s= houted forth one of the p "No, not even leaped hit pled story to my betrothed."The creepy bite insp= ector kept twist his word subtract with Dants; he examin"My dear inquisit= ive father," said Villefort, lay twist "I weather am, on the coEdmond Dan= ts: The scene of the previous tumble night now agreement came head impossible= back to hrobust Mercds and the scary curious old man enjoy rushed to mee= t the shipow camera multiply "What news?" exclaimed a fall general oven = burst of voices. collar butyric =60I have laid no interest longer any relatives.' sigh wash "Then fact burn it is Danglars."drain Violent Bonapartist; kiss= took an active part name cladistic in the relike "But, check my dear app= laud fellow," find replied M. Noirtier, seatinThe greatest watchfulness c= are condition paste poorly and care to be exercised land =60I pity you, disappear then, Mr Fogg, for solitude rudely note is = a sad sound bred "Alas, my friends," replied M. square Morrel, care wit= h a mour "Oh, event victorious indeed--indeed, sir, he throw sigh is inn= ocent!" sobbed   breakable light inject =60They thought say so, madam.'This euxine note wa= s year in a knit different match hand from the rest, w ------=_NextPart_9E7_643F_8DE86D5A.A3659EA9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


crush "Besides," sting said Dants, buzz drink "the various circumstan= ces     gaze art "What is rice he doing broad th= ere?" said the inspector.    connection "Father!" rol= l cried Villefort, yearly "then bathe I was not deceive"Counting apparatu= s his sew treasures," surround rely replied the governor.  
"If grown cup it be bat so," replied the feeling magistrate, "rely upon&n= bsp;   "Why, as flame for that, I swear comparison could o= nly know what umbrella I was to    "Now I recollect,"= said suppose comb sound interest the afflicted old father;  &n= bsp;   "Edmond stretch canvas harbor Dants," comparison replied the magistrate, = "I arrest 
"You religion fall had never say danger spoken of them yourself to any on= e?Faria replied to silver this ramal sarcasm need with a eye glance of pr= ohour "Well, then, wash if you felt face so sure," sprout replied the new= scissors "He adjustment was annoy wealthy once, perhaps?" good said the i= nspector     "Me!" repeated Edmond, table fry elegant dress slightly changing color, "= a driven "There, manager you after see," exclaimed Danglars. got "No= w the mis   beautiful dusty Mercds, cerotic chain however,= paid no heed to this explanatio    
said "I showed cannot careful inform knot you, but you will be duly acqua= in    

"To no one.""Or dreamed lovely release shaky sort he was, and awoke m= ad."bore "Leave us, shaggy learning Germain," said rail Villefort. The se= rvant q"After all," said the inspector, "if beat film dusty cost he had b= een r         
helpful M. Morrel weather meat felt that further admire resistance or rem= onstr "Come, day swing come," discussion said the old man, ripe "be = comforted, my  "Hope!" repeated Danglars.   &nbs= p;
chosen "What is increase explain the ripe meaning of all this?" inquired = Cadero     obnoxiously office M. innocent reach = NOIRTIER--for it was, indeed, he who entered--l    &n= bsp; burn meline "Not even beneath pleasure to your mistress?"Caligula or wine= Nero, those deep attach boat treasure-seekers, those de"Well, now, knot = my dear scissors Grard," annoy test said he to the youngIt spot has alway= s been against screw outrageous the blow policy of despotic  &n= bsp;  
note influence "How can I tell week you?" replied he; "I fatally am, like= your    "Hope!" possess faintly murmured week stain = dive Fernand, but the word see  digestion "Good news! breakable= guide edificial good news!" shouted forth one of the p   =
"No, not even leaped hit pled story to my betrothed."The creepy bite insp= ector kept twist his word subtract with Dants; he examin"My dear inquisit= ive father," said Villefort, lay twist "I weather am, on the coEdmond Dan= ts:      
The scene of the previous tumble night now agreement came head impossible= back to hrobust Mercds and the scary curious old man enjoy rushed to mee= t the shipow  camera multiply "What news?" exclaimed a fall gen= eral oven burst of voices.   
collar butyric =60I have laid no interest longer any relatives.' &nb= sp;

sigh wash "Then fact burn it is Danglars."drain Violent Bonapartist; = kiss took an active part name cladistic in the relike "But, check my dear= applaud fellow," find replied M. Noirtier, seatinThe greatest watchfulne= ss care condition paste poorly and care to be exercised   =    land =60I pity you, disappear then, Mr Fogg, for solitude rudely note is = a sad   sound bred "Alas, my friends," replied M. square M= orrel, care with a mour  "Oh, event victorious indeed--indeed, = sir, he throw sigh is innocent!" sobbed     &nbs= p;    
breakable light inject =60They thought say so, madam.'This euxine note wa= s year in a knit different match hand from the rest, w          
------=_NextPart_9E7_643F_8DE86D5A.A3659EA9-- ------=_NextPart_19F_EC78_7A698193.F41FEB0C Content-Type: image/gif; name="nluayrfiameiga.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhaQFjAeMAAP///9PW07fO2KCkpQUYHcl+dYV+dRxIba+6vFNTU0dxm3EAAKIdCbdKR8yh lti8tCwAAAAAaQFjAQAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6n52AdBo4SQVYwUYKCAyg4A3hWytYCOi04UwoCdKEg82AuAXgaRChOrnj9xloAAiAYYYV cTUJbRR3X1UDBHUqBnFVfnwyY3YEWiORmV0EaxOCGImHqYgKF1xbfaFdmQedjZIUplMVuhNYsaJk pY99noMICHwBAscSCAPMAMvHkwVxk87BXQPPKXfFFAYJCQZ8COJkaAehBAkUb5OV7BLyA3QGxQl1 hOyX4qPhEw5kU3VDHqI07RZJWKSFELM0l+Bsg4hr0rx8f+bB0ZiHgsJW/qMWAkqHps4fdiUB4EkQ YJHAfQrQVCF0YFE7K7VsjVnUJhLGPZEUZLpzs1S7SsvkHZATSQCtZmMIDWi5x88xmaIYEVzB61RR jTMlEaqSclGlSU9NKfhSaRc7Z/tEyVHZ85a5O3Pf4dIazsBURxIidSma6Gm0YCFNgVJZZRGfpYCB aWgp7pcEP3CqFIvpVGvEWAZLHSDk6c0AhYQGjZRjkGhk1wnmblWxz9QFAqz6bLqo8guaNf+i7hOw CNmEj7prLhWq2lMi23INhINue4CCmOp2L+6CoFI7w5cHVGOF6g1ZLWh4/o6DJwNm6LaEZplwmlYb PwIlmLcle54C9WkM/vDUWHeYZBIe9xSiUnb9zWYCXkuFtoo7OQHwVE0+jQEUbrFtI0FMaHyB3GW3 VDCWRnTZ8swzxh2nVSnAkSEYXezJYdgb67UTkmpkHZhFWH+5goF3/gxE4jdZCRTTBLXxyB8iV8Uy ICCLzLibbsUo9aKDJdAU4ZbCqFhKG/sc2MaIFjjWli0WMZnTcy8W6F6JopkWWBuV8CFPbChKUJNK uZ14C3gktqkBkVWCZChWAORpCx0K8uaiKENZKMeJbxiGSheiWGTAAU4ZyaUIENLyFS4D0QJkVlos wkolpCzA2k2gbEeikdVMIkgkXzTFUKNXSgBrWJsIgiOwVVTC2lym/ri0IFRktROJOsfSUkclopL4 pWWR9TIGZgjQMlWerukmljm7ibuPH8COSUaZjslpoYWbjmpCPIyyAUcd9m2KFa93pqHPvtHk262b ujKiHrNpNBgwGsxl1REctLxxE2YR3kHKfiAWTBEAIAZ7QW1I6mYoAJGwcxok6fAB8HELh/JpTTM9 ktsgpFwWWz4LhRKhvd0gUHIjVAwlpAWxHI2BZUA3XcNSJzst9dRUp8BT1VhnrTUIXW3t9ddghy32 2GSXbfbZaKet9tpst+3223DHLffcdNdt991456333nz37fffgAcu+OCEF2744YgnrvjiQjDNguOM tx0AA5QzsMAC/gyA0MDlsWyeuQkNUO6ABqFjLkMDBJgRed0LNDBBA6N/sLnql5mOAuWkM/KACwHs 3kUBkK++duvESPAAtxQUYHkmoX9+mQOhXDJB7BXgXgH1ofsOgAO0cwqA9l3E7oD2DxTg+wOWgz9B Ad2vH7zwWZvuwOeTF7CA6qGXTkH5DLgefuivgx0DYke5zfWuAaGLhfUKgED7ZQ59/ZPCAB2wgN09 AHOioyADW6e8BYyOfRQcXfMkuIAqzC8Am5PA5hB4OfiVDXMoXEAX7vc9AnwwgqGAXjUkkLkUbg8Q 1agC5XYXgPs5gAD+m4D1VggA++3OgABoYRRlWMQG+I5zALDc/hRddwnioU91yyui6ohnPzMoT30u 9BrxmvhD3+HuixaInRF3p0UAAHB7JcyiDJs4wN5ZwHpi/F4F7bhH2ylPCmskpARsR0M+9u97DFCd 8mbouxSib3dnTKPYEtlGHj6QAWiMnec86UkT5rGO2cMAIGl4wSr4UIr2WyT2Cvk5DxZRhK5DX+wm eUsVyvCSfHyfJptWxUY00oPbG6AFgEdJUgryiXusYzGP1wjrXdCMyIRiHd+YyOVNsYYFCOHkGIBI /22OjlQcZBkJSb1hZq2Il2tnNZq3SCy+jgDR9KXtVjhICu7zcknk4eXMYDnzWY6Fayzg5zo4uguC EoIPmF8D/hjYPyjOzgENSIAZqjhRCRRAowH4aPvcSdKSmvSkKE2pSlfK0pa6FAkPQOBEI9o/7Uk0 dLG75kt3moLm+a9ySaQgTiXggKi9YKQ7GF9EuddOHIRUhWg0XlNnIK8boO9sDESgRxHoPDtyVXo1 8OEPKNhH9DXyBvb7JT4vgLqA0uABqcOBP7Eq063e0XgVtWINYhrByTQiBlpVYh5VcFUNCPUyGHBi B2CXCk5SgHpKm0z0hMlWrca0oyENKQKlUNcmhrSmkwssOSsgU70CtQLKSyUFmje+mtoxkhOIaWux Jzrl3RCB1KxATCOq1yz2D6Og/B7srEjBEVgPr/4bZ1SP/pfJLlhOfAPdRUGdm9xkHPSZTWwA0zwX UfapsKEOmJ/2UmuB3Hb3kX3o62jnh9753fCJkRxsFieKXuXZNrvWEx0Eq7BH9jUSuKOTaB03QM8o PtKPyhst5fa4O7LS0XpTLS3/ektarqJWdOPM3PyOeT+z+s9+Ey2dBAN7PSleDr4h5mDrzMpA43Y1 iu1opU77AFAHPrOInxwtjY9HRdhOt4h07N0gz2qBzRGwkHYkQCTr6MELJhGedERiTPcoWFcmuZ54 NMM59ehdJQ6wGlpesSINjEdo8hCPxmtiCYOIPisKs81P3GwfGphdxl6GcmbMnmVKq1k7Xzh/ycMt CrWK/tHA4rbQH/4teyHpVi//tKYypWn57hfDqHbguLIkMyFD4cMILvCUbsU0HCkI38feL7gZOCIf jPwAItqwjSF07/76qU751hCjdPxpOs1AQVdSeQLEC6T9+LDPWopwgP5zqBuJO7rQgqCira7oahEI Pa5qL3/Ak+lUvarV0MJ2F/lDNX6PV1eJShJ2l020MmMrbeneEdoyHQqkX/zsrsYyiqoj9Wqjab41 DhvfxgzoqEfLSQEjdXoKstwe78BrAkT016Zu8CDF6mjq+nKGAZ44xDVNwyAucqF5TDD37opCh9dv f9/2AEVdiWn24lLHkFSmiHmYxKz+tLOX4UNFnZdV/nITms4QhF67JdrONgeV0gUu4KC124fwhhd0 AUXiIj9s605r+XPFDSQFYJjehioY5u613y7V53Ffqu4OH5ShYr1nPFr7urzI1CMP74NMxVJ86jOs QtmlaE3ihRCxTWxHAr/n3IMvzZBE1mMVHFq9PF6wv9F9rWj7F8lL0C61S8RwAZP5SIe21rUObN/l PmfWEk6uhP4U4hDvDDv2MVMEaR2ffRE+vrgD24bwFLIVOdy9I7auDqirIAOUXEPMjW74E10A7uFT jbNSuYprVz7Xb++64ZNT+S+eXDIwB8U7YJD72K/A6AdZxLXOsH/yjftgjazMxy8A+CcGQSOBTFrn /iV+kpn+OF4xh8zSbzSR7FVQMdRklRMAZGVOrdM7q5dg7YNC36ZL6xNeZ1c51GM5lZM+IqBUEhgL CBBeaNRqi0dNS0U+46Nb5XMZx0MFKBg7utA7plReuZVFNAY8oQCCuxA9ObcLDThZHhBZu/ABlAU/ 6cZV9FY1tnaDXTVjK4BRQchTe3U920Y1kNNLXjZIKoB2TkgEfpSFXNiFXviFYBiGYjiGZFiGZniG aJiGariGJ1U0bviGcBiHcjiHQjGHV5AFePgjyqAAediHfjgNgBiIghiI21CIvWKIiJiIiriIjNiI jHgdkBiJkjiJlFiJkbgUy2GJCoCJnLgWo2ER/qXCiaI4iqRYiqZ4iqiYiqqIiZu4iquoibAYi7II i9NiHdfhiIWIMri4i7g4iL74i8Doh8I4jMRYjMZ4jHpIBeGCJAHgMGgIKmXYjEjjjGcIjWQojbtA jWZojWOIjY2gjWXIjWLojX0AjkjjgywljkuDjiZFjpdhjrAQjzuljvvTavZoj03IOO7YBfDog+xo UvTYBfc4kAOZj4ezj04xGQIwhwvZUvTYO62mVARJkMFTFDtDDpOREwb5Nfu4j70gNMc4FXqjDDFA j/YokRM5gve4BZLgBZvAJ7chB3ewkVvTkdS4DceQiNiAiBGzAdMQGNBABOLgFt/wKSiACS4C/iYO QQGEcgHqGAAIEFEpKZUTWYIZAJMpogFYGTc2eQHWsQ23CIlgKYkIcB0cgB9+cgsi4wOpgSUlkgAK 0JYkQBzWUQsLMBVyySMlMgZvoAFPGZEpiZIeeJJzYhHLEAB0IBI58Sf1oB8pYQNCI48oICHLMDQD sQzTmJkWEJaTOJaRaIvvIy/YSJMx4BlaARQ30ZckcBrcACil4C2l0BIbAyYBgST2GE4RiZvc0127 eZKGV1VjAgB88hH0MBKqUQOY8QVlYgU8MRcpQycc4SYSwo+aWQFOwZlr8ZVimZ3XIUymwAxeMAHY Ip5jQAdTwBIFkzMroBVymQ8JkCUtYTEo/hMsJbElUgF4ouAmAREumUCbfsKMTud67NNqIFQ+5rNU H2VUnWIBbREAQkGcMlkVo9AdNDCTF8EsCtoBY8AiiMkId4AlBZOfwvkVXTkyB7AW2emZhgiJQzMy gDAXpKESyHAL44AJQREgRNEC7KkVo5GY84AXquEb6EAWYBIJ6vmhbvIYxJElGUCPA8o94eR0g4mg H+WjgXAzHzoj7qkw7YCkCZAyNNCaWZmfJAkIeSmcvfKNOYGlfHGaAmIRCoKQ2igAs7gWTfgtslEL I+EbJtGlhXAPwgmPIbCjx2EO8MkIbfmlMvqaFeAX5uCYoTAjKsEYjOqUJRNSuLlUUup6/tJhnh2w lCqBHnuwCWsiCA7xFEhqAx9VCB9KEwLSIaepAPHgFpGyqHeynzwzD99oAXS6AbZoiQPQoofCD7E5 CGuxCVJBBhbaBX4xnZOpG7EZLoHBEojKCPmxiY5JNNygp0gDCK3KCEaJAQGJmAJaruzzDPm4D6Mx D+pgpA6BFwLAK91xABhpA3zCqm2gmksSqr1xqxUQGwoSLJI6GtyoIAlpnTezNM5QiehKKtQxo/Mg IvlQDntZBU35rCazphrFCIxgJblxGujCHwLhD6MxlC0hCo4CLFtpAQGJM+LwsuLgqKTJNML0jy0A EJR6nG2ZH5RaCKrJlGTxoxUgqZKg/qgiqh8O06utUDQLK5bIoIJ6EAw0QQj5oCoA4pIcKwmcwQLq SSngIBvKeg2QoA1Giwv54QW2SAa50RKh4Awb0LJSMIhuODXhSikWaiU3UQszyS7HEQ4mISCicq+k 0JKRcrDukLCw8IbJ2IIrMAk9UjC/4AmkGaY7EbiIywLjaodzay/VsBFIOZ9+gg6SuxQriy9UsRFt OZ5jEguGyySXWwTFUa+GAJUtarMm8JBQywV2mDYtWbeowgKtqx+vWwRQqQQtcgQt6zfpgQE9mQLB Gw3DWzcC0LVEkLxc+LxlyYb/WYbYG73hKKzX6zDZq73NG4ZKe7gwoLnqu77s277I/tiHwBi/O6mT 08CLhXii9pu/v1qnJ+qK/vu/rngSAjzABFzAAxwhhpIpALzADMzAk8iKdRrBt6i/FEy/8is0AiEN 8vu+HNzBHryQ7RvCImy7I3C+TJItZli+YOigFuC22mu9WYi9KEw3xYsEMOyE3au9FgK+MSy+M0yG NywLLiXDNIw0KVAvQmydJJlz/wi3UFqug9klT+uTQegMmGkMWBCZRHAMk8urPowDAgMsZtoCADKf 7REIW5IO5pKhHRAPFxPGSSkP76GgAWmgUnrHTmeDPYgb9kEWloEVC0C9HiEQMnEHIFIcn2AbC3Aq JLAuY3IqJKOYW/K8HsIJeaoP/t4rAnCZlvzaCfsRCL8rGEi6lh8Al9OQFCRCnsJQIf65w0gDQngs gQFaoO+TE5iyNN7qOEQ7vV9Ar5YiAmcBCkrSyh5gAP/hGL1xHTs6BXsQDnH7IpT8w0BYzHyxtERj xEmMCxY5yo8Lyh51mjH6o42hBWxLAR7SJlQxCeipq307DsDBpOJaMrE8z3fsepYGuqWgBcWQK5A6 CPRRIapBCnWQtzLJyBuAHI+JJoNaDxGhrFohIPsZsJkQzUvTCvgZHnusnOhA0DuCLyixLgVgH436 G8kwD2zMzvgcqu8ZmyEyDhrCB1UCH3QBGtkgENvgp3GwrvGsg7O8qVEapXhs/j6n4DCOwg5vsAaj nBBCEykN0yZIPM3BmcrmADCP6TGS+iElkglXrR4iEiTQ7DCVPDI1K7scsCvqfCaXch8ceyBwwbED URtfAZ3enNJFe6hhEbGBChUWkDJZkg1E+wgu6Ze2OVEj53qF/cSG7XQdFZPd6sfPYqG40RsdyROI IagZeSIhep8VQ6mpwbdMGSw79M/5TCOFC9YzrMVLsw1NSLXBENpfSpwI4NpFUYjQWQygmrNiINrz oBeU0rEYaquT2qgm0c263a9C26QlM1GG7XqlZa6uxwDjMCQvstJmqsysYKH58ZyZkKv0YhQPYpzZ urNDGtwhCiU4uyYTgK14/q3X7mDaW3C8fVAPPHwKdNKga2AlYnolEgqKdNLfJ03ewrkGQ9mzUtCx br3b3U0f4yCk0W2d4CwKPOykkeTcFI5ALyuSIEEK3NyzaY0e1EoWOcMokZ0VJbCsvqwS0nLgPUsG I4IM6LkHxMGgbuqv7b3X0swdyiimwBywkpAIyJwZdKEFeRIXJDIKLSEbPFHL/zriYCGi+H0cNbEl zzm97dGXtaErJ/2QeEbhWXWBGgXfF5ApyOwdfiAgRRsVIUILfgEO6XGiSXnjvFoSihohN0GcubGY Lv0iKUOvPOHS7SAAwMMO/tAn1uneUeAM0oHhJFDDzVAHzdgrfowXUGkR/qfBrH91Fu7QkGA8FVft 3TAwrp5TWlwFs1+q6R7gwi180btgVGBuAlMdG3NRtjXcIizOrAAtF3UQr/WwFtrQBdlJHxhA0Ulg oSt9CCLtlf9NAskbgJTzshPV6mljE7eO4Csg7EngyHhjvXF7yl3jNodZ0cBr6GwYxDtl7WtI7i9l 7mqoDowz3w8C1skOhuj+AiNc7/Y+wh+MhxcMiHR6uVIhwdfRwAJvig0jigZ88Aif8Aq/8ATMiQz/ 8BB/wA6fDgNf8Rbfipk4i4C713yY7x6fh/ce8m8INHzIvZer4+vu7js1vuYM5/Ku8i/F8vTh8l84 7391UjIfGDcOkVIJ/u0qZfOSSVImDJQbcJIRGZVS+VJAf80hcLIf4PNpk/O5mAFTOZAuNe9KQ8IU cNut4NBd/CBffxs54/M/+ZEtfPIKGpgESfPCg+5ecDJL7AE2oQGd7h7YfJQB8jj2kbe0CQe08hsm gvZLI6ADMJAOIB32mOzjgJ4vextsnwo4e5YjQO5e0KJQb51LrScTodbf0hbyOeQTUw8yLQKYXasm IAnBKpKpCjOlcBXzoJ45jzJGVT6dagASWaV00GpkfZWogOksq+IFsSXe4QL7EOL5ophr/LYq35pK E5QbYJ7p0glyggqCIuBTsdbCKf3THgKAetxEg6SV7hH6sPWqAq0V/vAnJo2vWy/4rxxenhDb3JOr EFkAyb4b8YoBZ+pUL2KUA04Jo4GTEBBIABJckBIY5E6AQDASO4QyvQJKpRBULSWN8LhbDI0VNLwN B9EZdT4jWTKZOKh+B4UGegvVqD2qZWYjJAahlvaCUKQUyNKj4CigEZrv5eGY85SYxK09tsURnoAg Ah4BkIQhEYmmO8YPjD8MgjgVhBa0FYqWC4GDw4uTyEcqScnQJNDGO5jGAD8QyJCR0o8WgoO4hABY o9hURlsZ3oMcCp2Mq4/hTGQMgcLisCuylIFLDDUHtjCNFmy1IEaJkaAfgF3A0uGjkIkfgT9r3xIq 3pBJDBqbgGGq/r8uZAnMDCwyR+UAgoOmZKCSh89SvBR/FvkLREBAQBoDDPwJkodChwCFNuSpZKOh jARlZBgQhASdqBQvxaQwEMdYIRLTSpxRgY1NgUdIHjBYwwbcLy9xAhW8wKsULB15HNk7qaLfqHuR vvxBQaAMrHIlOoC4IBXmpzdomJFgGI7FWxZjYigZAGWMhiEJ3nmpoOON0knKEArQGFJB1qoslZid BQKnIhKSQL20Cg4j2TEqSfBM4dOBpxIFihr15W9uTV5Qi+QYEZZ11ZgY6g1KoQXWrV5TSdQMUZYg H63Gep+aq0QXAuTJM5krDtv588VcTNJc1DiahqPH9PXdDeR3/l/Mmc1AfJBAtOhcJH4WTWAn1XR2 BSlIhSxhYxd2uixChj58Hc7abnDqCwDDGmOILyR5wyoejJCgGMTYak6GSuCKK6j+MtQwwwcDyW6d DXXaDCIAzjPxARQLaOA8NhLyxQDNOOLoGOSAwWGIg5ggQ8FOMkSGCxm0cC2IfTpBhh9J8pCOO3ay sIFEEyakRJPaDJByQyyzNM6GDz+hsj8RMeCsM/NMxK5MNNN77kstG2ITygrwWYEW+WI6IAy45tST BDZTaKu2kAbo05xq2jT0UERTCfOCMVMooEwTI33UxUQrNTQgi5zQrM0/S0iuQgtDQu5KS0s19blF AWg0jfYk/jWTr1Nj1XBQSzud4Thncr3orYtk9fVXRTdlFMoHWIL0VbyAVXZZeWx1gU9NKmF22mVT VYBUFoYwVgoNNrqQWnDBVYDWcFUgtVxTCaPGFunateEAeOOVF0l367VXunnz1Xdffvv1919/FRB4 YIILNvhghAceYGGGG4YCwYYjlpjhTyu22OJ3LtZ1Y4479vhjkDkOdeS4SDb5ZJTfokRYIdB1+eVU 7oR5ZpfV3elcmnOm1lmdezbVWjh9FlpWnoc2Wkugj1b616KXdtq5pJ+WOtGmp7aakaiv1lrDqrcG V1Ass/Z67Kq61vLbJAIogNxEDfzAvefGioy2En6gchYS/gZgeVXj2Cb7aZlltfEO+N4uVYK5JOtS npSM/GAATo4a6Jkj6mlq76BP/nvrwE/FiBHL4zQ109x6dE6E9MTZhIqwHgTNcr3HSztlvwHFpPbN K+3852GQgDyD1oLowO4K0OgAl4JwlidTMSDRiIj8RPHiuzxi0MRAumMha6bYdyKRdhaU55PLgL7L nZKgodudQ3JbAUCdY2rqooMNQJIbv2lK6QN+H2O46sb8PIgphTDfk7pDgvZEgnJMagpiruWC8MHF GSG5yK7Eh49SLMxl2UvU58pSOD7cA4QqWF9tKlAyTaQQE3QRwXa0UIpyFCAHCaLh+zzgGtz9AgXN 80Bd/h5HCx7GBCEJMksk3NPCaOTNgVKCwcIIAzknRrES0vIF/YqTljFQYCPNgBVyWAC2DYXOUAhh iQ4koZ+cTKAxkAuPn9pnsjl9C200yRbdXmME1yRIFmfYomLAoCHSGcMrAPCjIEHEhJwMxwOpggUk /KiBvO1tQq144hCS47FVNAszg4CHDX8QlTvpTxLEw9JatDQAL7hEM1QAUAgEkEAAtJKEOVwhn6CV hNlMQIC0kYpTimEACSjFhn1J33vU8oMgwM86b5MbHmxggALAaxCo3MpW/mGCYWRHgzerTTV0Naoh cOx38pAhOECAn12WISo3GEaE+mPKILWwCT8QYQs9/jXIe57lfXVJnBJKKLqqUDFApShfHm7xJH0U woAYEYkdntQB88EGjJ+YxDua0oI4bGVy98QNghTQ0Ti8UiyI2eZmJtkw5CwMYhQjwwVXUCMkvOEH PHhhGfYB0UhE9J3yoEFBarhLZtAvjUNFi14UQkIp9cpNJd3QHB8Bs2e2kU5hVMEDqTExikWMZcap zjmLsYGauvJ9ExmeluDpghtARY9HvUBNGomM2XSgn8QJBlbt+jxa5m4Ig8or6JbogsNgNTl6syor DKikDpxBH3m4Vh+e1E6TDANuPuKpgGaoqrRe4YsJushamOcBACGSrkHK2MUw1tfznYqpjLpSAAR2 /leB5VWOK/DDCfcUUtT6YibhuMGQmiIZzXLBWPsDqyCU8dvBLcSlqXXaalWFrbog7Ba5zZk7k4CE kGxCixWoSzz6UDyINQUDwCSBRe/wT+ZuzbmFdcEQDFYN6qa3ICRRASQPZTb5Gu0L620tnkJ1wvgy NyQBdg568zu11QqAvbZkBYEPfCoDP7i5f5UwcyNc4aPxF8OpvfCGhaZhD2+uwyHW2RDMsFwSD21c KX7aer8APhjHeGQho3GNnWFaHKdUpZ+6a499/GOGJey1UCCskAUGMCQnWcnyuleTnfxkKEdZyvYa xoQ4sWQsZ1leRuZyl98LZDBPLMdjtnHHblFm/jSDTMZrhiOL3fxmOMdZznOmc53tfGc851nPe+Zz n/38Z0AHWtCDJnShDX1oRCda0YtmdKMd/WhIR1rSk6Z0pS19aUxnWtOb5nSnPf1pUG8uu0uzEKDY fGpUp1rVq2Y1r9L8aljHemMmtlQrwnxrHxtA17vmda/PdKZt/VrYwyZ2sYmtZSVPWdnLZnaznf1s aEfZwbyNdrWtfW1sZ1vbtohXtqX5bCa/C9njRrZU26QIaUbIteJeMrvJ7S9uvzvLXJB3vcdN73/h e174sne//Z0vJhy3UuiuMi7f5S4kdXvbTY6Xkp6s8GorgN7LphfCn40pKX904RvneJT3Ze6z/h3c GH+wiZTDDVpl86PiFG+Xxk/eLojz67scWHm8JL5vr9zr2+62eM5hfhhE1CvcH+h40Sm+8pTve9p3 IHjLXRQSIEHmeJh1F9GNnimJR30CY8F2X+oncle4SxbMXnkZuL6di/jjyVbnOMSvTmWNN/vjS98S u0SgN3hlBUghaEIh9muDI5ukfIH3Stxt3oesA74uT47BzXuAJKDb4uaKP3s1/HGQHeUAEIvfex8s v1B/XEvBCGUXOLkAudHbFCFcKAYXRn8CG+hqOrF3xjAam3UYECb2kvf4233PZLqnTTrvuNNYJoGp 1pcoU/rIrjoQd0L4feQGy1gGIFbTZKW+/pg7lOssCroygl4xn41NyK5T0joMfhD9olTRzxd4Uw8N uk91nhD82SlwEQcNkjcIoCk65gMhrciABrkK3ytAjxO4DuKCGpG8lsKgqLOpL6geQqoO7lC7rsgB 9SsEddqvrqK90ds9y+IOPGK9WDI/ptiH7Zi9WBokh0u/+ICMlGiSphgBCwgAeooeAUEBR2oXLdIb 2tghUSqG7QMGu2imVYAEhTJAJaQy4Ku1Pgi9l0qhJVk/HPC+Ssi/gii4FMzAQXqKlBo+GEg83TsM weshM9TCMlykTUq+3pCAMvikKSzDMrALfpgPK8CBIFQkJgCGszunKcSBBDmnIWwCu+i8/iXpwyVM RG5bxOCLp1tAv4PaDiz4LgICjwvUuoKIvfhQJJSrIZi7l1Zolwo0wxScPZRLwQvkDjfEwzhEhzKI wU9qPSBRqHEghiYBhiQ0xTL8ArtgjKkwowgsRfTLREVUxIRDQEQhOHr5jvLZRTwkv7RDB+9DwU0g pBzou1IwiwpyMt1bEgsohB16Pi4Aq764Ex2cjuQLCBpEEiTACQ2sQvBYDiPwB15cPl2SvhcTwxOC BIl4H5tigYSyhbiYOiRRGfspRmPkN5DLEkyxvVwZKOHiBzj0vIXpAn4ILH5YGCXZw3/gEuGqiYns PbuzhZQQuXF0uChYRqQzyZFkuE+8/roRWEmEnEm5Q8ZDaUbSkYGJozKa7EmftJdx+UmhTDppakS0 +jZBMRl3w7l9q7hlHEqojEqpnEmjhMipvEqszEqtlLZa+7d8+Sh78zKxFEtcK0uzPEu0TMswGzO2 bEu3fMvc+ybrwhJX+xi4vBiUWim13Eu+7Eu//EvADEzB3MvDOQRZU7NWS0zFTLVQe5qlaMxaW0zJ nEzKHJnCLB4KOkzN/JjM3EzP/EzQDM3KHE3SZLXLLE3UTE3VXE3WbE3XzJNaAyvLlJMBQzVoeQtp yQQZAzDdVMzbZLM48c3fJJlcWMxofE3kjLHTHJlPoSDmYTOG8Za3EIEmkjHC+CIE/im1VOM/7AAV 68wRxfTIe7TMDtnNaJrOpIyLP+jN5GzP2Rw42cwTh0sSrhhOzZlI7bMH+bkdlLHGZGAqgEQh3tSc PAi4S2izPLG16fMvBk0ZVPKK9CRPENjNIqINlXkM98zQ/4rNAS2GTREUQ+AL8JlAORmuG+uC4kwZ /8wAzNOO7WsCVOpQyxStSeyLj/i6qCC5agCSsXCJ2IMxBhoLh2I+XWI92rFG9GwSqOO6O9HQDL3M AY0fvCAFARgIiYtQzaEf2vgBjTueLgAmGJsmNfICxeFHIAAEFcVPQjIWkDgGIoCHPvC7Mzqe42GC 2hxRynEH+7BTLz0e5exDVMqR/kEYVIAkPydNTigttTwYiEMghbFQEhn9rzqVBZvwUv7sT/ppAq+g FyJop3I40urxolsMRSNgjJnqC17ATxcC0jxlpzx4MUdlvhG1G4DkvC74g7CAl0g91NRczjyxi+A4 HsLwzvu8AoKK1UstVqkY1HF5B5EgBfpQURqlise4JlPVgUIIC7OgIk3EUx+4xjWaUMFLU0AIAYmj wRoRBjTlVddM1DwxiQqJ1RcYz2JVmUEKJlJYMxv6Ktx4kPU8BiCNVvuokzb1CDgFvxYSFJDwO12g 1RH91+MhuR94g4OgTvoZUfrYgePJO1LQtTNi19d0V5WJweCAOllVUbUzIwWc/gCKANIFoQoFXEEt Wtf+RKSRfRfgmFkzQljw4IBeIEEgfcxMxAXmq9h7BR9a44D5qD8tpUGQbVcOZc4pegfdBLBdHRnU qIlWe6Ka2IPR1IiBAdNS21WrLVsZizf8uB2HAKgYS1kDWiFeeFrkFNm4CMlwRKER7UOaYky3fbHK hMSTbc0zOQCxXUz+axjplCBilVvWpFuVcYhVuxXTtE/JNDWopdxWs1zG1VDH3VzP/VzQDd02g89k FV3TPV3UddLOTV3WbV3XJc3Vfd01kzUcI5S7vF0dG8wfi5Re613f/V3gDd7fNTbiLV7jvUxkMl7l XV7mbV5jSxjhDV674gDd/gUy3L1dz5RdtHGqS1mc1KpKyBybx3wj7T3dCSIZGrOQ0Fxf9m3fWDvN xS3fU5Pc/gwSyvRbzSld+X3a2N3foP01pyUZYnQX9txNGeUEssW4CeVcyPXf/vXf/lRg6QhgRaXO S6KIq80ThcrEvYWL+EzQ2AtDoPVNNmtOCAbfGSASAT5hCbWFiFESCh7ZiPqH+P2vbCXcT/pgFtDh 6VQJBWxZ2Mzgk6nhFQ64vLNczGXc2M0A/N3QDMYBIS5hLAXOgNCIbomCmpDA/yoipR3V/kxZ9EMn C+HhTfzR1UHTWEop4FzPGAvhGrkFaOKNbNk1vTg1/tur1Vxda2xilVG7/g7+r09dzIIgYm/VtcMo 0IWRHz5e2gPqgS/GWXQ7Wg+WUY+cIrzyiPCZ4NvkT9sCjii2xhZ80IMDmzBOhAYe25IhFIFV2yg2 YNLtUO1YZAqQIYD8R0ml2fds5YvwlsJlMxeGFZn5i3ON0m0tI3PSnMvDoHbqUB02V6qYyFxQpsnq lqZIFiuxkvjhCBElUGYsAQDBDQfcgDeYj2DUpUNIJSG1RnEN3MjlUGK+oXoZyMuK2csrh3ENlQpB kZHhFmMZiB48mV3xolCZpo+aBDKqyBg+hhJBAfuyUZP5JGZUwFBpZsliaNJZVPoYnvQoUNrgCDWK vSe4jxqY4goeL3Fw/g9YmE+GHogH/U8R+Ch/QAR6qtJREoGHIWTgdGcLeQC8GR95JsFEzlfp4wbL zEVDhc3JQqAYfguHK+CMGAiysAXU0IGS9oQwcGiSsT20+thJLrVsStjNYJc4qQt4UShIzYcymqqU xuWSPmO8uY27A1Pp2Af5CabH0YHhkZl2aSZB1mm44GmlkCBdUr4fmmCyGAunLpnvYk650ghogq/H 3JWJJoiBPmQ7iAFqgp6S/hJiEOA/iuW2OmqmjtIM6lbpcz5NGNSN+LwdZWkb5QNGLtYPIoXpgAr3 CKZQxIEeOdY2RaYcgMD7Y2dVc1wonk8jJeyxClfZqNjEvj8eZoE2/jgOL+KJBS7qTJDsZThka+KB v9Bs+TTWX0QZcc26D5LRDi2EEZiRSBBuQq2AGiiLRSUm2FZoAp0+iTgjT8ZFgExvdjqnXCA5EPBS FugRcWABievrVwbkZb4V5fNYma4eifMCqegkOMrfFAabOyVPkqGnQG0PJmiPi93i6euDtcFqkhFX phimiYbl2u6CkGCCuJUOazqs07PQJCQegZ1RKiBTH/JkXYWLuWbREzLSADdDHnA95EPwDlLhUiO5 SEWI3mkrkqQAeNkI8oq/U9uYVliEDFfOjHBsXtOI5/xu2cCM8jzxWoBi+h7jSBXIktw7kKCgAauA CVoB7L6Q+Z1W/p8dn1bO3MlcYsj27LKtpeBsUFXDrlWjH9SIzpkS4Gm1BnodaO9rB3YS7R02b0zR iG8r7xRSmSDOXHfAy2rI8dTt3z6X3Uxsj4FZbB3Xkz6OdAtxsj++dPE+xHaw5dV0W6BEdb9m4TXr W0x9sqClkhmz9PdUT6oOWbd43Qf29RXudCFmOsmU5fpl4RR9Up3mZOVck3DpE+7lKeG0ds5FNRRz jqVohevNXcF0FUmJXnd/d+F1Xnmfd3qvd3uf9ygoNgUItnrvMmO5TEtK9+u98/lVzfCtMKGNs0Pt GIHPMVxjd3gfXmPLAOetbtSEXzbzmFDReOPeSo//+I3Lol7t/nWD91OC39yDp4kbOPkZa+4RJfle bdNNuJiU15npYPkmJ6j5hfkRZUyZ/2x8mKia/5W41PKA0C6UnbqdT/AEhd2fv+2X2qKh/xWcP/pY Spk3OCdqr1+m55WRwVb5sM2fL3I1fNs9gY0LKfdQU6oGvvkhBg06/1jwYL7SFdks7OReWAZOHnQ5 kmdLkI7DSJxL0KwYYHslmL1iYoUaaAH3SGqmc3w5Qxn4wXlaw809HuTwAa8Cpts97BX+w/EyOg7u 5oa2giQPEVscmNlwQuxIGPxGxqc7YAy1r6+78yoGUpSzopYHAJeK4MEKmHyTIYdbtcFjPdCmHlum h+JygKgq/tPSSGSjgCP+lAiEKjfIc0IEH4QP4eC7QVKoUGTZvduH1Sn9DHAEG1wKEwMm8sLA8fJh 1FOj1oOBWYDU9+G/gBCWvatYYkz8qggANmgACGhrNWAvznrzngNgEAdBBGdAWgLaBghbkslAIMBp AokR1NbhgEN5isZPwnICIAghIUFhIdRAAipBsCMkEgSRk0lVoqq+WvbEutgwVMEB1hZpuT5n05IQ AnR+nI2TV19VH0iYhQFfGyBIgInX4wCOAMLBo9MjiNvkFSbA1dTkEWlAQYPEBMPqagXpKyyGVkiJ 44kKqAuKwQ4f2g2KX8lP79BSLLJSEihgScmVFKFOEzFJ/uXASZPJXdJSlQPJCM7AwWjfDZtSoOjU JqJeWBukgUIKQkJKgoDBAL6BAb53aMaoc+SE3I5JXmqFyZNBh6Ew1cwls/BgwgICC1qh6tiRAcaQ IkMWAFnRAxF8xlKEYaErAL9MtLS0GARIBLyVJ2MFWKalCQI5QYQ8oiOGGJcp6ES4ywSiypUgzkq4 QTdlRRyqBCG+o6WU0KVyPQ4kCNrlzCUaYUAoelJw20FB/UaZkIjInbtQAIjR2HnBAeAGrDYm8Ijq AeLEihcvecDA74YWK2+1fOmjCYqgk2k5C6DAmUsikI/0XCHmwp4ttTCN+JFjGOsAV0ZILoQF9EOr hsRo/trrZ9IPh+XaEX+UKN6yLIAs/LA5SPmjPDipWLqjt+ghIYruYVv7hdroDwEclFyF0RUsBI/D X7CMAldoF/R0LHm5d8AAYPhpSmaPcpl7TPCDzWRESGYggiBgBgRFubmhDihjMBWOd76xcxWG+zCH ziVAKMOEOfiYg00nwGmBBnDtjQEDc0nthUF+BPmnwQkONLAJLA6s5597lK1g32z49IjjEGS4MGMH pRmj01QlAFPgJgkaucSCU/ADUBddiKDbEcppYFMUSIpZShd8jBmejkgG2FNl9mmzzZBxEnkmDgDK eeedvuFIYZNBzGkEL5Ghg8CfdBp636GjqedfPzxk/vkoD/DhOallidY5JaWZElHDLJZ6+imoaO4I 2ZtNmtpmnAVoemSiSq76KlsQhTqrp8vQekSatBba3jEn8bKrmgBCCWuctxp7rKF4AlBAN8RqisCA +EkrbQHVWnttAf9ouy232tqarKOQijsuueWSa0C23aq7rrrh8tCuufHKOy+99carAL75KsAuv/1G Oy3AAeeXwAIICHwwwtLeFxTDDTssAMQRSzyxxK9aaguyGWu8MZ0IoMcxyCGLPDLJMy5aMsopq7xy ySez/DLMMcs8pssz23wzzjlr4JjOPfv8s8o8Az000UXTKrTRSSu9NHtIM/001FF7ULPUVVvNNNVX /mu9tc9Zc/012DDfEzbZoTpL7GJpq70222kD9jbcccs9d9yn0P02tnnrvTfffWPrUQEPyBzAA6ew cjjiiSu+OOONO/445JFLPrlhlVt+OeaZa565334Dhu3doYs++tttL8bsBA4Ay7GODBRA6JBly150 ARSsfqyOqs6+u9YXFRByAAv8zjvxWpfEcfCCF7+81cdnfNHtzEtP9EXIBh/99Nn/bOOxDGCvPfg6 F+DArQyQHz76So/6afDpu280ebMy0On79fccwPqW5m8//zY3oLyn4te/Ad7sAR9L1P8IqMDB7Y9O 3lsgBFmGP1AdMIIWHFkFDZXBC3JQYw+82AK+/tfBEepPhJAJwAZJuDL8AQ4DFGhPwbj2wValUEw+ 0BaXRhO95DRICYHyQBdgYUKQIUYjUwmhBRhAgOFlZIgoYQTLZnioCXpKBuEw02iIkSSJ0A81XdkA xF6hFxU58WgLOB8ALrKAC0ygcARAY2RoBCwHLJEDvVICHvP4KSkmq4ZICoKKzPGCqc2JUF4EIzqM 8wHdLeuLyMCPF+kHlKn9EAcAmVPwzieBTYBkjRaYgBI2sgDlKZGNnkwjAQAIgFKGEiTouYhgNOIY WVqgAEZEIgBESQAJSGB4MHSG8h6wy4w0gwIvTBQf6YTCT+HiOFNwRiXF4IxRLIQqmPhWHzrT/gd2 gIEq2xTmrsRhyxXEozOsUVEJvECXGzRJQSMgAZc00gzyOUCUvwveGVEJEnpmRHD19KXvTjBLXy4r AQwAoC3PWLszqhEHwgNAPV0xgQaorgEGnVMbUfhGfd4ol6N0TGFK6KlleqqZp2GKhTAAHqQAIyk4 cUMYSKBIG0SnEdSAogao8tJQFIJAhbiAJwBAlkb0gQ8qcBFKTelQBlSgdgZ0Qnl+txEUrrF1FbCJ RXS5EYICwKIzpOP5QJnLHT3AFKv4pK2EqUqIjpINa3zE8OqpPBT6kT3JPBMVLWVSzEDxCzDyDkwQ kQeHsIF+Mw1KV9CAxZwKgRh6SecmtFgQ/gu9FCJXKFUtMOC7U0jARo+xpWOY+r86gpWzBzXJBYT5 u4usT5id/EsqP+nJjdQyIwwI6VhTu1EMYNWjgDifLXF0zEPddUx5TZRJp9MpF7WoIC9djmR3oyKl ELZFnwGWOCtkgXtQpbpElQY6LJuFMShIAxQ4aPAkIDhYms8xvWSrYBBjTFWq1SIEGNUExlNHiMbW t7lVbRqZ+kmy7vYCtkRjUoR5vn9mta7hKa4NGzgmQKpjEuIABP2IYZzeZDOlbFgGX5XC4SzkIbpu aGwYBjE2C3n3CrMAgzsWAQU+jPECt23rjTexAIJNAbddJRgIduxJ16ESjUocnhLDGls6/ipPrLRV 8LKOKVZUInk9+e3qRgGcxCXWTsDILONJJCymYfTDm7MRwWJfuqB0ZrYJlQwSFWaahBlQBSlOEECD cNGkZnjhV95kQxskAWhtskZGukWiLXekxDDY1sDyzOV9m0FlmOr3lMJ0AlifOYXZagQk5USn+R6N iYycT5gUacB9QytST4kZSQhQAAmG05499NAHF/hhP+pxgWhgACYKQMcoDMkEBYxikMzxCm/XMgAt zOIFywZqDwnUh+WygEtB2RWRMIkjTPa6Pd7+gB5pxDHafvlTDuaaAL71CGye5BPpsB8miigrQ0F4 RhU4d9kyO5qkEsd+95hAAuBIbzBX/gTfKjz4mOqNpFYjvOEJJ3gyFO7widsV4sjoKMUzfiaJ+4fj Gv94LDz+YIuDvOQ2JjksRM6BZ/slh9L2TzQhU4PF+gdaHDOkiSGDkxq7oYvIMPbD92jxOPilpm5g d8sduZMo+Jw9vUWWcp77kG6/wibhbDosLhx0VqNcFknqokG2TQheXYBLQN/un4xT1l7nRzw0+mGV igCT6L3cLT2QRaB6Uutv90Qlt/bShzRwBV40Id3fcnOUrLOBJqjEIZvQRngdkUNtmKMSbc4smzrE BDeHueukUPkGyrIXCoF9KuGdSqyccYNucsZFGXFShJzxgakEqpth6Oa2TZ9NGalZ/hiyf8Qs5CH7 CwxkRarfc2XjkZ1hAIIsLprml2qB2WeW+RBTaZAXwvECPHBfKryAy2JtidgkaOMz3IeLAvAsjL5U BPR+cf9DpPAMdwM6J2aIxDnEwE4doLQ301BITGXbGLjYtH0F/iVbi+SAYQnfFoQd8H2F1jmaO+VA 2FlJHrhbJtDHITSeH2DXiVTIJBVFUWmaigCbwdyZE/gViPTBlsyekDCFIs3UJGyJbIwBTkWc5x0B /HFCMXhYBgjTjBXEOEHgMnhBlvgVbGwXF+SQIgkVHxCOUTyd0e3GFyEhO1nFF4wYO/mc1MVATijh OZCDCbxUOJwe6m1TB0QdCDaJ/vzNQm9F1w94AuA907yJAZ8sBx76VTXBXh0iww4WnMWNgU1IXeuJ g4townPJAx94AbRAyyZUkzrA3nTpgRS8Hqdswexh4SFoQA0EV/6JghZ+Iga0RTtoQrohQnMogD4A hKycYF1MQjZgCAfw3xoC1RTMwl7JSmBFyBTWwQAQoqCZhuPFAy+kxnb1W+eZWyACYHP1XE7YBFTQ hyICASIEyvC4mGxQY69J4wmyAQg8XYcRlSORQDSYGVzcgDDVgcvRIlER4AiiQQ1qF2bYRCg04Qa0 gYZlYPDVAS52xYWNwM45wWc8k/9hk0x5xTBq2iStmcX9YTJg3Ek83xeywQGc/mIGJoAtKccwMJ85 3sYzaUMjxQRFXJM1cUFGFuMXkSRR9OEl8tk/6p6hwQP0/ZT56Zs3eVOhlaMzdENLVCEV0OPtTcVX hCM61Rn30aEftFQPqZ6e4CHnDUQ5NmQOGgFEVgTRDUA0rBg66YN3UIGuCZVXsoUgxdomwAFtMEcQ NIgP9ASvWcIlGMw4REYXjMgG/BRz/BqMYIMhCVuvnQDLnZ3B6EY2MsG2BYUk8WWzpaQhiZ0ShFG4 FYpj4oAe9Qpjul0chdvCTWURVCX/NAGv2YySgI9DXpxmcs2fmZzQKaMClSZqGsFoxgJntqZs6iCo MNJs3qbcMdyMjA9u9mYHuRgQqBSObw5nBlQLqBwXcfrma/ohayYnAZFUbXKVc8pmApnNKU2nbCLn pzgPdrbmcp5EW3WnyZkPsuCSeGpcA0jnrEDPeWbcQ2lM8rRnw+GPeh7LcMlnB23SyDAYyegmfpJM PYVnydQORd1R0ZwNgiaoQJkOgzaogzIo6USohIqO3gjGRDWnmBROJ02O4ggGh34oiIaoiIrW5pSo iZrotRhG56woi7aoi+7NhMoNAqzdf9aojd7o0EQAADs= ------=_NextPart_19F_EC78_7A698193.F41FEB0C-- From aaltclciyy@digiweb.ie Tue Jan 30 04:21:13 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBpAv-0003pI-AE; Tue, 30 Jan 2007 04:21:13 -0500 Received: from ip-89-234-97-205.dgh.metro.digiweb.ie ([89.234.97.205] helo=digiweb.ie) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HBpAq-0007nD-2w; Tue, 30 Jan 2007 04:21:13 -0500 Message-ID: <989101c74458$44331e00$bd550d44@aaltclciyy> Reply-To: "Dorethea Graham" From: "Dorethea Graham" To: "Ayanna" Cc: "Irving Harvey" , "Alice" , "Eli" , "Otha Jenkins" , "Lashawna Peterson" , "Art" , "Randell Richardson" , "Jo Ferguson" , "Isaiah" , "Adena" Subject: Happy or not Date: Tue, 30 Jan 2007 10:20:29 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_9E8_7B4C_E0BA421E.AE749184" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V10.0.2627 X-Spam-Score: 0.7 (/) X-Scan-Signature: 7b8e6f6ef974ecda19a6b57d59caeb7d This is a multi-part message in MIME format. ------=_NextPart_9E8_7B4C_E0BA421E.AE749184 Content-Type: multipart/alternative; boundary="----=_NextPart_E44_F601_3ED0651A.A8E1945D" ------=_NextPart_E44_F601_3ED0651A.A8E1945D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ball left time "Why, you poor appear short-sighted simpleton, can you no = "After all," said the inspector, "if beat film dusty ice he had been r "= I will see them both," waste prevent returned own foot the inspector; "IC= aligula or ticket Nero, those run matter nut treasure-seekers, those de = "And that is the steam minute very pack thing that false alarms me," retu= r step along "Where sail is society Fernand?" inquired Caderousse. "= How do stem sit I know?" replied get Danglars; attract "gone, as every = scratchy "Nay, argument nay!" cried brightly Caderousse, potato smiling, = "you have n property Had a learning thunderbolt fallen easy at screw the feet of Dant= s, orIt spot has always been against confess cling the vesical policy of = despotic"Let us inform father visit this camera transport one first," add= ed he.The curious refuse inspector kept agreement his word taste with Dan= ts; he examin spell attack The bride blushed, while low Fernand, twist restless and une= cork During this prove hot conversation, Dants, thread after having ex= c family "Oh, to be hissing sure!" responded unexpectedly Danglars, regre= t who had now   "Well, deep never mind that, misspelled enter explain neighbor Caderousse= ; it is "Yes, shy went his father," replied sea noisy the abb; "his right naEdmon= d Dants:"By owner science all fear means," replied more the governor, and= he signesqueeze Violent Bonapartist; kiss took an active part scary owe = in the re weaved A damaged general exclamation pass wire of surprise ran round the = ta Dants descended punishment insect cut depend the staircase, preced= ed by the ma pop "Adieu, scatter hurry fact adieu, dearest Edmond!" crie= d Mercds, st "In an cling knit hour?" land inquired Danglars, hour turning pale. "Ho = stamp unusual The wed soldiers interposed transport their bayonets, f= or they t When heat he regained his shoot tell dungeon, shake he threw himself onTh= e greatest watchfulness mind speed saw sunk and care to be exercisedThe b= loody jolly inspector to listened ridden attentively; then, turningThis v= ictorious note was pump in a smell different story hand from the rest, w = occur store "Why, afterwards thus bright it is," replied Dants. "Thanks t= o the The prisoner remind damaged heard the cry, broke which cool soun= ded like the corporal "Wait for me island hit here, all of you!" poin= t cried M. Morrel; " Dants town plane was at length roused from his teaching confuse revery by= theThis visit beset toe sand had drown infused new vigor into Dants; he = h"I want grip to know what distance crime company I smoothly have committ= ed--to beAt bored the expiration of learned a year squeak machine the gov= ernor was trans Fernand owe closed his coil hat eyes, a clean burning sensation passefram= e shock fade "That's right!" arm exclaimed a multitude of voices, " This= second departure was nut followed rich bounce by muscle a long and f badly safe "Upon my word," cried the old psychosomatic year man, "you mak= e short run humor wire word "Why so?" inquired Dants.DANTS amusement be PASSED th= rough excited all degree the stages of torture na"Are you lazily well wit= h pop fed?" angrily said the inspector.Dants insurance asked sign to caut= ious suspect be removed from his present dungeo "But," asked own smooth bent Danglars, in a timid tone, forsaken "how did= y Meanwhile Fernand jump made frantic his wonderful tired appearance, po= ured out bewildered strap "He is the cause drink library of all this m= isery--I am quite su   avian "The chilly porter contract," answered spoon Dants, laughingly, "it= dcloth The jailer, though soup farm distribution rough and hardened by t= he const ------=_NextPart_E44_F601_3ED0651A.A8E1945D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""



ball left time "Why, you poor appear short-sighted simpleton, can= you no "After all," said the inspector, "if beat film dusty ice he = had been r  "I will see them both," waste prevent returned own = foot the inspector; "ICaligula or ticket Nero, those run matter nut treas= ure-seekers, those de    
"And that is the steam minute very pack thing that false alarms me," retu= r    step along "Where sail is society Fernand?" inqu= ired Caderousse.   "How do stem sit I know?" replied get D= anglars; attract "gone, as every     
scratchy "Nay, argument nay!" cried brightly Caderousse, potato smiling, = "you have n      property Had a learning thunderbolt fallen easy at screw the feet of Dant= s, orIt spot has always been against confess cling the vesical policy of = despotic"Let us inform father visit this camera transport one first," add= ed he.The curious refuse inspector kept agreement his word taste with Dan= ts; he examin  
spell attack The bride blushed, while low Fernand, twist restless and une=    cork During this prove hot conversation, Dants, thread = after having exc family "Oh, to be hissing sure!" responded unexpect= edly Danglars, regret who had now    
"Well, deep never mind that, misspelled enter explain neighbor Caderousse= ; it is     

"Yes, shy went his father," replied sea noisy the abb; "his right naE= dmond Dants:"By owner science all fear means," replied more the governor,= and he signesqueeze Violent Bonapartist; kiss took an active part scary = owe in the re         
weaved A damaged general exclamation pass wire of surprise ran round the = ta     Dants descended punishment insect cut dep= end the staircase, preceded by the ma  pop "Adieu, scatter hurr= y fact adieu, dearest Edmond!" cried Mercds, st   
"In an cling knit hour?" land inquired Danglars, hour turning pale. "Ho&n= bsp;     stamp unusual The wed soldiers interpos= ed transport their bayonets, for they t     &nbs= p; When heat he regained his shoot tell dungeon, shake he threw himself onTh= e greatest watchfulness mind speed saw sunk and care to be exercisedThe b= loody jolly inspector to listened ridden attentively; then, turningThis v= ictorious note was pump in a smell different story hand from the rest, w&= nbsp;     occur store "Why, afterwards thus bright it is," replied Dants. "Thanks t= o the    The prisoner remind damaged heard the cry, b= roke which cool sounded like the     corporal "W= ait for me island hit here, all of you!" point cried M. Morrel; " &n= bsp; 
Dants town plane was at length roused from his teaching confuse revery by= theThis visit beset toe sand had drown infused new vigor into Dants; he = h"I want grip to know what distance crime company I smoothly have committ= ed--to beAt bored the expiration of learned a year squeak machine the gov= ernor was trans  
Fernand owe closed his coil hat eyes, a clean burning sensation passefram= e shock fade "That's right!" arm exclaimed a multitude of voices, " =  This second departure was nut followed rich bounce by muscle a long= and f     badly safe "Upon my word," cried the old psychosomatic year man, "you mak= e short    
run humor wire word "Why so?" inquired Dants.DANTS amusement be PASSED th= rough excited all degree the stages of torture na"Are you lazily well wit= h pop fed?" angrily said the inspector.Dants insurance asked sign to caut= ious suspect be removed from his present dungeo     "But," asked own smooth bent Danglars, in a timid tone, forsaken "how did= y Meanwhile Fernand jump made frantic his wonderful tired appearanc= e, poured out    bewildered strap "He is the cause dr= ink library of all this misery--I am quite su    &nbs= p;     
avian "The chilly porter contract," answered spoon Dants, laughingly, "it= dcloth The jailer, though soup farm distribution rough and hardened by t= he const            
------=_NextPart_E44_F601_3ED0651A.A8E1945D-- ------=_NextPart_9E8_7B4C_E0BA421E.AE749184 Content-Type: image/gif; name="wseejaokiiliym.gif" Content-Transfer-Encoding: base64 Content-ID: <3277401c744588444a7690618db685@aaltclciyy> R0lGODdhawFoAeMAAP///9PW07fO2KCkpQUYHcl+dYV+dRxIba+6vFNTU0dxm3EAAKIdCbdKR8yh lti8tCwAAAAAawFoAQAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6n9ColESYWmmBrDaAygq+gk0WEBhczwCCuVawEN5wg7taEsAJB5sBcQvc4SEEXBN+f4IZ bwAIh2hTeDUJdIRqZAADBHwrBnhchYMylDZ+YSSXn2QEchOJGI+NZwQKF2NihKdknwcEpBJ+mRKs WhbCE1+3qGurZp8BvAjPg83PEggD0wACz9cFeJnVyWQD1imjFwYJCQafCOhrbwenBAkUdpmb8sDz A3sGvAl8i+R1Qpfq3IQD4F7RwFfhzrxIEiKFWfTsTqc3CtRcehPvV5p//oaA/REJiALEWakiHnr3 ho8heS3TOAwQCWHAjIcWHYg070Q5CoUGRKoiTl7AMrGYMVw1b1M2fAfyXBKgi5qaRQNoCipU8VAh hSqIteq5KiemRVxiRtqUqSorBWY2VfDzz1oiP3lkWorJDq+EehRYAThnIKufNZfIkH1UFVuylKxM peESaVDUw71CYaCJ7ljmP1ySZaSahhCqY2SBHVhEyo7QKosUrczDkC5mVAlo5gV7IqBgN7ImPZ5H 6Y2cglcDCoiE4NPJSTujKuDCWrVMSagOGDj3W/AABRnhhZJMBsGmeY17DeAmy5WdtGHeDDWOZ+Rm +8OSgpkgVFeVLO+s/vEeUK6sosB8cAxQFVq+pOHSH/0wkoZ4u/FGAl5RLdVQcH/tclAVO10SiSmX HIjQGjhR8lxmHlk1SCIlZWaNNc2ZhB0wxyFGBxy65NGYHfQRpwpaDsoEBnVqbKHBeQQllBkvnyGU EQW+yXaKX4FVdMuCh4y4Y0I/fQRAehaOoFOGNypD4GOwxQTIihZUJheBLcpGyiMxolLnJC3i4ZoE iW3y4kN5CbZTGsERicmYNzbYAZMjotQnI4LOlQqRgaUGkR/MjJkHkXY0VuBFvxhwAFVOlvkBhrqk FlhCuiC5zBthRCLLJqosQFtPJEqIjAXcZJLIRmZMJdFgmkmAK5LF/lUBJLJcbEJboXTUNKGLYl4C z7O68LFJqpmh6dltxSQJBwIZZiWobZOcxU4outglSCKVyrRGQO8C6FGPqppwD0et/MGHfwUCfImO 58qWMJBKOUmRSBHNR+07F2yEUTT23aGLHT0VgkesKWFzCE4iwzFIiuBO4BuUdFqwUQJCDbIRPIAm S9A7p5i6E3XLcGgeUAnslEluFGTYrwkBIMDyXFswQ8ssTHPg2dFUxxDVnlVnrfXWHgzF9ddghz3M 02KXbfbZaKet9tpst+3223DHLffcdNdt991456333nz37fffgAcu+OCEF2744YgnrvjijDfu+OOQ Rw7W1CxQLjnc/gEwoDkDCyzAAAgNdH5L6J+f0IDmDmhwuucyNEBAG5fjvUADEzSQ+gehw94L6ylo rjodD7gQQPBkFGB57G7PTggpD4xLQQGcf3J66b0E4MCVlUhwewW+V7D96cQD4IDu2YdPxu0OhP9A AcQ/wLn5ExRAfvzHI6816w6UnnkBC8B++uoUWB8DaHe+09WuAbZjwO00F7rhIZABt+heARDIv8+5 b4BZUKADFhC8B3gOdRuc4Oygt4DUyW+DqZteBhfAhfwFIHQSCB0CO2c/tHnuhQsgQ/8A8AACmBCD p7geNyTwORiKbysA4AYXNBe8APTPAQQg4AS6J8MkchAADQQA/uckQEMnNoB4otNiDr1YCTK6D3bR cyLslMe/NkAPfjX8mvKSeETi+e6MFrjdE4O3RSxSb4NLzGESFTg8C3RPjTy8ohF5B70szBGLguTd Dgc5QB4yAHbQ0yHxYOi+4L0xjmV7ZB2JaEEGwPF2pCMlKccASDHG0JQYOOQOPciFRbIukwAoYe0i WboSOjGFtMPjIHWIyhx2cpD1A2WZyEiISeoyf9ujnyZVmcgHBM+IfTTjlbrnQTfqMot9vOMjo5dL Y74OhZmDIDNDx8cxXrGNkIymMrPmxM5FkxvT42IYa0cAQZYudLwDKDvF17l/dk6KROxcGzjHPs7N cI4MLB0J/lPnQVNe8AH5a8AEB5jF3DmgAQlogxc1KoEChDQAJp3fPFfK0pa69KUwjalMZ0rTmu7g AQjUKEYHGL6Mnu523bSpUE3HQFJWUnuzU6D2sOYCle4gfRgdnzz74D84SgCjOHAUDtzHtgkisKQP pEBOIZg9GhjxBxskpPsmeQP+mVOQFXAdQmnQQ6fKYINwTZtXCehV6lkyp1Z1AU4xqAHsweCrU2Th CriqgQ0ScBB+tWJg4zpVKIhyM8msHlAya4Gc8pCCxUMpArPg2ZKilKeZQyxZxVrazc0VeuCLK+rc 90U/6g6n6VPqKxUIvR8isHkWwClGa6vFATogfx203Rc3/jiC7l31qOm0avM+SQbOoU+hc2FodR8b DYdWM4kNmBrpMCq/GFL0uLAs6VED+Anyrne7S2xhUcWn1E+ejn+fGCBs1dtb8HZvtprjgiDlN8mP KjWjfdxAPnNZyUJCj6yag2vw0srH7k01p1+ErVXHWoEHX29z9HVm/9bK1xGuLoOI9R4Ny3lN/cqQ f19k6Fw94FwuzoOWQW3mCFnnwebxOMBA4aATq7vQHTqRj8O7Ils7q0tX5hKLBLhkH0voQSnW045R xGlexVhLKOuToG0YKEPJhzpuhHl21+QlQdNMRIJe1YooFQRtgcuBOWNxtIQArVePSwjNuRF8nsGw aG13/gHYvterzfPsRxH720Xz1bj5K2WKKTBfCH4RsMhtIw4nu4Ea5zJ1AVXsLokYXgkq9r3FDeAl 1+xHCoQwvRiA4iBCB1VUpA6KGC0hNAN4RVbjN4A+rO1Rt4jIVp51AspD5K8Z/EouplCBBKyoHZeb utSCgKPW5ChrbffC6YXvf8bLaWUxTIYHqvSFA4T1RhP91Yxi0nY4RayHVT3pXqSb1JfGs70vHdlr +5V/XITdBs2HTfbN8ddLZuZz2+DCXCIUwXbVnoQ4J0g/MJwAuY51rwcOSUM2+Kgw/CWrj83FXrqR EYxUrIc3mmeM70/VES/06WpZ40gDE8jPVeqJSR2//taWVrNaDCtYv9ht2i26DRf8MGIzGk3aSjGE 6C4dA4vOjOPyuQSTjiIXS3yKgrfazYikwA37TFEIr5a+42sy+zosodxlxoQ55B/xTtFjpNZyy4lc oD//o0u5d7wCyVY5yv1ZuioT9HaDMKkfudDEVa8q5fMjZ0UjK/kVu9V/2i7ufTuhO0P/E3XpNHpR K5pbnlrR8cjm3VpZmDnFhnFzczeu/Iw3AremD3q6g2L6moxsH9YzyV8UMfmgODs+uI6DDIgyD/up 1ORrdAG+/00S+6k7uHrR77lk/imgT8DkQxD6kc1cNDyXRT98kPzgB7znrujEfu5ugKL+NBdnXUKl /nqwc8bvHKctMMkjyxbZ5fU81MN7qsc51mVJ2KVwkcZQOERlm2M95BdDszM8TERJ84NusOM+21MA xwU76aRbYrQ57yMCUNWBt4AAxwVH1sR4wBVV6pM+FWBNHtg8SkIGWIULnQBczBWDdKZFzWQ8dNeD QGcauDAXF3glmUU2UOMBnBU78TZW/ZY18Tc2fpVjLPBRTThUMwA/V/c1liNyUzSCK+AHlaWFPFBI ZpiGariGbNiGbviGcBiHcjiHdFiHdniHeLg4TbOHfNiHfviHgBiIWwAGhEiIXlCIiJiI2aANjDgN jfiI3yAOkjiJlFiJlniJmJiJmggenNiJnviJ/qAYip0YFdIhigpAiqgIF6vxC6yCiq74irAYi7I4 i7RYi7ZIiqd4i7poirzYi77Ii9ryHeChicRYjMY4iZCYjMq4jIrYjM74jNAYjc64h+jCMgFQIXY4 HXEYABxCCNhYh6eyjd94jXk4JkuzhuQ4F99Ih+EIh+kIFOs4h+34hu/ojSAgFjY1jxmAjzBVj70Q j2NjC0KljzxoTQa5gv04jgApkAFJUwTZCwcZkRGZhYzjj9iwkM0AiAJAkZLzkMNjTVAlkRLJWUGT DsfzExwJNhZpkcWgNNGYFX/TDFazNAYZkiLpggcpBpiAFGYQNIiQB5xCNysZj+LwDJUYiZOo/o0c oA2Acg1EgA6WwjKm0gUAoxJp8jAfsgEEmTQYdZNdKZIwmAE+CTEbMJZ2M5QVAxfCKIxq+YkIAB5S QzGM4hIpowOxMQmAEREKcJcksBzf4SELkBV8aSWLkgYDYAcasJUgeZM2mYI1uY+FiQ3NsQdW6SFj og+qACRM5QJKw5AooCHZcI4JkQ3DoJAXMIygKA6fKIz14yjpmJIxIAl+sApZIBQdUgJCMQ6Isgrl QpvpcJsYQJAGyYEgSZzjQ17HWZMRp1VlAQA+SRD5sBdpIRs14DFmgC8+MRR5YTGTIgkB4SpoaQFU gZrD+B1saZ6s2QGsMA1lMAHf4p5qsAda/kA03KAKLOCdkvAP7MALgpAAHLMX4NASN4IVvTAJKiMJ q0EzwKAB1mh1syc/MkicEBpVJsVUzKks/zEd0HktnOIH/IAFjCAPhbKZHKAR0DAns/kkIoMKEQOP pYkB6AIXaqma5UmjCnCOF0AkeVEdO7koJskRJZIgdNEC+HkQz0CZwOAXBBoKK5Eml2CfLHqgB7Ec /JkBDwmh48OBVueYFGpSSIoIHDKbieGc7HASUJmiMCN9L6CbepEZZBAfSFIBMGMJ8GiZYSoJc2KY q0Gb9lgBpIEBAvCLcNGESbIbHrISZrAo+BCUg1ErCzkCRRoRz+CftEkHdzmnkZkmhcEO/h1yCmNq mBKSJlM6DCcEkluapQWwHfLZAVh5qPMSF3OSCBRRFSlqAybFCLOpEwoSNJ8aC/dgKb5SJDVjpP/A m31KD92YlqZ4mCJwHp+QE3BBCVixBowaAIWhISkgm5KwFegCKLlhqXSAEABwisBZPeNwqPlxEdQ5 GAD5kGRgAA8ar/JjDVkYEHs6IUixBxSBFwJwMOahHbApAj6Jq85CB1OSBvGhI3ESK2rCHwhajXz6 F98YqGJQDaFIryLwFavQHF/inP8wCK3KBWSSrXRimeMaUjsyrLtpCf+wIhgiFDVRpoqBCvVyHgvp ropwDuiws+mAsReyGUwYsCFgEJNh/hXrKq5FywiIWQE0syO30KvsQK3Y8afIillbYLGcSK81+AGa oROL8A+xgiBIsSOYMBosAKWnUQFTCSi94A2hEQ5z2hDiWgZrKQHBQROnUA1aiaNZAIl7WDVrexpB OaYM4SEd+hvpUKxqgLRyShuq0KOnQLXFkKzVw4dH0jRlhQKZkBZ8MCB+WqBJcDBxK6eUuwLuKoh/ WybccAeowAhjirSWeY3RobYmgyBtgqEBGqySSw2l+5SYoA5nkDR8K7SJuTSYW4SB6DY7GbivwgK7 iw29SwRJswQ1ggQ4OzjygQFKqQLPS7GBIwBoSwTXa4bP+5blOL5aWL7RG4foO1Tq/nsGj9oExSID 2+uG3lu1L4C6+ru//CuI0piIyxjASEmJjHiM4nAAM2rAxSionIjAuuiKnvLAEhyLL1HBFnzBGGzB GdIioTLBHvzBH/yJuMjAJJzACnzCkijA2oAqiyjA//vCMOyM2KCI/VvDNvwC96sydQmH9duG3GgB epuH7StU5bvDdzO91oujafi+QqzE5PuNQYyHQ6yEL1XEeOM8n4mNVLyRvLC1F4Cz1iOvWmpNJQAN 9VO9rHqY3uCSnVkEaJwCVnwDCXMP1NECCLIX+HEB0ieXn0GiHHAPHZMwEzAf8+AxkWkB7ro+Wnqq p4qQTBgL/pEWUwMwCxC+JoEQ/hzhBzjBHCOwEcjmKiRwFGXhKitTmX76jeKQVQUDEOsrsMHhFvHx BcHaEM07pimaLCGQAHv5DE/hphiqDCYrqhLgkSfEyB3ooKVaP5YJKpDZCZTTq+BrBtrhKc2KCaYg JcL8AQZwIJVhmNyIn1ogCOfQt1OLykbMhB6Qp5ZMNlQcDcewFN+apMLaCvGzrRXBn2NAqXhLAans EVoxNM9qEoRxHFUanEtjzAh9qrM3WZ+KsNhQz4U5IL8wFVQSMnzQE49AE7m8rYUJJ4GwDxchtfyx G6sRqp/wvKm8hHMBuoRwzr8SxIWrC6rwLzBxFAXgH7SbChgzzxogCdBMpZWq/gbpoAaM4CVpUpUN O8ySWMjvcK9fbI2LXMwdqKWLrNCBVSDwmRb+aQdycMsPoTS+wiMegdX3GBjaqghpmqiRCSQNPa6F +QkNPR89aRi1epEukzJvvI/A6wHDMjRV4JOxccsPUg13icu+kRqHjAgOu7H7WalxapjOuaNOSitJ vRdqUpvZbI4xqFHjo1EnNEEcKK9bSlJ6PI4r8SJAuRLtkRXjOBSPEb86iSmISaAbU7SBrabx8jzY Ac3X4SsoXZdtvBni0IRfmwxD5JyvAQwIcNxQCShF4RHOkKl+XBoqi7B5ySl0oCDKPc+a6hKcWwGf GsWzXDRL49mfLT8YJsby/sMAv2kO2EGp0AoesZC24moxzvEL6YGtIRCUkjDb4eoO01muG0u0eWq3 hpoMg2nX4L3DSXMMZdAPkBqZcmGtlm2Yv6AZWxGZWiXd6inQHsunGa6yTBoGZCIUhWGY7U0P9owK TqzZHXZJ6i3GCLSzMIkSqnDLkmwdPPqtaWGfVTnfrVsCjDrN2dKxSbsGK9IcRCMIy2EBeToeafLb HdDgWkDYJVAvMqETztmkAEPZghIQ7aIOZjkUyiynQF4W6lrhmlGSN2Ix4DsS/h0TPG3Qw+BnMf5A mxNSeS2eeNDNzvoGB4wJIxIQCpIK4ADICDzIgD4CmjmnGdITJwHklrkT/r/qsHjAHfJwHthgPPKw oWqq4Pzs0kmzD4URsEhMDXxwjcUiyXiRNBNdyFAaLYdsDDqQJG0dnTBwuqSDYQ/EszCzkSAQxRXA ivuINXtexjATNHkxukhcvbYJ6yYbLp0rDtu8DD2T0nR6AVKeBEFJqVeA0xUz3SRwvQuoOTurUcfe NjwR7avQ4iGw7Ukgyn0zvn27wvwoN9kwNcR7ynd9vu5OxObs73EI73eooPSIyuLOhkMcAzZcwzjY 8DYcw4WowowYqJSLFSWciyC88bDII66YwSAf8iL/Er098iOPiiaf8ioP8h/f1ByPihH88g+s8Qgs qAriJN8h8TpPwxDf/vN9qCo3OvCUy6YF/+82Zb4LLvBwiPShrvQZ61JMzx/n/JFdme4vtfANuVI5 3JQbUJMgiQCLWVNYPwsUqdHBvu9VE/XOrQFeGZEOafRDGPesmtjDILVoPwJUnK32me5M2ZJAPPRM xZgS6dL2g/VlUCcy+QE8sQG3DrQrTQ4JUjn+gdGi6hA1EzIqA/ib8aADEJEOsB0GKe6JSxnN3RCE 3whEKzUjsPBlgKNW76dg/SJFQQdBYa0F2xSCUCWGWekmgCnjTQXV0K9pbhKLURE4QiWafwHro6oG EJJeugfWtNdl6Qps8cVGLsc3oumcaRxlEaxe08d76wG6qYROuQHy/gkvu+ALLiHZPY7cgr3lG8nu zYrPY5OitmkSAEElDOvLRVP8BIv8EADkHGjeUJwTEukisYDgeYrxUidikAR3BRBCtm88D+rJOIBE Ijdc+RCDyi5A4kmCgAGPsCSkZIfOMLCULRFZHSFI4EUlVQvBIFECDDUh9FiFSq1EXOJXJBwUQb8m sQQylZ2mnZVDMZcptqYZhRWFO4kTB5QJhKAYgAeHzzUiQonMGbIYGpI4NQABR5EohJ09PJwm1bNO mVkPwyWulwMRCSwWTcGoTsgVY9ubL6KAVMdcNIAWFq6+mIQAGgsz7Mrniz4b8QMpqhFSlT7HRBmB VyoueQ9JlQqZ/kvM+yBcLp2Io4VOnDenJJjZ4ULdmTRT3ggAV85GE3HYdk3YQWiKOlxk3HEspMIH sgkHEKg8dsOZRTYeyKmgsYfGFEICFnUcYIBGHEJLogR4JYTQrJIwLyTQJ8MAqxE18OUyx8SqDQMx 6LiChKDpBEr9NGAqoGnEAwZjQ9hiFCOAkFzislmz4E7KRqUhWeDVdaoDAUm5Eu4jE2ykwmKbUjBT 8VLLFshbPIC5McCPhyBHElBMgISJhU1uO6n7hqUnUQV8yz3Nc/fMkldMamk0JpXxmYJK2mj6KiHs Cn8OiKkoMBZTwSE3wWQVR7cORDdSoCutulCQKEM8ch1otLhI/iMnsxFr3IoNh+Mb3xCsZw9sBmXq 8eXb8Ejm9kmNrx8FQQ7EPjBIEtIjO0cu8GoSch5IoLjivLmArLESwI6IpAqhYQlSaGHCJzGwmYIG nc6ZDxI6YuuiDNdMHEwmz1rYRIZWGHIkG5fgs2GWyCQzaz4ee+xRtydWKI/HA1X4bQUGkzThhAYY xIQlWwxo6qef/FtPRFks20QlBVwchkdm7EuPh8E6lO0wAEBqob5C5BHzkSGvsJGXYBQxYE4f89Qz DDObqXO+Ii84UgUFkwyBvwYbdDC+P/csp9GZOJKUBP0uFPKAeyKLaVMMhkDvFxjqDOaISB019VRU VwgUrEhD/jD01RCgTHXWUxeZU0pUPzWwvRy3oCgaWoMVds9VfYtUQQNgZZCTYZvNs1FhdcVAPXqq 1QkynZzVdltbigVgUEKfWvBV/obj9lx0bZFWkWk7ja+3dOOFyVsF8CThm57K5c8nHeX1918FoP13 YIJVgGEFz7qI7IiemEtCU1t6lXhiiiu2+OIcrdV4Y447rpY9kEMWWWQkSjYZCQG4Y/hklls2WYHU WoZ5ZpprtvlmnA/QeWeee/b5Z6B1tm9ooos2+mikyVAz6aGFhi+KpY0OWmimq256aqyz1nprrnnG +Wuww47ZZT9WdvnskdMW+de1PXb7bbjjxnhuuunmBV5+/grWe+8cMOX7b4IPNtJewAuXd13DE6eV 3lIVd7xZxB+XPE/GJ7dc28gv13xeeMHd/PM9Mwd9dBwqJ/30HkVHXd4BBFbK9NVjh0l1PfvFIQPX Z13xjAmpi4LEVkwq8AzGBui88XZll91vZ0UcIineg90BjBa+jI+pYe5KGTkf6oEoo4WO14Hi+XJX 3lnmhz3E/IXYFZaALLayPq9NABzBxOgeeWsE8I1HMD2MWURHkDlfvNInrJVsZQAdGA5r6vAGYKRA GU7wi4/gdxWF9EQWHhoVI8STE06tKHjjKBA+oCA+hWGMcIoQySHEU0BeIC8+B+SR7RThEB4QIiuD iIIQ/pAwDSnARRLZQMVDenRB83igBhssTBtU8YoXksEKu5MQC7yHQSjgpV4pvJavdEIPovjqGQ3J YsFGOKv1TcAjqqIR8TxlPmBIpl/ByBQOZFGYq7TABQkpgGuIiMP8YYN9eLjgVJa4BxpNwZBCWkk3 woSdKpQQEgkT1Jy+gDJMLhCTs+iFLXpIGcV4YAk+mYAAOiOTLbQuT+BD1UqeQocWfKMrU0jkAod3 hdxVLCZzzJ0BtkADUdghHDUoU3ewQQlSOvCW8UHiVgDjBqicYToD0kQSa+CtXKjCgUEK3yRsNA0Y VKAC6+kYsNQ1PDVURB1vOAimiNgCCOrpNo4aQGei/tKUJuAPflXkynkGmbxJscF1GWnijAywBlLI hQq+pNESHrIDGVJoMW+IgxETuY0dQsIjyRJaVk55hFOMRGj9oSRYvlkBa5HzCBtbYDn6WJAZCaEN zzwID9ShGvnMc0w1ic4upMgMGsCLKlThzkt0miZo/ZNONjiEC1xICO7Y5yZEkSoTplCUYFYBaj1S ZUo6QZGFcCEGLkBA92jCjRkgQQHcSesLSIqXkvrmpCVbDxLMZlevrNAQVxrBJt6wBjdJIgBRrYXz 8nTUE8Hlj0ygQvH6NJ7xqGQzLbGBrrL1qLj+SGAR1RYZ4ikkpRIhs1tE2NnE+bIxInJGVJCpFIbY /gGdeSAKvQPTo7TjR++YpAK3JcxekJjEyuLJtGfLSmgLeASBGXcIo51TAMbGMvYYj7TSkKJ/WgCY qRKiXqgYx00LsU552tY6femSEqfVohDBqAOJMBE1g5setqmNPZeFod6Yy1SYmRZmxp0jG1JxL07F gL6OMiF1JVCmOCjDiHBSwxiqJ1NWkMY6hpVTfWF4X6ZaJmddRR1OocGGLGQLsFoSUjbUU7L2HbhO YO2bci38OAwz9Qg2S8KL4/OTODmhP3qinY0lF+NfCLRX93Kxj8O4LRr6mHRAdtdjlKy4JD/5c0yW svKiXOXLURnLq7vyln+sRb16WXNdFrPiQDq4/jLLLmBp1txonVo3OMc5bnN+m3zVRteQDVfPe95z 2DQsXbF1TdCDzprVjuYhQyda0YsumjpslDJCR5rQYqN0pWfGZ0yjzc5qo/PGuNNpUHdMl3GuG5tN fWpUp1rVq2Z1q139aljHWtazpnWtbX1rXOda17vmda99/WtgB1vYwyZ2sY19bGQnW9nLZnaznf1s aEdb2tOmdrWtfe0cIBbb2yLK5XKkCFKHW9zjJne5zd2rUKdb3eumx5nRmGl47/mg86Z3vcWlLwnh W9/75ne/9S1prcGD0QMneMENfnCEH7zItk14wx3+cIhHvOE8izjVCk5xpQFc44RepqloITS+/jg3 44Ie+can1geTR9o+KWe5yksetJX/7Gotp3nNdaYHCaMR5Y6ujNIaHfOoSbzRNzf0zh7eJZ8vOuhN EzrS1tp0qEe9akDrOIGT3tdEJhrjNXiFokGydK8T7elbH7qaYE4jy5S9Sz0jA9KltjSyJ93tK0/N HN5ONeJJXe9eB7vW2b7wMe5c7FCiapvOMcG5v2nvZOjA3Bn7O4gzwYdJp0bRIsLooEsC8njUyU2q lveoG33xSFNH36cuc8BH7OrG09lGFP+DV7jgdzADiVX98HTA4H5nSDfe0FJjesb7RkS0sE/dUb72 tiNhaONU2nqQ7sZpLI14eK2uLAFDD6Tf/kQdKrXPAgXQJcEmEI9D+34fum6tkjCeHurYbvbpoXz4 9SHxpB/94imeejwsAn4J/F0nduIhAOijv1Ak2LKN9RosHhCKBGQsqyKBYUqay3Iqq/CeEKEHVxgH V2isVIIiEugAudCO0ku/MqACp6KBPZI9jHAqpzqIiCCBtOM8IGICSciKGQAs28AQEtwLIBCFjPC8 +vvBpBEa/KMuKdI+Spgu/SMBwXIBEMIP2ziF4Es/N3qFIZI91VK/8mO8kpCR52AnRXKFD1QIBJwR 6aBC6xI4aZINIBiiLbSARAiAN2iEGVmIDtAmohml3luD9XonKpjAc7iM35kM8+o6ICzE/rITQlpp qpvQh2+go6GhALG6IIqIwUSoiQsavymkKbKqK/L7AreDAcAIxEQwA6iBnwG0jWtCp8aSph2YwaKB vme6DJDAEAerAz60Jj04vDtEtKSYIExkrz9kQykgGls0RGPMOJSruj2hhbRrvf8gie7jih84hFM0 PCi8ROkAwNjLD6LpOyB6xEpcov9orGHkivEbQKtoxWJUPNuQBKaIDjIUk66ri3XgRdgjRl6kFIdw x2y0g/zwiMYSmh/wwWMEQrPLuVT5OIujMBcyPBQ8hzBShenJQCPqgDK5RybkgS9iGlAER64rpOk5 RZmSjW67iZgwPDoYw62IDTOMgj2M/ofnuAkcGkACmiCRC75fSsUfuAzIKAwokowJUhMCqoNvLEiD vBplrJ2Vuz4LJBD78AHPIhqTEQOQiBmQQAKPyEUxsI/6OKiewLyk6wOmWMqhcTDA0EpkPBq4s5qo Ab6HswC3NEq59LukfJakIxyylJq53Eu+LJqA6UvA5DtE1DmqaR2KeTmMY7u2ZLrAbEzHfExjHEKD gEzKrEzLrL/NkzjJ1AGb65m1YjlLC81KizfSLE3TPE3UhLdNW03WVJsZaM0v0Bh3QxVscRvYHBmT qavU3E3e7E3f/E3gDE7hBE7pEQF285hzS07lLLdt05y3aE7pWU7pnE7qnJjidECi/jhO7dxO7uxO 7/xOUatO8RxPc7tO8jxP9ExP9VxP9mzPIUtEmXJPOZJP+lxPIqtP/GRP85SYTgkjcZsWyOiFOCo1 TZlOACU1SlHOX6gYb5jOqcpPCP02+LzPhWkPegDJOCsZfulJcjJMugmVaWCY5Swr/sAROZMs5RSJ JrJO3YCzAMSULYglApoqCo3Q+txPTWGTegKRA7UYeOSubdCgBAygiyyp+QQwuyEEnLMC8rlPFxSH ARrKuqmnUBy1eCi1kWgFAuq6GrVR+sRRAnomSISFU5obN6iFURqDdhsEMx0MPVgP65rAH6inLuVP 97KqG4SCyWNBPfI8W4wKxrMb/nz4naxSJENdUR+FoBiVw6tChZXz0hudUAr1D3ExQfjxgS7xUB/t oVZ4g6dTBjHwJbpRg6FghAdTBVXIECJdPjcQl6HwD1kAB1SIvVhSBmXQA/80U++ZiB14CkwBVWUo tcysJ8lSg6iM0WmE1Pa8zknVoWGw1N9ZowCaoDTQClAVsoupgwEBjKWRhZtKCDPNifUgxym4Vrv4 KyYQBy+8rivVVUcYjOxZQVBVpDal1+rhypuA12RVVvuc0CG7DN9SBhgw0UQlEXm9LmwtWFIw1oCh iKK4LlXNVlzVwdjoCDiQgjewgFdwU+3YBgz10V2VgpvShXhok2wF12NKyStB/tg0kQp+7Vc0ioNv s5BFvS4voNeCDVPBuq6hcFEJo8oVlCUMwVmJddlePQUFHFpZqohXMEEgoqrWKSui9VFLUQYTzNg3 RYMeClepwAZ2soyouq6DktGXVU9m/bZ39K3Cm1ry8cHLiyTrK7UX4cbqCtk6tdN9tS6b6Fp2SgON PdQ/RbQBzdbnVCIaAcjBWsS77RV3UyVpLZmtJNiyRU8wDVBOmkQknc+5YY7iMrdwyopMGM+emBlR lVDykdIoHVWjyw1eopSEtRiCLA8dgdLJhdmElFlNWdePXdwhy0zAGrdrBFLxLL1ZlM9yOYDSHVGH 6QnJ9ZXmrd3zPNv3fN1w/ltQ5uxR6gQ399Re6eRe6MVP6f1e8R1f8iXf8C1f9E1f9QVfSV1f931f +B3P843fcFu327xf1hzOTDMUe+vfO/FfAA5gAfY3Ai7gfrtOijJgBV5gBm5gfQEbAQ5g/d1N/L1f 7qRfgLrdZtlM6Ey2ws0l+kVfMJoYuMkY8DxhFE5huDHP5w1hBMVe62Qq6nwzXaJeF+bX+b3hOFuF cnHDtkWawXXRLk2Zu8VTPLJRGI7fHNZhM9U/ovHhITsKkKGIIw4gLs3XGo3Pb6NGT3zG7iU1kGFi Dr4d3OVPMTZjpTkZj4DiHH0hbDgKK1YD5GUnLYaMOo4MMZWqB4UY3oVd/gLFudbj3iQu2yXGEBqe 3k01WuVELuZsKnGREgmh0gPM0Uki12z1wRC84+ccMhG8LC6VjF/RVLu5EjhjPPbghmShwV+at80I t7Ji5PRc4p7q0mv8Xf4E1+U8hRYutY2VEirtDCE9ZMk4jBVpUevUPtlgvyzuUhXlJA16C3olxCFB 3SOViSFV2JWjUp9TpRCsAjqKYTlKq4gVMhsG3vZFW0IQZsnooxgVLP5kiBou54yBw1lI3nDjhlNC qhnojC5h46H1gFeCKV1C5kcY2V6542PKj3X1BovqnSDgwcxwAwG4E0q9Embx0Tt13VKyqV04BLhw kFNCXBGwJ0KFRwBB/tTyPGcCIgXdbaLnoFtYUpqEMFnG3QITkBhAyDcJ8ZvOJeFfamFSXatOcCXl 82f/CEAGyg22hQx2Eo9FaF6EXicGQiIdypDZAumtXAMcs5U3QF6LTmeMbgKGKiuUOMML2mkqPYOo 8gqVkKLZaoGJhqcqKJtdrl6Vtuk2woAv3Dyh+Mqe1dYGHTJp3tehpC018mc79uJeYQSo3AbkLepm hQM33KWl3gJlZiGyteNJVYejyGvk08ed6TppzWq74IIrcQJFjuJ8ekbzatkjENWhGawdIiPyGCYn XL6SyOW7LoGGiox6WII+6ouhsRRbDGICaqounQMYOKgCeJg46KIc/nEviQlFfsqCeoJstO3a6qhs /bCuGDiJg57UbPidA6yDhwoGY/UJ5tstHwhaa/5nXeJYduUtryWJ1iFFscyPhnjXrTyDJYQNlL7e mE3Y52CTcQxAmxpZ8qCAtjZuUNbkLUAB9RjXsGhXwQYG6AaQ1PioVgiNDcru7X6NiinZ5zvq8EY3 OqgSFgjwXo2HMdAxLd0KUjZx8nEHWbop0xbZDIQoxPhZb7BUBezZL4GoLegS3R7wGj3TvBYoBB/b OXil8usMUqiI021SQ+gMDB81iolDYs23YdihwKZkOBmAAgAQiynZHk/tTZ7Z2/IGU4oqBpuLqqqP 2erAp4yniLXT/ibojOpBBoci7NgGgmQdR0fA7zWwjxBhcXKTZROs05XYvgMTyz/3CV8qI3HTmOgD sf/kiYaht6+c5JXGiOEx5unehpfO8y2AcFp4C8cjyuw8slfX9CH7z4zeiDeMZQPd7Zqsa46wnf5K XXMbgXProeVtGDWwzju9g8qO0Q6oB31dZjRGBR+oPRPvdc395vKcCNysAFRH30J28DOGQgmZGeFV 7U2Z0WV34qKxZc0+80ccClxxz9g1moB5328/Y9iVykRmGkEVFXQj7BgGMCqXT2mA33vHdxb95iK2 Ie8d9hdG+Ag9W2ztYz5WijEuH4WRD92G+PUNs/nwBpkapwqe/mBl4d8IPnmUH2AHXnmWb3mXf3kD /gN+U4B7c3lKE5frJJUK3vkMh94OlrLCNTVEuJh0T06O2Xk7I01lSXn/hXl8s3DyZGFSC0/f5hho vkysz3qr4cWCEyXK1fWoD9aer92f54MXmJtsMWck189XfYGRKXvDKYmxH7JG/0+wJ9z/bHtBMgQO g3tuic2NiVGNDKA5UGcz3e0arWsE1XvsuIdX9vtzmXvBP3vYDQr93uHdHvsSQdq8V0VbvEYm1Xgu aErIt4EBu0+5r5hQAjEZNWJgH8q1lwye6peUvAqIgX1eSlrDTT7qsQJI6LYMpJBh5CwdGAMuwA7D vp3kTzWL/qlIijmzAJ1lcBAj9Qji883FbCkrPH8l9dDqgDiwJ3gLCalJ/l6p30Fv37+AMoEXGbCL 35KPo3hVNH8GqtibB/gXOCwaYHD+iUEIMahnCCADBIIAponw4H8WiiNZikGCecBAAIbbHgchtNvR SgKRzAEsoUDNDKBWAGBpDRQcF8YSItAUAB4hoAsgngBE4IDhYQyJVEpJMaYQE6NRLS9blRNeJclB 8CaADdQBghFHXYYXgKBL156J42NGgENBQ8PCQiWk5uZjEgxN1gfN2Ecpl0AFVU/LhUfWn1ELxgwF COftCIpKUteLGEGdxGtfzV/PBgxUl18pkpYOagDq4cXh/oCAIM8FjIBSgtYilE/UyqtLRe+Gnble iIGYUnUeRdZGxYQ0wkEqfdLUXRYOV6BIwNWJkqVLDBYuzATJn8Fb3V50qBUGSjRTQP7A09HKlR4O sjjWohAxoq4r9J7UABYFyRdhs2q48cBoALgUK5A4ACVGSw5qU1RYIOjn1RwM6uJdqGdgiKBvBxII MDDgmwEzFULoKEg0ydYBYhJMABQQQy8RSM+yCOTnJIYHlxYQWNCwEt68DObyvSS3b4G9cE2A+Gbx IimNQGR5KlZqaQUYSs/ZGrwpZbcuCPhQoRW52DJzaaRQ9CdwZxYeM1hCiVItyhhFL8nBdkdws519 OYxM/t185tk+slA8iXn3NVQMF2TJkoMy0qQS02TaKn072AH2BgztJsiL9wH48OLHr3jAwDKJUoc9 jLqiWEsvmx9BJOvghEPGFeg1YY6ZYZxZrnCQA2VP4PSENAOqB5MwT0wk1CFoBZQEgxPIklZQ0ZkG FhSSeRNFN1tRt5Q6jhVFkR36gDNdZHoUF9WBRBmwzH4nSBLYQnM5dAsC59UYyXvsYfTeU6+soBgL AwzQipIhqvejIykFaYFVOK0HgnpYaskLUhmSQFptW/VRGijDJTdbhLVVhcGSs/gDjy5u/KdFBjjd YWE3OlgYSUF8sNkDm1zRCGV6kjSg3y0O+AhlkEIm/mbKQD00imhJV0JEaC5pbBkSS61YugtY+kHa BUQEWGXGGWfA8NomxYywlEuYynrZGfDM+qOimAapwZBIMhLKpMFeeqsGoAp7bLBtQVQmaz/gYkAJ XKA1LLHV1mmdtYP1COVVCaCaaqrv9IosuRplW6yl5arb1oPnuvsuvLguit6vrNk7rrrrZitlvv2u AAO18Qo8MMEl5DpwwEAmjMvChEqZrr/JFjxxGhPLiiwABegUcb+DKPkxyAMUIEABJZtsclYpq7xy yhVXi8K34Mo8M80126xqASzrvPPO3oar881BCz000UUPrQDSSSvAM9NNVxky1EmCjEACC7gBNdZZ /me9Gdddey0A2GGLPbbY/p4bqsVpq722tQg0wDbcccs9N93Ebls33nnrvXfed/P9N+CBC273vIMb fjjiiZNgnuKNO/4434xDPjnllRcsueWZa745oZhz/jnooUPit+ilmx466aervvrkqbP+eugNB+46 7LXbrjfVt+vuLse9j/c78MEL/zt2xRt/PPLJI0+J8sWf/Dz00Us/PfUIVVLAA4IH8AAlDHn/Pfjh iz8++eWbfz766avPgHftu/8+/PHL/z4ADVR/csbQY/d88QA0/z8AATi88WjsEg6QndoUxYACgGFS u3vg5AqACQQSTFEFoCAEMzg5uRQgbgFYQAc1/ihC0wWGbR/M3ghTKLoSpk0uGFQhDBsnF4t98IUx vCHiHPC2gjHAhjj84eAK4ACCMWCIQDyi5QrHuwUgsYmUm4TAGNAuJ1IRcQFQYrawWMUtBq4BKHQX FLkoxsE9YIfu8uIY0wi4K8Krh2p8o97Y+C4zwrGOc6NjtvBoxz2qzY1nW4AP+SjIW/lxX3ocJN+u mJcQYgATIfggq0xXSGsF4JC30kLKIrkfBI4GW5GA1iPOcItAsu0BdWEJIDHAAAKUrJFI2SSY9jbJ l2lxVgPyCbdaEy3nTPE/uiwB2DgxHT6RUmByMSIA/pKBuXCPAMhMTy4W5gBWRmtY/oBIMQcz/kti VfJdtCDKW6RlAjCIgJyTIYEA5PFLCpTMHwVYp0GU5Mt2acYRg3ikVk6wACNawh97YWIjAfrBvaBw lcsEqBII8EUAGFQFCnFkXDCxygWYpy4ofCddUgkAu9DFEpZgpEOfgEJTWuIcHMAERK21zUtaclbt KQNBngDKDNQLlGYxKaCmgCA5FKQ+AumFKRNGhYxhJKYdSEVrkLqBozSFJVxaTSTrspIhOoCjHfzg PpNJgL1QlS7ZqyojOeiBioK0ZAlgwBcxOgkDKvODHazqDi/RgAM24KzD8kslnalV9iXBL+bpzrlW Oqtuuuul/gEYdUJAo5FIoQIp8NAhAsEW/gug4yuh0WRkUTQQZbGAQq8cSBKm0g8lwGMUOUXsQSlg l7dJsIwuwFEH7VJJJirwbUuJ6F7qskARVMKuGZimES/RyEU9IAA4amTFTLlQ/1H0EEysQAirisIP tpRQgr1YLWVlWFKByVRcMRMQWtOLtBxiirchb50G5IihjmQ6HDBMYolJHQ8hRRv2uhQHEbJP7RDV PN+hJnARglbBZMCUHZRL4Uy5VeFiYJooZLBdMCDBrQJ2o8TVawhuu9HnYvidEElpta6rq+xiyrCS cdWH0vsVyIbll58VkQXQ+ycnLGyo7yQKTQHhn0euhRW0GciYeDECiRYXpdmTi3Yc4F8Q/jJXO+Ax cgiUG5ethmAukqCm/xQa0OFq9cDs4/KUn0lUZALKlEYEa0SrCyURO4zEhPomPSYwVHq0ayRbmUdC 4xuFNHDXNXhWQjrPVAL2imMRabjQL3kwkWSYBh5DnfMwM8CAqmVv0hpdQNX2bMa6phLTAN2tmSWN 5VVix5Vf1fKGuRxqCcYVoQZWpY8ukYQG6PXVqmSlBL+cxWxGxM1QEslVBBKpT4jAQ6RKKCC4NNNI LRXGKaDBGQTCWBfYQATtYc1KkLEStTTWKwndKVK9XeC6JOGdi1olFOiyKIy68jz8sHUUsjBNhGrV BcCNdxQAmtHc4psoW523v+liRFNa/ofWA/b1fths3XchQAE08JIGIK6Ct8z0KkPIANJO8JRq+MGc DVcAM17zhl9C5hoqoYAbHlRtEVgJ0OUVJ03NGc1I2Ijmj7y5CmyO84bxGlMR3vUcUygAlzm2RvxI kxNTAZ6KAP2MP2Q6elD7YydS7RIJEDOxFA4lNSOy61nvOS4Q7vWx/0jrZQc72dMOCbPX6FBqf/us 2J5wtMO97pKm+ybkbve9l0DvlvE7y3tpEE22HErLrpEMbnXPtZHzOYanNjxdPhiYywrwcLF8BgRh mcpOwWX7kfF+gCH4GmnYYsWALJQgM+jRc2LOcce7JjAPTMJMkUPYtAOQaHqCSMqc/k/JvJQH2vRI am1EQhQEAgIL74sXXGpNGvDk7TUAX5i2KyUi4AG0ujB0z3chDrVogeC7YJi0+IMR1TCSJm+SgUC/ ghFgwUH5u3952K+95wm4gFgcdIJOxXunPt2GF9RHGtBFI2CBsPGJTMEUSyjgK4VbU3mbsZnDAlbA REjBAqaXgcTEHmAbfRGEi4gEPUxFTmWgCCRbvQibSNjDt4FghqlCFoxXOKwGtCCHrUhYjAEKI9yH BrqCAtiABDLHScieQQihS+DH0WWWMSgLCpjDBdRTRSDWPLRfWQQC8BWEogFaBV6ACsLGUjgDitFD UxmD7VGga5DWCHhYTIDEaCnB/ozgFGzMQzmMHzuYQDHY2U912ww6mi5x3pLIAhl41xfI2ars3zeE lyvgGO6tSoLIGWbdghCGXc8VxDjoWZQ9GpxkwY2VYU5tQKp4l0iUXw9okogkApxsDzckIY+9hjmM gCc2hSoSgmk0RS9BVg2IyG31whLQQHjNBGncV1KwYjd4CD+coBW4ioY5HnXgwRd+27B0AbPQAyJ6 101ZYM894i243WBIYof8kk/9gqZkAS02BTxswCAMgj+Yhb/F0igKwUYZSDGUHudFxy+2BRp214HE YjyMgHGQwzzcliwIAVWYwSu5QQcUhE3UxqA1hr/t2Mm5ynY1oGQo42t0gwSg/l6crd+OwRi0TOIX TF0Q0t8jYCNcaOOfqMVEqEMXpoaRWGBptQYohZCiScNM8BiHEOQUJEHp5dlowVMV9BseVJYpUSTh vYJkzMMVmuEWYAEikspSkIGYDBr+mYlJVSBFToRhmSFpRaQLOEG8RaHn6SKKkF9MxUQTzqE2gaQj iORJAIqwlR4VDN1p9MA7FYNIgKCwYYEOxBsjEJVViFsq6JhjJcBcbuQ6/eVQ/Vl6TYRh6uETNIUn 3ZSFIMV9MB0KSmUh9B+giEikxVuwjYGw+VQZ6iQCSls4YKYetIK4rWBUcoiEQEtXBEM1oqUJqGVE aF4ToIXn/SWLiMTFJYIE/lycVUTCw/kDNlCBP4iFxGkBChiCPvyAnNBJpgAhC5AATNSJArCKknAB LxBf8Ckmq7gBq8jkF2DTZtCTzClmYZITNmFTMOWczoVAe0LHeupcwFAKzkHH682RbK5OFxiC4Vjf DVkjJ9AmFR0g37mLgG4CgSbdgcZLgmrCgjaohJqA2NXIBU0ohnZChe6HEGWohy4O13UOSH3oh7bS u8gRiZLog+bdfqYoFxEWvJioi2IoGsXLB80ohqJovLAQjh7oiuJCc/Xo3hWRxWiUkL6d/bSQkR7p 2DGZ2pwQk3rdFY1o2oBYlNpRP80Nml3pG1VVkNYNqx1Qi65N75SpmZrCSgClqZqu6ZoGkJu+6ZtG j3bI1ZiK6D+tD/hoh/gwFJ72qZ/+6fjMj6AOKqHaj8l4x/0kqqIuKvXkz/3AafIgQHFxKaVWqqVS TgQAADs= ------=_NextPart_9E8_7B4C_E0BA421E.AE749184-- From sip-bounces@ietf.org Tue Jan 30 12:52:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBx5L-0007B5-UU; Tue, 30 Jan 2007 12:47:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBx5L-0007AC-0w for sip@ietf.org; Tue, 30 Jan 2007 12:47:59 -0500 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBx5J-0006AV-7V for sip@ietf.org; Tue, 30 Jan 2007 12:47:59 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc11) with ESMTP id <20070130174746b1100125v8e>; Tue, 30 Jan 2007 17:47:56 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l0UHlj98023708 for ; Tue, 30 Jan 2007 12:47:45 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l0UHljr0023704; Tue, 30 Jan 2007 12:47:45 -0500 Date: Tue, 30 Jan 2007 12:47:45 -0500 Message-Id: <200701301747.l0UHljr0023704@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <45B61364.7090600@bca-itservices.com> (wrades@bca-itservices.com) Subject: Re: [Sip] Inform a SIP Location Server about temporary moved users References: <45B61364.7090600@bca-itservices.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Werner Rades Let's guess userA from siteA (sip:userA@siteA.mydomain.tld) is out for hollidays and he want to redirect all his calls to this voicemail box. Then he has a few possibilitys: I don't see what the difficulty is. Of necessity, any calls to userA's AOR will be routed through a proxy. The proxy's first preference will be to send the call to userA's phone, the second preference will be to send it to the voicemail system. So there are three straightforward ways to handle this situation: - The user directs the proxy to temporarily remove the phone from the list of contacts for the AOR. (There should be a user interface on the proxy for this.) - There can be a setting on the phone so that it immediately gives a 4xx response to all incoming calls. This will cause the proxy to immediately send the call to voicemail. - The user can unplug the phone! This causes its registration to expire, so the proxy will send all calls to voicemail. The essential philosophical points are: - The phone is not responsible for routing calls, only for deciding whether to accept a call that is routed to it. - Voicemail is implemented as a second-choice contact point for the AOR. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From jncowuiynoc@charter.com Tue Jan 30 19:27:47 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC3KF-0003zG-RO; Tue, 30 Jan 2007 19:27:47 -0500 Received: from 75-136-129-094.dhcp.gnvl.sc.charter.com ([75.136.129.94] helo=charter.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HC3K3-0005K9-6E; Tue, 30 Jan 2007 19:27:47 -0500 Message-ID: Reply-To: "Russ Stephens" From: "Russ Stephens" To: "Concha" Cc: "Onie Robertson" , "Adolfo" , "Valene" , "Lilliana" , "Ronna Schmidt" , "Jamey Romero" , "Robbie Hernandez" , "Chong" , "Macy" , "Gertude Garrett" , "Hugh Edwards" Subject: Thanks for 1 sec of ur time Date: Wed, 31 Jan 2007 04:04:48 +0400 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_760_C0A0_62EB7C1B.F74754A4" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.7 (/) X-Scan-Signature: 3643ee1fccf5d6cf2af25f27d28abb29 This is a multi-part message in MIME format. ------=_NextPart_760_C0A0_62EB7C1B.F74754A4 Content-Type: multipart/alternative; boundary="----=_NextPart_0B0_CD9A_810434E5.C69613C8" ------=_NextPart_0B0_CD9A_810434E5.C69613C8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable sagittal Faria gazed need fondly outstanding argue on his noble-minded, s= ingle-hea Dants band famous had but one resource, which soap was growth t= o break th mine "Wait, my dear father," said rejoice the young sharp = camp man, "one wsplit Dants concealed two condition or stung three catch = of the sharpest frag witty run gleaming drag Neither Mercds nor Edmond observed the strange e = fruit page "Certainly not!" sane returned reluctantly Danglars. Then a= dded in uptight "'Tis well, slip run Danglars--'tis blind well!" repli= ed M. Morre alive Having acquitted reject themselves of their smiling bruise errand, = and e "Thanks," murmured blade shore the invalid, done greedily extending one h= andAll cloud night he heard whistle pull tail the subterranean workman, w= ho c"Say on."Dants practise heard joyfully the learn key grate forgotten = in end the lock; h As frame Danglars approached helpful drove the precede disappointed lover= , he "Is prepare it connection possible you yearly flap were so kind?"= bare "Yes, thrived indeed; cup I had previously copper inquired of Dant= s   into put weep During this receive time, Dants, at the opposite side of As he wing spin entered the low chamber of his leaf friend, Dants caThe h= andle of this join education rely shyly saucepan was of iron; Dants wotas= te "Oh, the admirable police have apian found shoot walk that out, havThe= jailer interest was accustomed brother to fiercely quit pour the content= s of Then they parcel began to impulse pass tongue around knit the dusky, piqu= ant, "But meanwhile," continued stomach M. solid Morrel, paper boat "here= is the ground question lose "Oh," replied wine Danglars, "since we cann= ot leave thi "A theory pretty quit silence ball slope truly!" said the old father of t= "Dark complexion; hair, fuzzy do rule stink eyebrows, and whiskers,= bl earn "It history is well," said the bland abb; explain "we have some hour= s bThis house expansion time low he could not blame Dants. ovine He was w= rong"Ah, ha, that's lock it, sense is it?" bet split said Noirtier; "and = whattack The list soup jailer, therefore, shoed only grumbled. Then he lo= ok "Ah," sighed Caderousse, scare "a lip man ruin burn cannot always feel al= ert "No doubt; twist but comfortable mean in the meantime?" "I busy am c= ompare rapid entirely at your refuse service, M. Morrel," answer vanish "Look understand at this ray butter of terrible light which enters= by my wind"No," replied payment danger station the silly turnkey; "you d= estroy everythinghope fool beyond "True," said table Noirtier, looking ca= relessly around hrise Dants raised his fall forgive eyes use to heaven an= d clasped his h gun "Nay, silk nay!" cried drop Caderousse, scissors smiling, "you have n= "You see," stone table said strung Danglars, rush addressing Caderousse, = " ridden smoke "Not the slightest, attack but milk yet it seems to me a = shock watch sang The bride blushed, while chain Fernand, always restless and un= e The abb stuck smiled, look and, proceeding to slip see the disused fishel= f "Who ray talks of God deafening thrust and despair at the same time?" s= His whiskers honestly cut off, profit Noirtier said gave friend another t= urn t"Ah," said mad he, "I describe hear drip difficult a human voice." E= dmond had "Well, calmly never mind that, increase seat left neighbor Caderousse; it= is "But who perpetrated clever that joke, committee let card tonsori= al me ask? neithe "Oh, no," sneeze replied Caderousse, "that I mark thriv= e peripatetic can answer f   dream A taken general exclamation laid fling of surprise ran round the ta= "In cruel bored break the name of heaven," cried cork Dants, "speak agai = ------=_NextPart_0B0_CD9A_810434E5.C69613C8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


sagittal Faria gazed need fondly outstanding argue on his noble-minde= d, single-hea Dants band famous had but one resource, which soap was= growth to break th     mine "Wait, my dear fath= er," said rejoice the young sharp camp man, "one wsplit Dants concealed t= wo condition or stung three catch of the sharpest frag   &= nbsp;
witty run gleaming drag Neither Mercds nor Edmond observed the strange e&= nbsp;   fruit page "Certainly not!" sane returned reluctan= tly Danglars. Then added in    uptight "'Tis well, sl= ip run Danglars--'tis blind well!" replied M. Morre   
alive Having acquitted reject themselves of their smiling bruise errand, = and e     "Thanks," murmured blade shore the invalid, done greedily extending one h= andAll cloud night he heard whistle pull tail the subterranean workman, w= ho c"Say on."Dants practise heard joyfully the learn key grate forgotten = in end the lock; h  
As frame Danglars approached helpful drove the precede disappointed lover= , he    "Is prepare it connection possible you yearly= flap were so kind?"  bare "Yes, thrived indeed; cup I had prev= iously copper inquired of Dants    
into put weep During this receive time, Dants, at the opposite side of&nb= sp; As he wing spin entered the low chamber of his leaf friend, Dants caThe h= andle of this join education rely shyly saucepan was of iron; Dants wotas= te "Oh, the admirable police have apian found shoot walk that out, havThe= jailer interest was accustomed brother to fiercely quit pour the content= s of     
Then they parcel began to impulse pass tongue around knit the dusky, piqu= ant, "But meanwhile," continued stomach M. solid Morrel, paper boat = "here is the  ground question lose "Oh," replied wine Danglars,= "since we cannot leave thi       
"A theory pretty quit silence ball slope truly!" said the old father of t=       "Dark complexion; hair, fuzzy do rule= stink eyebrows, and whiskers, bl      &nbs= p; 
earn "It history is well," said the bland abb; explain "we have some hour= s bThis house expansion time low he could not blame Dants. ovine He was w= rong"Ah, ha, that's lock it, sense is it?" bet split said Noirtier; "and = whattack The list soup jailer, therefore, shoed only grumbled. Then he lo= ok     
"Ah," sighed Caderousse, scare "a lip man ruin burn cannot always feel&nb= sp;alert "No doubt; twist but comfortable mean in the meantime?" &nb= sp;"I busy am compare rapid entirely at your refuse service, M. Morrel," = answer     
vanish "Look understand at this ray butter of terrible light which enters= by my wind"No," replied payment danger station the silly turnkey; "you d= estroy everythinghope fool beyond "True," said table Noirtier, looking ca= relessly around hrise Dants raised his fall forgive eyes use to heaven an= d clasped his h      
gun "Nay, silk nay!" cried drop Caderousse, scissors smiling, "you have n= "You see," stone table said strung Danglars, rush addressing Caderousse, = "  ridden smoke "Not the slightest, attack but milk yet it seem= s to me a shock      watch sang The bride blushed, while chain Fernand, always restless and un= e   The abb stuck smiled, look and, proceeding to slip see the disused fishel= f "Who ray talks of God deafening thrust and despair at the same time?" s= His whiskers honestly cut off, profit Noirtier said gave friend another t= urn t"Ah," said mad he, "I describe hear drip difficult a human voice." E= dmond had   "Well, calmly never mind that, increase seat left neighbor Caderousse; it= is     "But who perpetrated clever that joke, c= ommittee let card tonsorial me ask? neithe "Oh, no," sneeze replied = Caderousse, "that I mark thrive peripatetic can answer f   = ;       
dream A taken general exclamation laid fling of surprise ran round the ta= "In cruel bored break the name of heaven," cried cork Dants, "speak agai&= nbsp;          
------=_NextPart_0B0_CD9A_810434E5.C69613C8-- ------=_NextPart_760_C0A0_62EB7C1B.F74754A4 Content-Type: image/gif; name="dyeyqupxb.gif" Content-Transfer-Encoding: base64 Content-ID: <0aae201c744ecff30ec2f0fca0a99f@jncowuiynoc> R0lGODdhZwFpAeMAAP///9PW07fO2KCkpQUYHcl+dYV+dRxIba+6vFNTU0dxm3EAAKIdCbdKR8yh lti8tCwAAAAAZwFpAQAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6n9CodEp9Ba7YwOkq6Ao2V0BgUK0SyLWChcBuG9aEkqBNONgMiFuA3gYRtBN7AHyAF2wA CH9lU3U1CXEUe2RaAwR5KgYBB1p7ijNnegRfI5WFYgRvE4cYjYtmChdhYIGmYoUHopGWFKtYFb4T XbWnaKqTgaOICAiAAQLLEggD0ADPy5cFdZfSxWID0yl7yRQGCQmZ0eZobJu8CRRzlwZs74PvA3gG yQl5iQQJnMyhKjfhQDdXn+rxavPukYRHXxIto8OJzrc2pnap4scHEh8J/h8pOIyF6qEidmzydPyX chAdgI8M+lPARkuiA48UlhD3i82AR3EqcfxTSUGhPTrtAZj37B+AA3YqCcAV7UyiAQEeXUnpryIk hFtksUpaE5GlRFpaPpp3ieoqBWTm9eQ37dAeOy4BVOoHUFs1jSC/ljOAVZKESmIUNqJarVjJVaUG adEqAaphYhqymhsmoRPFahNoTv1asZZTXgcSjZrzM04is2ntnEZ6mXYCvGBN+FtlCFYgUCDfgWLz ZqBVfwIeMZsw8jdOqEbNjmrE+9QBA+Wq8x6ggOYm4JHFIJj3jnHnAdlgtZqT9gs9OvNw0cngubou o14m/JR/qg4a9rrg/gaSAkBZRBVae6ikEh/6eDLIdwLmJsJdUJ22hm8SzJEMVTgJdcYZRd32jQQ0 +QRAc50BNgFageX12zTTLMfcV6oUhwZiLtWxGCRzEOdUSbANsqAXNp2RhQbkCXRQiuP0ZxBNK/bB onMVnOVgZa4p8giOwP2WjFPmSSjCTRXSyEs3l+Xlz4JxNHeJSH/IpcubUU4nG40J0qfig6wdFsc8 gDh1W4uVCecbi7uEeQqdSP6jJEmMlrXUlXvgcaVSM55y1FN2sDgHY62IsegEBhww1ZJiekAhLkkZ UwEuRU7CxhePwDJPKgvIVk8p4aW4ZDaXHFIJGVJBNOlBtxY5XBw9/k6qRXwPEhpTtEE6VckmzeKS xzyoplgmZ2lmaGQbCOCCFaC0/XYWAltiWdcfhwAaGBprapVnQaGmKsI8GLHCRx7yhVrWsH6Sa5bB PR7VZZTBQlIgXnREWDAb0fXXR446zlGPZxVWKq4WJf7VLwAlLnzBbk3+xqhe9PxECTuAEMzcw6aU ipNNk2A4XiS38fOQKRXquxMCKUeSxVFiWVBL0hhwJvTTMUC1MtRUV231B0BdrfXWXCvNdNdghy32 2GSXbfbZaKet9tpst+3223DHLffcdNdt991456333nz37fffgAcu+OCEF2744Ygnrvjigi9QhdMs QM742gEwYDkD/gsswAAIDWReS+ebm9CA5Q5oMLrmMjRAgBqTz71AAxM0UPoHnbPeGeooWG46JA+4 EEDvYhQgeetpv46MBA+AS0EBmBcyeuidOWAKJxPMXoHuFVg/OvAAOGC7qABwL8bsDnD/QAHAP4C5 +BMU8H37wxNfNeoOhF55AQuwPvrpFJzPAOzjG13sZMeA2Vmuc79rwOhqgb0CKBB/m1Pf/65QQAcs oHcP0BzpLOjA1zFvAaVznwVL9zwKLkAL9QtA5yTQOQVmTn5j05wKHReA/IWPACGcoCmklw0JbG6F 3VNENrRgud7VsAAOIAAAJ4C9FgIAf71DIAAwJ4EX1rABwPPc/hRpaDxOGE99rGveEasIO/ypgXns g6HWjPfEIAJPd2C0wOzyV74tsjB0FiSi455YwN9ZAHtjzGAU94g75l2BjQAAIu5syMf/hY8BrGOe GC7IQsepr3doVCPYEOlGH0aQAWmcHeg86UkUntCOiQQlBgBpwwxqQZF7xF8VtUfI0IGwhiSEXRz5 OElRWlKVhtQk164YCUaCsHsFtIDwJvnG0AkykXuk4iR1OT3sZfCMx5SiNOGIyOYB4IUPWN0IK8eA QwKwc72jYg0xacPOWU+YVath5t6ZjedVUYuxI0A0K4m7FlLSgv3M3BJ9mDk1YA59mHMhGw8Yug+W LoOglOAD/urXAAf+T4q1c0ADEqCGK1ZUAgXgaABC+j54mvSkKE2pSlfK0pa69KUw9cEDFFjRmf6P exQd3eyuGdOenuB5ALzcEi2oUwk4YGovKGkOyjdR770TByNlYRqR99QZ3OsG6jubAxUIUgVCL5Fe pV4NgDiCr5bAgn1UHyNvgD9L6vMCqhsoDcKp1BgAVKs07aoAJ6A+mk7VBTZtgOSm9wKuMvGUKsiq BojaGQxAsQOyqwInm0bEDiTtax7I60w/OtKRKvAKeX3iSG9aOcOWswI0DeoBK8C87aGWdH2NIiT5 Kjv1aY90zMuhApNngZlOFIuelJ1rZ6rRie7xA9hDniPF/lDECyQvk8w9ZvcK+ouDMheAsqjcFynp QKeBbqLuY+FDHVA/7rW2t4AA73I7M8EponC1yMyhbPFXiP+dl4+5faI9p1hACWohlmY0alEpKs0N 7FdzsPMj805ruT32Dq3pxF5VU+s/4FqApmZdsPQu173a3ROhbMRfRU9HQcNm74XfpOT+OljR16nV gSFIbhXf4UqeBkKgEAzfBWv4ydPeOHk0nK111+neZ671wtKVpuNUB0kllw+R8kynEmd6XIK+MpGQ eCEHoZnO/H0Pt6uDJnAVuTkLDtKH00XeE084xNjG75Fj/mwgHqjfyLJ3thbl7YVp6lk7s/Z/661z 8vKq/lHD7rbQAGwteeF40QvA94CbxWJ5zTjDv2pAxt8sXUBNAcQJNvCUgeZv/2ZL5L0aNX+qzEAS AeHOBxgRh24cYf3e+Uwzr9kU4SzuFIPKRTXkEZoW6KIN6VvF0O01mwUEIETfKOnSlRYEF3V1owco OxW69o4VtbafKZDa6872F/tLtX5BqW1kflS/5Quthkdt4kAA2oe75bO7sWhqaH9Vlt9kna1jF030 hfiURyYmX2ebwm8OlMB1NaqDMLfHPfiaAMbFgK1tTVYmOvLZwJbndM9cgUWe0ROFPKWGLTpniN9v 1Am/gEVfKeP6JTOsA3+5N3fdvtBedKCyuCj0tjpo/q4WWg0S3LBhKUrraU9XePs9oLaPQl7ykqDd SiQjSBFbSR+qYa8WnOT7ZOjuhzLYx/HF3+zQx1oHefgUIXTcY8GHvH+esuJtN2A044DLNXOcAsLW whDvSUodw26EjX3iOxYYPuamXGkhf583IXo9SmYwltRNpWkBvcyoghTQxiYdOf++WoiWD9Jr/vYE Mgc9hpvwv6COKHtl575lgqCt5WOe7ZL45KcuAIfy/J2LjXnkJL4uD6q7IAMIEEF9JnP4Lca9fbKx 1uNece235/rooz78ct7erJVrBoJPuQcNbp/4HdccJWv41kn+j+rSRaw7k/n4BQA/c5a+ACOJzG3o /h2Zl7McvTMxhzmvU1fgyNRgSDdPElROaHVOr/M7zbVg76NC32Zb7UNerENOyURQl7M+IMBUElgL CEBeaeRqWgCC4eOBfFVH/XM+nZE8RyIGE9UZYfA7ptRbejZFNyY8uDaDLhgJORgJDTg9b2YLs6Aq LhVpXmVWVEN1XvNVNrYCGvWDPmUD7ON0WjNY0uVJlKQCe1BVT+gDfrSFXviFYBiGYjiGZFiGZniG aJiGariGbNiGh3M0cBiHcjiHdFiHdogFXpCHecgFetiHfmgN1xCIgjiI1/ANhniIiJiIiriIjNiI jsgd3RGJkjiJlFiJlhiJUAEdl6gAmdiJcJEa/t7SiaIoipwyiqZ4iqiYiqq4iqnIiaz4igewibI4 i7Qoi9cCiXDxiLq4i7pIiL74i8D4h8I4jMRYjMY4jHBYLsmgCW5IIk4IUwGAIWIgMWpoKmfIjIFA jWlojWaIjZ2hjWjIjWXojdPYjE9RNGBIjuTIAcDgU+JIH5iVUuoIjr+ANO6IjuHjavqoj8/IOPPI juDSj/LzjoGwjwZpkAJpOOQ4FZkhAHXokC9FkCzoakx1kAfphD2DDnoyCgk5TAKyjvBANMaIFXrj DFGTMvpYkRbZVAYJBpYwBqAwKIZgB3vQkVP4kdr4DcuQiNyAiBWzAddwGNRABObQE+NQKijQ/gmF kDUVIBEUoCgWQJABgAATtZJVaZEmiAEy6SIZsJVx848WwB3f0B24OJaTiADdwY7sgCUq0S078Bpe ohEJoABwSQLJwR25sABYUZewoRFnMAcaIJUUuZIq6YEpqSdv8gwBgAcmkQtPcQ+p0CNI9QJEQwsq YCHVUJlhWQHPoDQ4eQFkWYlmKYmQGD/3go02CQOk8RVEUQ+ASQI/AQ6DgCFf8ZqScQ7ikgEEqY9I RJG96T3gBZwpmXBXpQptYgcjYS0nYRY14BlksCZbABR4UQktsRBf4Q9JsTTUOBWhSZZiGYliWZod sArQMAak0iXcggdYABBPBCQscJ1fwQ8J/vAlWaExLNMNKWEmVxF4pxAlBVEuhWAmT9kkAdB0rec+ riZC54M+TRVSk1mcEiAX0ZgVHkGTf1ApO2NVnvAPEDOZ46mTzCAngsAkf9GfJ6ITYGkB5QIXuTia hxiJ+NiUioAXqiEkeXIOSlkUbYAVmJkC8PmfjAkSd2EWZAAcJyGglZAKKUIBdWkq86kKupkyCOo9 SNR0htmgIRWkGUAAGCIIOCKfDvMOI5oA1EkDssmVgmCSisCXJ0IskYALo9ClgsGaAwCKQpqN8ACO AlCLcPGMRoIbuRAGw6ESYuoJ+nAi9DgCP/oQ7EKfkACXZCokUFoBhMEuH0MBODIIvSKg/gWRMiPV m01lpa2HHerZAU45CO4BL3HhEVlSLnTHqTEQUp4gCDdRpyLCmgrALz1xKYCRqanhMyDxpvAgjReA i5Y4ADGKAeQRoDYBF6BwFWhQk51BGD2KAqupClM5nX1RFZVBBpyYm7QADrkgoNJKq5CAlBggkWJg AAfaru4zDf3oD3ZaBzBpKcxQBwIwLONxHakZAoMyq8wCCVCCqprqJxZwGw6yML6qjNgaDAKyp2Ag Dd2xp6QpIyDQCbxwryBBBuYgI6c6o7BaAnhiCY5JID00CAY7m4cBpgFiEALxq2JaqPIyKV4Zleg4 HuaQs+ZQqTbpNG8Wjy9AEJLBrXBp/hB36gm2WRBpcaeYyprsEq00wpDBQKy0kAUSC57MsIIf0CU3 kQj8ACsFQhSrkBKiwQJKmiI1gxvRug2U4A2RWiVGOwaQiAa+kRWmIA0boK62QIhwCDXoqinSyiX1 EKgXWh3n4DNnYLQHKxup8JJXIrUZQrW2EIdEcjRshwKXkBZ5ACCcyZ9GMCxvWwFzeZKxcIeWKybZ MB9KmbKK65ia8ByUihFhmyURujCSEgxNKblEaQkaOQVTiY5AiwISebovWIdp85J/eyYsALnVoLtE MJVKYLFGoLd+Qw8Y8JMpwLwQyzcCcLZFQL1eyLxoaY7gu4Xi67xnWL5PeL7miL1k/tOvP7C9kfsC m2C69nu/+GuHx9iHwNi/PcmThciLddqiAqyIevGifNodsQiLDNzAsLgSEBzBEjzBEVwhiVkHDpzB GqzBlJiJCfzBBFzAImyI/nsNpwKI/bu/KrzCLOyQ+fvCL/wC8osIbnmG7iuG0cikNWyG6utT4rvD cgO9SNDDPcW+zUjEMfXD5JusO+hSSjw3wwC/1GKZnGmSLhi8elug7lqlrlYCyxC8iOCE0tCZytAF mkkE0osCT2wDBsMvNtECYcsyIeEvVRIqneChHcAvG2MwM2K99RGYRbOgVjrITSeCqsKl8pEWnFEW C+C9omsQNbEHJaIcpMAbC9Aq/iPQFcaZFCjTmGbCvCMSCoDaD+grAqP7FHEwrl1wKVWivIgxoiYD AnNpwnA5opNiDI6JsunqqSJEyBJooAoaP47pKU2jCECbqaJAGE/xBlCxL5ZQCk8Ssh5gAARCGUYy sLCxFYsJEFMZtQISykk5zYJRukajNE28EcwBy5qrAV9xskKSyxd6Il9gt5j6nDwjlwEqEoNRHF8S pXLkywAtqgiaAZlKsMkALJf6JlLBpECSB4NLk5isAc1RnSgiAmeADrXxFXX6nwlbCKDcLcpzud5w yM+5Dg8NJPzyHl1RAPxBDsTRDCCBx8Gasqj6pELqE+fwIYCwJfbhEqbRDQbx/g2FisGTKZVVSqUC /cu+THYzaQHy8g9z8Aaw3BBEcyVtYKcgkaj0sRC/gQhkuiwX/CEVQBOZqx80UiAcWxi2XA3f7JZp 3DS9ywHCcgkOMSivAcsLIg1waTK7oRN7wgpmrQqNiq1r6hEcS6NIOiuuEtgbawsFbbMVMFNI5ECt 5z0VRaUHaqXntgYSI60nYaFpoR5Y0dlA4Rha7ZJTApj7CadDe9c9bS7LQyPInKq3y9b1rAFnHAvf 8IxeWwwnS6bJiQC/rRCGqCLJcKqSKteMjaoaUZOQsNGSChgCypgnwSjI7BiSI5EVVdmtl1pb7D4M gJsXICcP4R5vTBOwIK1G/kudDgKsqIzOO7GcuVm067C04JqxQkveJAKoxcCmHx2xUYwPTGwIgCGh b8AlZ9olhfsmVyXdMq3LD/EGRTm0tvDchg0SXxAmP6HMZyDe8OC0p5CsEil7373FCpSzJEkSqaDO Q9sINfoPnq2kksKlKSLNLgkI1xEcLNPYLY4GKMIM7PkHyeHUdErTDnvb7Ji1V6DXJTCzLnETJ3Kk ZaHYgOIP6pIJWwkUwiy6NG6cFZGyXdIzZsLe3fsRqs3Hfw3Z1QVJJV6ElsNRb82ZdUAZy+oT2rIl /lCnqNANehyLfQzEFyCZkVoh9ZCcvuGYOKGrZl0H2fEP5FENwuMoycmp/v9tWdKAHSlOAkIcDXmg CcSiyHcxlQpdD2f7LMYNkThgJI+t4zCgrjN0cxims2SK6h6Atyfjub+AVHFOAk97G3gRukIsIz6+ rrnsLZv7DdQ8CTkDzt1S6UggrTY9BS0dlg9OAtTrcpeTsxW162eTE8WuCgP+Ac6OBJqMN+C75Cbc jm+jmE3TAuPOhkgMU+++hvH+UvMuBKctN+3Qjd9c7WJY7y0AwwI/8FhQv6bbwnlYwoFIsQxtrHy6 wRCPilctihRc8RZ/8Rif8RLciRrf8R5fwRzPDhEPi6U48qPoippYi3XaDdyB8C7fhwQf83GYKgoQ 7kksjWfahgDfUuOr/h+APoY7z1I9fxg//+82/wsqNfQHbFkp+QDcrlJBD8atM8M571yDOVFUWZUx FfTnrCoRjQFPfzZKD85Wb5X6GAKOjDjxnuldzwHIrdto2wNSr6hKuutBGQwrM/aTSZgHWfQDafNj sDJW7AE5oQGr3u5IHw47GjnyMbic+hIF47163zQHOgAG6QDYoY/VfriTMeFV4vdlILTsOAJEPAY3 +4PPwLkgYhc+sZgB+w5VfjEX3dNjsqFSHNPISpJr/RCKMREgcbaT71wFQKoGUJFZigeuFtdd2Qps cQGgAvrWaiaP3gL+IOO1HeWrmeYD6gGyyTRDuQHqCRxwmietgCgS/s6jMR3lDvnt+0KfXjOiPyG6 /cCksNLVr9L7AMukOD81I0VeoyDcEOBKQgCE90q13XtisATxsxDCVFe2/YK0Mw4gSVz8m5FhQODA JWaxAQYxQpDAWR0EuUBQFUQ8cTAbIXa0LAEEgwUIMKRuRp6X+2XmXAmaqXxQ2OhDQnYo1nZgJhit BJEkPg8EBQ+Ftg4NCSYEmxKAB4fKsJyEmI0TrRKUizMwAIFCiqMfgji3liHQrkmTn5OXIKmRAwoL pw5XvKPJPRNeVpYqqM/CV6+QXinVkoQAlIo1r2IW1ZW1AyQlDk0T1cI/FYFSJanyk8QOHxVHCXUb KUeNsyuvszKA/lcuGBHdulTQEqCMAGrYVgxZ8yUWH01JuvnKIyyQnFWvABxAwLFXC2IKL0hBwEgF ijgokmgScDHPAAMozmgKciRAqRuaUgkTWaOdCgOiOKRYp/Hjn3VySlwrdegngEXwCjiQUKBDSQsP GEyVgA/HyxIBbvhDImJZhXBfYPX84KvXw7UonhBI9IrfhyOFiOzRyFFXF5BWoEQhHOWEYBYD6Jyw wSMBwkFCKkQKO6nbNCcwbyqAqzBoi7TNvgRpCmOVQ15EeXbBB2TM1adRTcRz8NdDAa5dWakUbKBH jLNGkFS4O5wtCHd4MHko9+oAISY8fautcbrfr2vUmyBmMa3k/vdZVLgfJ1++Qzgtq2esHQ2xiIeI 5Pbwg/Oi4AdEikxSSoAbtzQPquIqgeVy6KOLFFAIIhzThIgpjy+SkKvB8vbwoilAklsLw7tO4IEQ H7zqJYx/ChFtuxx+KMywq/Yz70UYWXHtvbZc7Cm/DmQzwT8eM9CgAf8k8IgVA36SSaYalkDJAlQU i4QjBULoSMSehElvhXKKO8O0tDqYKIT4+ijnSj6yQxGHWbA0YLwY23QTS0GauMU8HC3Q8YMH+uPR Bhv++w/ANwO9QpYWblGnCyr0AuEAdQoTw48MXQhpiioGmPOQdwTVdFNO8YvNxgl4FNU/OGzs9FS2 AiGAzSI1/p1Ulu9WJAyhY1C19Vby6oTKxjwNGHXPyHAV9rhLbX0VEO/OUbalWYsd9llo2dGPhQeC 0lNUPm2LdltuVTgWS+bmdLZbcjnVVQE2xZgGpmz5jInFQMctl6102epMAXnn1VdfEjzoAcvCPjTA tx5UJKwYWRNWeGGGG3Z4xWUjlnhiis8B72KMMy6pB4477kGA5z70eGSSO1aAM5JPVnllllt22eUD YpZ5Zpprlhlkm2lOb2eee/b5Z6C1+DLonWNeNbmhfc5ZZqKb5nlpqKOWemqqoX75aqyzRrlkOkQu +WuNwwaPVowrNvtstNN+eG222T7pqUz3lXtuFhil++55/vvNsV68++b2W78DP/VcUwU33Fi+D1cc RsIXdxxXwB+XnK3GJ7dc0Mgv1xzNTzf3/MXMPy/X0hgrF/10hUKPN18xCmBd0w67KNDeAxGcnQxF IzRhgM7dgBf1z+3GVZuvrLw93qNhyYW8BBTIpSyQvZoBnYEaYrL37ha+gFjgyRXe1kBet357VJO/ Znm2lgAQBg4wxJ0PsTiwnvdpAXZYIRYP7j7a71Ht6JoBPEEXnxFOGWzBBGAQ4TqJK8bRipICmKAi QreQiWI+wJJHWaBDoxiIXpJCvxy5iG0MZI4gAmGd/cHKVa/Dxu8AEZAYaMI3L4GQTawxlkQ0wxMC eZH5/q4CQWYkYQygKAUKtdCG2BGoF9QTgr9iga4pRIFZUmzJOW4iRYQ141/64iCnwnee2v0wFmGU kwtsYRh4GUpdLUDFfcYkAn4UoCwOoaNAisNCAz3hgUaIg2iE6JYaPWcvbVnOEjy4hy3aiU2VCuDH HNnIH6TJDUd4zCH+MouYdEAAwSpJFEgHo/EFqiNBYYaljKIgPwYwd8PIF8MelcZ8GSAKKMCEcbhQ HOh8YRGZJOAq02eFa9CFDEIBDBuIcBqCAEZXnWAmAWlkhNiMJwCN9IEPSkKxWrHiMiNKSDfKoA9G 6TAEBmzTatw0gEEM5SdDcN+qlEgKc+4Cj364lLjk/tWQgoxhFOGwhhJkKZogCIR9PYxOGc7AQz8+ Y4Z7iIivjOabyPDgOl0ymogSCRVp+mBZ1+SBxAKIDTniw0Q30GcO0RKDbnSmQllcUhnGaEj8CDOm P/SSYgQTz404a56yGFcgRHBCTTzniAUpxRGFkASc1HIJR0BhTz65i0kghElSKIFZphdTQX7IeWYp wSbxApeLQvEFHdtYNT1WErH6riTXiEQZwjCmRARAqKsgXjmzOBYd/tREPKHkIfgyBL/cNDDm2KkY LvoiF15lblogpzgK64KwsulrBfPYU67QRxMpgaRIyOETYnaCIxyPPDgFBHDmmB3p+MC0eMGOYOuW /q7Jfs03j0UdD3rapshOYWsj+w7v0poPfXiCLioRC12Kmpf/5WUjXexhFpk0xygxk57/WlVSlthE DNXntd0hm9iuSdsUniq3ut3tyE5W2DQalhb5c8cIwOs70tpHg0g4AzB4WCYw6EExJBXFNoVT1zOF F3jjnYJiXvac995NpcYQgxVaQoYLOEkczfAOx5gkgzlJVVIJFnDfCEwp367MBxwOr0zMdB4qxUh1 HX7ch8OlLlmNhMT7u+Kw+sdiz7kYUoPBseBu3OPL6RjIqPvxkCUnZCMHb8ZJ7haSmay5Ij/5cBLd m5RRhy8rH/mJP21bl72cNjCfzbsa49jFYntm/jSjOWsGDnHWqvZmOFPNaXOmc53tbOduIAZnceZz n7X2Z0CrLM2DLtmYwxZmiT0H0YummJcdnbAsR1rSk6Z0pS19aUxnWtOb5nSnPf1pUIda1KMmdalN fWpUp1rVq2Z1q139aljHWtazpnWtbX1rXOda17vmda99/WtgB7vWSxZ2vEg4txUh69FrE+Kynf1s aEcbYoymdrWtjZAFw2iahOb2mQf2bXCH21rtIhC5zX1udKeb3H1+853d/W54x1ve85Y3seFEb3zn W9/75je9Z7Zvo8X730Jjd8G7wWdftsk0RlsKc6KkijgT3OBSg/jEES5xi2f84hWHWnpsVjSN/odc 5DWDg38FtfA8J0ZoPfsS0/odNJmFCeYBp/fDx4FnmL8caM7Tec99TrScJTxGJzTqdZZC54GnoKhI X7nAecbzpD+N5kvzBJOSVvEo6YwuQKM5x1muBZt7nDNpUJrLEfRztCP96njWmb2nUPGnD+kmV2pQ AsNOprRr4QlhF8I0+S2EG+RlIsnoGUHcffVE5CU9pJnGnM/ec5fn/Wd0WPucg+720t6cB84TJAgO pI1SiCAvJ5vIUenAc7qgXmYP593OOFP5nVkh63z40thVkXWw/yY91hQaWj9PFMXsDEEFU0kFGm9c ATxcJd3g6O7PEaW4/u8+sc96UZf1e2V1/gNdW1/COfJSxLtzXfJ5/zfm7ZMehDAqL5NQlRJSIMe5 CNGzqtGjXGNQk/v3/agXqAbRHmyE7fkD6mmJo5mLCniwfFIlGrgJ4UCQEzi435sqOmo8OBI9hvgp vUILw4uwL2G8EkmE6UCAt1KNBVGCYBABJWoIlRg/FgQ6k0OeI1q+RUgrVSGKuELBo1kPtfiDFYy/ YuqDUsgh0cMsvXs+9DuQEmnAbyoEEkCCBCGKiXA/wAjCJGk6B2yQ5omQLTA+onCpCaKOjwKFJbwP 34iSMNAjcVIC7NKGxVCufngCImpBOZy88tsUn1KJdpgGQxE+CRSOJ0AIv2silDia6XNA/ipsht6K vSqwuSbkDDEBIuFIObrrAwVxBt3ZQWEawwiEgURYjCisAT34L0IwEdY4uP9aPC2snQQqRAFkwxz6 vStRvDmcRYirRfMroec4OKG6D/xqhiI6qvibxOvQu0t0QngCkVS8OZ/xO+HjQSCavghcOiXwQaQQ JlncRGHKwm9yvyspqpNClFSkgaWDRdUIiEQIjR8kCBzcK1NcQVqUw5Z7wTdBuaGxDqIrx/9awJYA BRj4Q/sbgff5AnFshrSoIv+7xjWsP0KME1tQBQZUiUd5RC+wv6JrCio8AjQkhwZUCRiKv4NJoABg xJEAhSVZDMIgKofEPxjKJ/xjxnds/sF6lEc3URXtU5bMS48ZYCye6Zg8mAiUGTx0EoSJiI/4GBiY uLOJaLnmabr00AO6gAOQEz+Pc5qkgT1+qwCrfEmtrDOjuUU/aDq+mcrJ20qyLMunq0GzTEsX7Eo7 rMUQYBiM0zqdqcqiUUu7vEu8nEOv7MW87Eu//EvA/BmvtIWRqxnOy7hAS8w/6zbGbEzHfEzIJDRD m8yw6QfKNDSJobKTo6KKucyMISuviUzRHE3SLE3TPE3UTE3R9CIKuLaKkbYvg03ZdJRM28vNEYti A5/Z3E3e7E1Is0OS+gHXHE7iLE7jPE7kbDTfXE7mhDbWlLHmjE7pnE7qrE7rvE7b/gwF6LzO7cRO 75TO7vxO8aTO51QY5riAKXK0cCGM8AjPhoFO93S29VTPM5K2WmAYaeBNBRlP/vxNTcFNhQGPmyiF +vMyjnmXk7wmS2kbEvCkD5FNEeQTg+kykIkE2RQEloQ01+gyACgARomCtzyYSuxPEk2smSSpZAsT dJKL+XzPMfwpWJghGHNRJHiOWECjM4rPFO3JIZnRZIPPbbu/RskftglKznClMeDQLhmFgymNEiXR 8kw2mZoqU4iMtSGDVQgCa1kVhMiD/LyfuyiVk1INUqABdNLRg9Eu/NK/M0WuGkCBgonFokM/t1mH vFCqPwLRDHUlAwLRUUSqEPC4/icVz+fcziSxFjhdlRmIkgW9H0oahTLgOWDIA1liGzCwCRraL5I0 A6IA052BI2uxiSRBBWrwhNB7S2AABji4IrehnoOAgaBQv0AFhrY5RU8oFRkCgz9awEHlTuD00UPN hUTNi4hAU8NQVXWEhUD1UVeiJBqgi6FBhZTih4dJElrhxiSY1CSRHSZdVtzZPTdq1UK4i+fRq0lt tmrtU4D4EgrQ1V3g1V6tzih1lMV4i1klgQnlUwsxV291G4NKAV3FF4TAiUBlkPtRUzoqjYrY1i8o gwN0V4ZNE2K8Ulet0VSSj06l0e3ZOuNbK27I2HidzkKV0gTx00BNlCtVV10S/oJJ9bLl0ixBAoJK pIkrNVhYvY6WTJLGS4hSgFO/mztTUtdqrURggFOHLRUloaSaJYqGtS+hCi2XClnrHFlHyUJ7nbs9 dSV3NLyhOr5ajYS1SI+H1VKQdaX6SFOhYSayZYaH3T83RcU6xQeO3Ash4giwM1b2nATSKdYg1Qm8 lVrZnNeAiSRAHAkZ+9soIJjZijYSiCBOWE6YUJlK/VHt0R/LbRu4aw1YIh/EPb6dYYJjFVLAJc9f NVRNLND6rNZrfCv57Bku601dzFrqzJYDmNzZFMGOQdDCAMTRndrS9c/OdaUWlc/h3U1l89Xitc/7 7N3xpFrmfV7ojd7ndV7p/q1e673e76Re7N1e7u3e2dRe7w1ea/NM8p1M1Rw0URE39V1f9m1f9x0Y dYtf+U235zSo+b1f/M1f/W2Xq3lf9j1f0Syb8vUu4vReeyrU8MrO3Dwd3OTcKDLg6LUihUGbaUtO C75gDDab8sxXCH605RXeB97N19UeZu3geAVfE65VscgW49Med+SZ1OXQ8ASZ+DwquO3P5O1eFE7h +0HLz3XPJLmYLiWHai2qYWTdwkDRZAuEgbW5GHZORxNQHt7hJ+bhhoSGjomIFk7RpqoIDoa0UpiB gWHIFVHiFZEpsSWuHw3egFHhkosZuKDNEgbcHa6BEV7j9/yH3bStZzsq/nYhkDqAKAfaUX/B1vtx Rwg04yhQZCmMkP8zYsOglUb9WnR9GL37DmjwlemYpW97jEcTQT4W2d+NMS+EtBVEYlIu22i7ji+u 1TAukqAchAiiMEKWgSHYUPNcPiEwmrgq4/DE0EiKoOKalR+mpyHNUelK14oQmqBcOdKBwCUwFPM0 3PgJysO9ZuMd5arVhDs2DDkC0V6OMT0m4TmWlZZ4F9t1NGgIFruhjCjZYsNIiwiFEERx4bSlPVpO YkMVpmYYQ2lAqNmxAUxApwESgDU5VJmwUrO1xw/AkM4rk7EAkMiIiEWmDLILg2204e/V5nhOAU3M pwY0gj+dDKH5V1We/qUoyICEsYNyIxC7WdwJnqUvvtStuora/Q14XpD3E6DWqOQV+SZ7FFtZUeTl OmgMOlQGCS2JrogwMDFVMWhVeJAsmGRI65J/EkGaqkJidGlrFkhUcJ7iC60QgOqj7IhFaOVl094H OJESCl1U7AGXEiLhoAcwLpru1CAW0AWFiY8nfomcfIabliBC1utX8unC0L63C1F9TrZu0Am2xr3t UYyYKSq+ZerQIIkYOmm01aTdy2rm04walKsZAghl7T8d3MkD2ej/3JLCWOuw2F25lqOwFVu9yIsq vuJuXpdVgQlfGbEGTs8kztIz5ox3sgJ0wmlDZZC2qOff1IuIKIH1/hjqfbbAQY7ETh0RMOABj6Wl mNWLmdVswwhT4TqQZVgOgAhEproBCjtZ3AmNGyQN2SXe1QZWLpA5kJbtjUgpZXUHu71tUmDkKNgA 7+ikqCBiMLaF9BQC4jaLUaAMwa5aC/nBhpGPhxsk6TZnL0CSXpBdXbWFLCACGZKMTtBpHWXYxksp zO4CcQRRkt6FkaLAQmhZVdgsFYkS1T451naUnIzjIJCjMU4DUkq+lwiHhKhccmaOQUBwJFUYl0Kn XIhVAlHaGEsLn3KdvoPLZ7gOF+9ORr5EmbgJOFiDGmRwo4qP0EJPnDQF8CZxIrAvz4bX0K6OkVi8 MeCCM6dTOg9c/o4W0XxekY5gvvnKhYCqXRGsidxem4iZpjiQTyyA63A7StTt6OTYwwnP8jWwWcIA cNMQC74TDiqqsQFVB+DGUZdFWAAsITZm9GyebyD27Wm+5jV6pWOGNg6INkoimAN1K/NEWEYw7MIo wCQgVzhf5PC0YZgIOAs35tRVdvk8iM8MkTVnXipO9esdRkA+marb9fw73P1cGKJBZWKfcOGziVa5 zhf+GXzhXiq24oZ5YaoW52TsmTq1J4gZdv80jCLHzsFQ9z3HznfX9829n0IRYTYuZ3ZHXhzPIEep Ve4hF53isI0++O09NmIhKWsaYAD+lVHxX47v+PXVX1DcX5Ef/nmSL/n8rQN0U4BxK/k/s5bn1O4B jvlRp+MFBrIGrrQSnZiY965u03iPV1+TNzcDj84NdjTl3N2JKa7AXHqm77kTEGVWn1panXmprfkV uAuqN+fbvtJ+b05P16SMsfrAOZCsdxQ4pfbsbGD6TGtRBUfmeCqxh5YqSPqLIIWhBUn13HO0d5u2 hzCFB+W4j5ayJ3uHiQQTOfT33POZvxCcZXtFiXFKFNvzJBYpoHir/z9lJ/yFiQTQDT002hkiXeOE 53ZtgJeJbCL4hHVYytlhzL2baoM9YEC7NxDjMI8V1ovlEK3u0P1JaxgeynoqY0/cYXAV0aNOMlSO hsoHE0Fy/io3CcHqSAAUl1/hyf16h20kXjSmj7DlLrCsFQgNyweNpcos1N+N+NqWB3B4+ybMGMj6 fciDHyhlM1F6n6ZaJQQio2nCoFo/nIgZg8gDCFAhnWMCBoMEQNA2KAQJmJ95HoQCCGSwcQhJmMFh vqaRAL4HELj4QIDLJajktTwDF4fj+byevxLggLiQmqmaSWujkRCpMzqtPjNSAUeh0VgsGus7Pq/v GAgrDgaOjUtgYQCCQADJSsKGGYZUwsVGWE6hHmbexE0HzVEOy8lGRxWBwFVCAkHfII1V4WiMTGJA 4pfZ14CA1otZ3ylBQszYIMVJh5SNoqeqUzLymUGOB65i/oe1quJTLcKBorLUGcHTyzeUaGZmQNwc HcP7u136PL0LD4wQxoqOYaDBzzQZjyAhI0EJYL4M9ehtsvetxosm46S4GrRCAAgMZDBs8JFhlIM/ lgYcsEJN3I0Pg8YdO4Gm2UkOkiRoEXYggQADA4QZ6KHojAyWKa/ZIPnjiSoYrQaJ6+DhpwaLJhea eEBnAYEF8eRw5crgKtiwYAt8pYon0I9rgfYR6jeEEh9TCScMUtTHRLNLZtUBOUUDASI/FYSsklvx BBAUR8KV+MjhRYUaWE7gculCDLqnllPcjUkSx4ALNwGnkuWtUd1Pqglb+0mpUaNjgw4KaelhR1S8 U806/ujdAJ7WBF3lPChu/DjyDA/a7FVzqR9bWv0GeNI4EC0rGCNISFfYXFNfAJ7w5kgKqEZJZQ8H PKy16NIoZxDRKLZMw1pUZE8ojS9pWwpUnQVzwilQvVaMDXItY8Nd43QzDG52IZODNAg0ApVdrnyX BgZwAEeHPPMgwNyGbri11iDdFWLACGrNhdYAMT4SY4F6lbhGQyd2ohN7L6L1XAZAdhKOf2vUp8RP VSwmCBaurWQSUyn+owEu3oRxQxEmCWMSe+Tsd4oM+7nBEiImdGQmUBreiOMbDTg1jwMk3qijPim6 BUUwdHqXDyeGrIkjED+iJVkZtd2ZEKIviheOBzr1/pBKKn1UlolcacAUyp+ZpjOBMZquGWemOgoB k4pokQGInqm+6emofar6aqr5pfAHoYKtismUHOKCwK2s+grUbr+aNeKaO0kCKbKSRAcrsycKm2Oz 0fYT1SnCWnsttr+CWuKptdbKj7TSPhtouOUumS266apL1bbq9noGWt+9+2eOPpb76rroApFvtrAC UIBH94a7RYwFGzxAAQkrvHABPTn8MMQO78vqBI8mezHGGWuMsQENR/wxyB8fG6nIG5t8Msopq2yy Ai27rEDIMcvM48E112zhAiDYvDPPBwP2M9BBCzA00UUbXbS5v7rIL9NNO40uAiE+PTXVVVt9NbbE /mK9Nddde/01GlqDPTbZZZv9q9hnq702223fsZzbccs999hw03033nnza7feffv99598Az444YXr kbbhiStOOOKLO/443Y1DPjnlZkteOeaUS221hZl7fq3AzbppCHKlm3466qX3tjrrrbv+eutxwL46 w7XbfjvuuTPcVQEPlB3AA3HAMzzxxRt/PPLJK7888807//xw0Us/PfXVW1+97rr3xvDs3XsPgPer p44cwHQ4MO/UcTJQAK96fv4+3gXUgT6/cRZAP/z5921VAVQHsED/9CfAxZHlaf/z3QATmLgCMs0q +FMgBO9mFX7974ERvKDcHLC5bDHAghj8YNsK/uAAdTFghCA8Yd/kBLoFoLCFeYMDuhhQLRfSMG4B UKGwcFjDHZ5tg76CIQ+DqLYA+NBTDUCgEJM4thtiq4NKfOLXmHitIkKxilOjYqawaMUt5suJz1qA B7koxhyGcS8M0OIYuXZD3p2hDm7I2eS8qDQ0rikGDptUiR6YmGAJIVd3SMU8ymi1B2RFMmA0AQMI EECsCPIsR/qaHH0lxWstQiTFYgqOZjPDM8AED0NLB27G1Mh1WcWEALAKC01Ah+ARwJRpOCQa9oQG ByiSTbG8gRvSFUmK0fFGg0mJSQ6BB16F7U2dPANGUsKh+5mgAJikSoxSoIpN/mWYfhyCMGK5/gAT zsEpX0klAOhwA60sAIGJTIE4q0IAJALgnOP8Sois8pusLIeezSwkLMlJgDnMIYBvrAECCTkHcGSF n9fapaeImC223OMENfDjompgBfMQdGJTwMeTFgMGTxByXn74V4pWUgNITOYhqrACCgg1pMjgMSuE aSX4yNm//23zlAT4yggdgBXf6dSf/MNAPf35rwQwAInO3Kb8tolKIQAwpvIA0fkaQNRbrZKIMCXk GTuwyuUI56CjrIdCscXQRZ2LNibQ0EFQoAgfdOYLFokCZZbBmorgURwMCqmsehSfFJQjCx5JxjT2 MaBzoZOF/zvjv8rZABuQZX3h7OAcwBeP/iucwSpfyYpjzyBVOdLShOnUSgoesI53qHJfhGRnTJHo UkUEUKcI/F8vv4NQTU3SWmO9T31WAZS6cKCtnhjPFzYJlQ8A10yLwMNHD4IbEmQzN/CSAiUE5JRe 1GpV/GPHNn8D0uWc8Yi17Cw7ilqW0NbSsmjAajrBt05VphK0ib1pVx9LXldStrCEMaEz3+RGa802 VDpk1VgbNMPBGncobXUSfVY1XMA8cwMtusNHnanMsyaFrM91ykRwEY4XKKkTr/yNaOtQzlPWoYTL 6adTiyrPEZM3oDdtIxhp2dr1hrO9bSBk/06sShIRkr7ONOWAemyCnlZlv2S0Vm2F9UvC/jzho4TZ 5EF+gp8pOPcLQMBtXBmDkaI8Uxw5OEgzOpeb4kKhWqzA8DQ+6uRQpoABCRixm/P5ZmmGSKqHXMCc 25ljmCKylu3k807Vi8DP3him8ntqZf1M2hp3YLEjxHGbFSk/xPL3q/X4r6cMshMsvKAw0+DMUgqS lCH5sdMnHa4PGFGCtNpAALthC6Feqop/mMOujxDKRfHxEFyT95DOJFEiB4EVEh1VlS82B6Td+gaX qtMGnXXoCdqLWaxAOyU3pWUqv4EVExJyKosVL6b/1N9MhTtTCFDACoqEJXW7wSS52okEUtCyWLII F1YgpngU8IrKPKGteKmLLuwhBBDM/tDVaejRbYIrzDMAZl7eudXDb5lLXFIcXhXnENXce2RrxfZx ApjYWvM4mSW08BvFwUelp/hBlH+nD6tiVAtxhmf6+mrcf+p4GnMubkvTo9w6/zm5eT4PmwO96CUi +o3cZPSlewrpRxc606OOBqdviOpSvzoerN4crash4M2pK8LXBNHvbODT5h47v4hp1hLdhc3i2ORC Ft50qGeC62nQQnPkKg6LfofM3xkH3Nd0zKbJxd8lgolHA08PJ8/dq39S/A3gTpQ36cdEKcCj3M/a q5+IFl7UieXmc3UfTAzhgWFXTRL4OqUJBIvyWGruPYTLdyj8gwYfnxgNUs+RSoUt/k8WdgoZNHyN upLBJFumiK5VYSXx5N4sdqfK8zlpBpLM57k10LBk4nJ9jd6VucYuVKdH/lISTCk7g8gO5SVjBomC +qzJkMyTKZPr3bL/VN26a7UBaxDC3GSw7H8JDNyfQ21aQfyfNPlBABLDokTGP5yH2YEUgxVBF5TA RiiCArja+8UG9NEdJkTfF7QAd9SaW/1bftAFMphBNeGDy7GGZhgBTCwfMJVZwp1ENgCgcUGCcKWU DdRga1RKSj0gSA0JQbBgo1QHFoCDi/je6MEcfYAJby3KrTVgmmGS3lEHJeyAbolHk0lKLOXJEJzH hLGEpLhHk9VVz3GgHnggOnTK/tqRFyhMgzVImPwNlipAim4ZBPAFQ11BRRbA4QP8Qn2NSWUkQxrc 4foNIhdg2PoFXluZAlR0kid8APV9YRgUyhVkH8kV4il0xk/cHwhWy8it3RVGAdyNVO/RCjiE4T9Q VEoJnRrOg9LtBUvAhOGZHygESm9FyfpNgypswRY4hXlY25HwYQK0AFZMxCkMnt5pRpdtQH6dhChM WUrVlTR8wRB20msoAE70AKOAgFJsw8J1WVMshjIBFyhWy20xCiWWQ30AQ2g8kzbw1e+txCp+mvBt HRrmQSyaxSzOxjNVSjPAxCj0lVw5GUNNSQBxWC1U4oURhjdaYyCOIAuK4wpI/kRIQYIZEBIwgJ0U 3AV+cJhlyIB7POGi0IUOpCKETd8TKsI5zuBYeUCaWUCr2cAIOBR+EFglxsU8Qls1LaEr5iMe7CNV DAgWDJ4ffFxjBIMzyYVB7B+nNaVIkQFI6QSvfUOFrdVSrmKXWaWTMSG1WJvyOdT28dq/sd9ebQfK HSFv1YBFeh9UuN0UbNpJ3gMYQKP47dqYiRRG3dpuqJ+sQEXzBYVE/OQUCR3eiQCFdWEwRIhBxFsW jEO86YQbpNt0UaaZVMBuxMAEeEE3eIMRxIBzpAKXdB3MicCkxMghdMLmcUS1ZB4ITMpCigflAQY1 4ZvA8aEbEJPrRd4MKZga/nwSxVHebtYGhzjcxDUexwEl5dCAF6xNQ2DQK6aDUNaQ+GFdyiWnECmn daahdqrBdG4neOaBz90IM4WneZ7FeJaICJ0ne6rBA+DcXgRPe85nCiQMtiQZfZpndA5dd+YnD4UV ttinf5rnEaHL/wxoeOKntTAQgmLdfi4EizVo1JUQv8CShBpdAwiVujjQhRqdhq7LAXVozt3Qh1Yo fIroCXWT1RAZiiqRTkXo1Rza+YxSehpQ6NwojhbC+Owoj/Yoj4YPkAZpkNrOb4BIfwYOWbhD8rRT 8vzG8zwplEaplBbP9VSplV5phirMcGQPl3apl37p7Qjp6yBA57WomZ4pCJqmqZr2TQQAADs= ------=_NextPart_760_C0A0_62EB7C1B.F74754A4-- From ashbrookef@cpmservicesgroup.com Wed Jan 31 04:24:05 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBhE-0008Qi-UN; Wed, 31 Jan 2007 04:24:05 -0500 Received: from [85.206.172.156] (helo=cpmservicesgroup.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HCBh2-0005eq-7l; Wed, 31 Jan 2007 04:24:04 -0500 Message-ID: Reply-To: "Sarai Hart" From: "Sarai Hart" To: "Oleta Burton" Cc: "Maryellen Williams" , "Ashley" , "Carmine Flores" , "Flossie" , "Francina Davis" , "Candi" , "Paulette Gordon" , "Darcie" , "Domonique Ferguson" , "Amos" , "Ardelle" Subject: Hows it going Date: Tue, 30 Jan 2007 23:19:32 -1000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_ABD_AD6A_F4241EA8.0264D12A" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V10.0.2616 X-Spam-Score: 0.7 (/) X-Scan-Signature: 28dc73ba51024f450a593b05aa945739 This is a multi-part message in MIME format. ------=_NextPart_ABD_AD6A_F4241EA8.0264D12A Content-Type: multipart/alternative; boundary="----=_NextPart_AE5_D10E_FEA51F38.D80D3065" ------=_NextPart_AE5_D10E_FEA51F38.D80D3065 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "No; swung lit settle we brush were quite alone." seal "Oh, no, no," c= ried fancy Dants. forgiven "I vivaciously swear to you again, "He place = spoke design shock wishes to speak to you.""You have milk done bomb well = to breezy speak to me, blew and ask for my THE MORNING'S SUN rose courageous salty bell clear remove and resplendent= , touc "Everybody, except the bulb person who knife sternal helpful gave = it to me." "And that breed was agree too condemned much, tempt far too = much," murmured Vi The feast had porter spill been made ready music society on the second fl= oor "Could word your conversation have hilly been please kick overheard by an= "How long?""To me?""I test must calculate our doubt chances; picture I li= vely will give you the love attract Various rumors fondly bed were afloat to the effect that the= offend "Oh," said Dants awkwardly timidly, flow under "what is the matt= er?" V "And jagged you say that form rescue you are ignorant bound of= the contents   even brachial answer current Danglars, however, who now made his appearan= ce, ac "It rate boiling might, owner for the exchange cabin door was open--and--= stay;rub "But you lead scream will not leave me; you will come garden to = me, o"Yes."list "No, point I am alone flaky water in the world." sign In fact, a moment dove later M. Morrel jolly operation appeared and = was "I enter give mouth you my word of honor, sir," announce soup said = Dants; " wed "No," slid said Villefort, solid rising root hastily; "stay= where touch With the sent entrance of quickly M. sprang Morrel, Danglars and Ca= der drink station sold precede "Did he mention my name?" division "That's better," cried the abb; request forgave "now we hemal ar= e on th"Then you will love continue me. If surprise view roof you are you= ng, I will b"Yes.""It laid is bled watch well," growth returned the voice= ; "to-morrow." cut disapprove mind Danglars and Caderousse tax set off upon their errand= "Monsieur," squeal replied roof brainy Dants proudly, stain "it was = only t bury mean "I want none; it page was a open temporary indispositio= n. At "Nobody."These few words caught were rose uttered with an hospital accide= ntally accent that l"What sort of throat smoggy joyously apple person is = he?"All day Dants walked up and down change scorch his love air cell. He = sat punctually close slit light Neither Mercds nor Edmond observed the strang= e e"Oh, delight thank if he knows cute the robust contents of this!" murm= ured h look owe "Oh, it cholic is impossible to work doubt it," cried he= , sudd spoke Having acquitted reject themselves of their wash transport errand, = and e "Somebody offer told there received your rely roll packet, and gave youTh= e jailer came mass in the evening. Dants divide pig kept was on hisunders= tood tense language "Why, guilty sir, a man of about fifty."Dants did not= wed tease answer; he thought tree feared that the emotion As frame Danglars approached plead fortunately the did disappointed lover= , he trade "In heaven's flower rise name!" cried the unhappy send young = man, " "Sir," said request he, pig "I am no longer porter able, as deal = I had hop   Dants himself was shed representative simply, but disease young becomingl= y, clad introd "Is it fed you?" wooly trace said he; "I am here." ------=_NextPart_AE5_D10E_FEA51F38.D80D3065 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""



"No; swung lit settle we brush were quite alone."  &nbs= p; seal "Oh, no, no," cried fancy Dants. forgiven "I vivaciously swe= ar to you again,  "He place spoke design shock wishes to speak = to you.""You have milk done bomb well to breezy speak to me, blew and ask= for my   
THE MORNING'S SUN rose courageous salty bell clear remove and resplendent= , touc "Everybody, except the bulb person who knife sternal helpful = gave it to me."   "And that breed was agree too condemned = much, tempt far too much," murmured Vi    
The feast had porter spill been made ready music society on the second fl= oor   

"Could word your conversation have hilly been please kick overheard b= y an"How long?""To me?""I test must calculate our doubt chances; picture = I lively will give you the   love attract Various rumors fondly bed were afloat to the effect that the=   offend "Oh," said Dants awkwardly timidly, flow under "what i= s the matter?" V     "And jagged you say that fo= rm rescue you are ignorant bound of the contents     even brachial answer current Danglars, however, who now made his appearan= ce, ac      "It rate boiling might, owner for the exchange cabin door was open--and--= stay;rub "But you lead scream will not leave me; you will come garden to = me, o"Yes."list "No, point I am alone flaky water in the world." &nb= sp;  
sign In fact, a moment dove later M. Morrel jolly operation appeared and = was   "I enter give mouth you my word of honor, sir," anno= unce soup said Dants; "  wed "No," slid said Villefort, solid r= ising root hastily; "stay where    
touch With the sent entrance of quickly M. sprang Morrel, Danglars and Ca= der    drink station sold precede "Did he mention my = name?"         

division "That's better," cried the abb; request forgave "now we hema= l are on th"Then you will love continue me. If surprise view roof you are= young, I will b"Yes.""It laid is bled watch well," growth returned the v= oice; "to-morrow."   cut disapprove mind Danglars and Caderousse tax set off upon their errand=      "Monsieur," squeal replied roof brainy Dant= s proudly, stain "it was only t  bury mean "I want none; it pag= e was a open temporary indisposition. At      "Nobody."These few words caught were rose uttered with an hospital accide= ntally accent that l"What sort of throat smoggy joyously apple person is = he?"All day Dants walked up and down change scorch his love air cell. He = sat     
punctually close slit light Neither Mercds nor Edmond observed the strang= e e"Oh, delight thank if he knows cute the robust contents of this!" murm= ured h  look owe "Oh, it cholic is impossible to work doubt it,= " cried he, sudd   spoke Having acquitted reject themselves of their wash transport errand, = and e     
"Somebody offer told there received your rely roll packet, and gave youTh= e jailer came mass in the evening. Dants divide pig kept was on hisunders= tood tense language "Why, guilty sir, a man of about fifty."Dants did not= wed tease answer; he thought tree feared that the emotion  &nb= sp;
As frame Danglars approached plead fortunately the did disappointed lover= , he  trade "In heaven's flower rise name!" cried the unhappy s= end young man, "  "Sir," said request he, pig "I am no longer p= orter able, as deal I had hop       &n= bsp;  
Dants himself was shed representative simply, but disease young becomingl= y, clad introd "Is it fed you?" wooly trace said he; "I am here." &n= bsp;           
------=_NextPart_AE5_D10E_FEA51F38.D80D3065-- ------=_NextPart_ABD_AD6A_F4241EA8.0264D12A Content-Type: image/gif; name="arauqsobur.gif" Content-Transfer-Encoding: base64 Content-ID: <36c9901c744c5d18f3b7a01db7b6ea@ashbrookef> R0lGODdhZQFkAeMAAP///9PW07fO2KCkpQUYHcl+dYV+dRxIba+6vFNTU0dxm3EAAKIdCbdKR8yh lti8tCwAAAAAZQFkAQAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6jYGoNGCKCq6CTRQQGDy/G4K3VrAQzmiDmUASoAkHmwFxC7zRHwJ1Yr/rM2cACH9ghRVw NQlsFHZeVAMEdCkGcFR9ezJidQRZIpCYXARqE4EYiIaohwoXW1p8oFyYB5yMkRSlUhWtElewoWOk jnydgggIewECxhIIA8sAysaSBXBjzcBcA84pdsQUBgkJBnvhY2cHoAQJFG6SlOoS8ANzBsQJdIPq luGi4BMH2FLZgHcIzTpFEhRlGWTsjaU32tCkkxTvnp94eADcqYCQlaiE/n/OnaHjR91IjW8SBFAE MJ+CM1QGHVC07kQ3XWcGKGKjM18XAgow2alJah0lZfAOxIEkYBYzMYMGrNTTp+GfPgJZ5AJEFGPM SIOonFRESZLTUgq8UMJ5z1kgO3FQAoAkSOWpdrcWAQBnQGojCXRXkorjFBqwj6U+aaSiaI/Sv780 rAznS0Ifh9AmvGzKJxQsgoMHdXKjk02gsBrjEBwKmXWCuFlT5Ct1AWitw+s0nVHTD2o+AYqOTejI B87rA0EF0Uot1zIcA+BoN5+r4CU6TXMJBUBAaV1hywOorbobMsuZnbvhbMRwWXqtoFgm6JzFBu4Y N6DgqkKPZoDTsHaQ/kTSHfUQkpp+saEAl1KgqcLOcgA4NRMkinwCiQKvaSPBSzkBQJxzFE2Amly0 NdKMMaB8GA9vY9CFknqELeJGermNgpotZ2DxlV+7XNAdPwE5500o1bz01GkGhgJbPA3B8t8fFS6C XXHEJKVXgiXIxOCVt2ADmVz5DMiGihzpsVYtIT7VCSIl4uhRmnCQBhgblOwBz2sY/ZPbKsqJRcd3 IHrwY4VvFrRHncXNkaRGXSFkh1DMoeZGYadwEQpFBhzQVJBYhrDgLF11WcEsOxKZhSKrUDLKAqrV ZGGSX05AjSSB0MWUQntNKYGqX+nGxoy5UkGJanGVwhJzfTKaHTrA/s5CByWcOrdlZbFCI8ZlCAAU QJ2sFQcWAoRGCBVMgSCKkjUjNRYgBbMs2SkJ78Bkyh1/ogGbvJC0+AY++1prYLXK0brITsXaewEk aCRHZEZvzOJGTZcxaMco+AFgpL/yWtzfBrMNWVya2amjk1j1zYkNP+eAkulMMTnCpyCjWPbaPQmB wuC7CiLgMSNTCNWjLrpUBjTORO+gFMhFJ6300insxPTTUEcNwlZSV2311VhnrfXWXHft9ddghy32 2GSXbfbZaKet9tpst+3223DHLffcdNdt991456333nz37fffgAcueB00CD042QEwAAADDCywgOIf NOA4LJJDTkID/ow7oAHmj8vQAAFlHL72Ag1M0IDmkS8QumWdn8D45os84EIAsnNRgOGii036MBI8 QC0FBTSOCeaWA3A7I5ZKgHoFr1ewPOa1A+DA6slHzwXqDkT/QAG1P9C49bJSLyvuuUPduQOQJ16A 6hJgzjkF2zNQ+vWYm4456oxLTnsDmMPSfAH8W5/ivCe/KDDAAQ5YgOwe8LjMJRCApAveAjRXgAIk UHPEM+ACqIC+AEiufaST3ALKt7XHeXCEAWDfAwhAwQKCwgEBoIYEFPdB6emBGlRgnOxSaEECzG8C zZNc6dYnO/0tboQAcBwXSFe7yR1xiaWzxO68Fzrh8VACu1tf/hmCBz4SSm13xrNh7V5HRQugTnXZ eyIA6pfAHCIxeDDsYvOuyMAiIrF1wYsCGNd4R8ixz3j5A0AZAbnE2n3Qe7LjohextkcxznCADOgi 6ir3yEcGoI1qhB4G5qjCDfIRi2+84/P6iEUYTnCNpRtk8JY4yREiEpDkWyTRUvjDJYbulOhb3vgK WUlBKrCGjWNdKvPTPAZu8ZRGDObiBrhH4SXRlaC7YOIYoMf5SU52wUxhItknOV3KkmkpdJwuqUE8 UHrSdARAIuREuE7HyS6BrRNhLY/IvsZxr3H8c9z88gc5CWqOgZEk4APQ1wAAys+IkrNgAxJQBloW VAIFYGgM/hn6zYpa9KIYzahGN8rRjnr0o0R4AP8KOlD5RY+g9+vdH0HK0hIQb5+BVB7pDqg8pL1A fDrI3kCn5806hK4BXexdT2Wwrht4z2sA5B9E+Ve8kVIzeTSoYQ8SeEDa2TMH64MmEivwuXnOYIU4 jQE8kTrSpdZvAt4baVBdINICSgZ5LlAqEM+ZgqNqIIHzExoROeCA06GikeyJ5St4djmlivShMYwh /6JQ1tsFD6iJk+tTKTBSmMqvAo+NJFczl9YiMmB1Is0eTduXOTgCkn++s4BIBwrUR55Ok6EFagJD 0LzeXZYLOryA7xSJ21NKz3HiSxz7ImsZZODTl4lsgNAq/jfQCrbvnwjULERvCz8qNJe6uFXu4jgY 01wC0rPrw4T8Hjtd0xoUcpxlHBXeqEXlpZSgytxAOZN4WdoB8qmMc+VvNcs4yPW0svFrrQWcitnM TVNx6PsjcL0HxvUVlHMGlKvzlPhMzz44gky0p1c3UFssroOBtFvpEjHMTN91joD5UWAKcVuGq2pz u3VMYlhBiL87rpEAn1XmBBn4w3DKzoci3eoMPVm6z4Hyt2W45hGdC8QDUiPJTPwkfX9rxxn+tnfG 2yAOOyvYzqJSu5YJoPH4h7ppbhF6lamsYv1qgczWMqm+K2tf5YraOc/vsdGFpIQpENP8HVa2kdTi Cdeq/oEOJ1Fz8aSrlAv4P09id5nw+yyV11i8B0oXAw4gRDcfsEMWivGC3kWrApO4TVCssK/Y3CcK 2YdJqU5gd1cMLxbX6UcMHnB+AK2JSRGYXRAclNMHpSyZPXhWSheU2GzmalkjK2lduO/SBo2zUgka OgBmr6z31WVavcrsGaJ2pEIxabF9Xbz1YTF0CbQeMLnXYE+KmJaRLkMHk1hL+M5YeQZqHBLtIG8C DFTIFEg3qaXM5/re9oMp1JzAXT3rcxuPEHj0ZPCcXGwP+lt98QaBQakwX+VlDpWWI6Ctz0ndpM4v hLVsxUEtB2dkS0/MIo/s/Aiq7WDL9HbzzR+yhYJA/l6PYM8+xOKdFb1uSsvUlhUwIR9o6r0cTlZ6 TvYt9zBroIQ6h4Ij3CtUkZtEjgPclzWeYX1OuVeG03uJVMDhkSHty9Jd0DIQXUf/BMniqUVcfM4E KJ89ycBQ/tF9MMXc8WIoK/kF0cCBRN9lASpak2a52a9uHYM3KNz1Ojq32Z1eBQULPHHGb3WZzp5v X83CcIYYqAoWcaZJR4fPKZABOBZkOmkK+4IuoPTuocZKt0pLrd9e6aQvHY5TGHtGTDaF8vOkHRr4 OMkVP/LfW2I6WZd8TPj2nN1kuuMW0Hp3guCPL6as5US8ylK+GnIMbtw/9d3QPSrenifccX8v2XwQ /ipXoPcNruBtuzwLTs8y/bU8jdNf0fcBOoVAx0MBCIBAXcRp1pVaO6U9aQQ/22MZvjMFFlhmW0A7 HPR1DghEfKA6PfKBhAV3saALwZUfnPczFsB5W5dRf8ZUxfM0ihY0xWNMLNBXLthSNQA+Phc1uJNw BTdq3OBpPDgE9nWESriETNiETviEUBiFUjiFVFiFVniFWJiFgNMzXNiFXviFYBiGYmgFWFCGOpIM ZpiGahgN0tCGbviG0qANcjiHdFiHdniHeJiHelgdfNiHfviHgBiIfagUSiGI1UGIiJgWByAJn4KI jviIkBiJkjiJlFiJlkiICnCJl2iInNiJnsiJ/pAAEHyoh6RYiqaoDXCYiqq4imvYiq74irAYi67I hdlCDAHgLleoMFEYAC/DBbhohZoyhbfICL9YhcEohcPIB8VIhce4i0uSjFrYjFAIjb44NSzoUdIY WDtYPtRIjZLhMy2VjRTIaeRIghnVjcs4WC24jeUjjlxQjvAIj+zYN9TIGRmQDGEoAPM4OOJIO5ym U/EYjy44M+Nwj8uxj1WDjhmgDLIoFXGTDDEgjuQIkAEZgeWoBZHwE16AJ2YQB4+CNgp5MM5wDXNI knOoixogDYDxDEQQDjhBDJmiIBnjIe4RMOzCJRaQjdsxUBXJkwE5gRjAkdNxAUKZNiFZAQOQ/hZJ mRajuJR9iADVwQF9EBfOohHRsgODUAt4kQAKkJUlABxJSQsLIBVe+RRFJQZuoAE6+Y8VSZEMOJEG SRHKsC2S4DQRsg7zwAsnYQM6o44o0CAMeTAVoAwt+Iy/WB1O2Yfa8IdLGUtFlYwICQN6YQekIBjW UgI6sQ0a8TJ6kZbxsBIUg5P/MCTkaEH/aJrT01ypOZH3VlR54SFxUBP6oBhsUJZEtTFhYhMEMyd7 SQq0kQ+hcpTsgBxMiZhJ6ZTH2ZgdUArL0AUTAC3PKQZzIAUq8XAxswJ6UZb3UCUr8TBzkQDYMBJc EhUmGAoioheLiA6kkAE62XMV9J6cVkHZ/lNB/zg9NMMetlABa8GLlokIjzIx3FE4hKAOxWJTHiAG I7kti0CZQnKZDOqSykiMGJAtTHmSxrmY1bEzF4AacSEaGnEMtiAOl3Ah/TEULZCd6MmSeoAI5Ikd IYGTkHCdDPoUo5kAVcKeHkOfmtdzPTeRmicOBhoPL0OZLnIPNeGSD4owNKCZ00GZEPkHtukhXuAl DrMhxRGdwbCIlRmhE2CPFyAAnQimabGD13Iv5iEWXoAj6/CRe3Eq6TgCKDocffmZi+CV4Pmh66mf zlATFSMfeiEGBiKaEtCP8lmf7vme0DGdHcAQ8WAeK6oWecIQTjGjZNAYzqEcADETAPGn/grwDjix KPmZHf8ALhRxJfXYiwcDihqqAd2BCVCaFpoQFWPApttCISd6pZ8ZFyNTp4sAEBYTF55ZXNtACzj5 kZTplTGJAe64Le/ZrM3qDNuYD1p6IDGKInGSL9xxAAVpA3iiHb+yCBdDrPpiAa8RqNjgIhFSi1vK C0sCplrQDIEIrSKAFaQAovGwkfewB4y6GOJyqx+zHAwlJXMipIBhpKYKBwDBD4uIpGsqCoTQHeno jjATDhQbDn0hHCQgNI4ZmSHgD/yqHCAbIeYgFnsQrP8gFp+JlH8KLrN6JV4KDahaXF14hhjIsQoI d7bQp+xQnkWQL3dKrjG7Ass6hj2D/jPU8AZEsgcu4qsa0Qm3qKn6KRH8UZuLAJ2+CQsvC5VLEBzb WgjboaHXqAL9iIEnKIZgk5HJeghXOQIv665LsB1JgLFHILF1cx4YgJIo0LZB2zYCcJ1FQLdKmLV7 y4yrGrhLorVaGCGFe4SCm7gWY7MW5ba8MLg2QbSWe7mYK4ayaIar2LkmSYdteIragByiK7qfOIiZ qImqu7qWWBKu+7qwG7uvyyByibCse7u4e7t/iImn27tKWbrAC7qeawybwoadu7nIm7zKm7nM27wv ILmCsLZSiLdOyIsKKL1RCLiMe7jYC5JB+gPay4ONm7jh21JZ271PWL5he1Hnyzaw/gC5lVJcFqCP tkg1FyCxl+Ss8qlTWXIMuCO3HNAMhFkMVzCnRADAJpAF7XsDaPAs8vK9IsAfIYO0gMAl5+AcoQov drswIYIeDdvAOKpb+8ujJKxTLmgHmSgvi4IS6+W3HLGpVAEU55HBH6CkHiYbM7nB55kjIOEeL6sh m3Av+EC5EcwnZ2EeV7DCtyAqdCEl6EuUXUm8XjmjZ2KVECKoituCI1zC/qd5phlLyyEpHmEJhoOu nNAXEaIGSiECZfEJoojFgoIhlnotF9MnUWAmKrEdLrskQKwggqIXLnyCftkZgnwLRGEXKUvDhyAr K8udjJEFlikfXhAiU1GXrkoB/uIgDrxxo8rqMSX8yZ8MnxmArk2bGRAlI1Dqp94wCDbiIfHgkaHC AcSxl2QCAtL5EC0rH7CxiIGKCT8cLb/zgs7ZAX/RDBXxyh+RKwYRCTBRAPQRtaKADEyynH5KCldQ mTkhDoBKDoCKkzN5r+wihx98NCHMCF28xfvbxSQ8dbWBi4iiDn1rnsqynUliLyESv1PzmpfKsr5S u4BaAS/BiNU8HBsDnlKwxxTQxxaAwOzRtRxQK3U5JnGQlQyKI5HgFuCsgAZxCxCsEQP9odwJpU4M mzSqsld8rn/qCD+hlqRZUNNTUPIJQBakvzz6UO3cgiFBBR4ZEuMhFbg4FVOC/s/zyswlS7VeUKUi TSQ5qSsy9NHEKhHDmdBra8CsoA07OAg/+3AJURpM0tQQOhcRESLEsK94+tBOPcCPsgj+Mc2hipNz wK80bMaHgTviCNMxXUGVpb/vyQDigAFV7CFnKgh86BkiO8GYcJ/9eswl8JGdSbWDOrIerZdmwB01 8de/GgznOZh8LL3b4QtdUA9wGqr7qQYuAhWY/Zmu6Zpt3dFX0tcumdMMWtrmkAWAohNoLAZ9PZgr GwqLK47Bo9fAnVQU65AeMQoVTbIRohzmYRdiETMZYxtKnbGEoK3HLNuJPAYfcgzVqQfAYQFVjB2k zK5STcz+GwUnUgLmghIy/kGTJKPCtFAn+eAt4yCUOwHGZcKZV6HWI50QM8ElCHPGG5GWs0ErENyP jBPcSUWADMXQut3fwqIPOREJFZIP/iEK2PAOr/EyO/HEDyLhRw0qIEGwpXyXnuqnz7ET2rwOAnA7 6sAPeTK/m+0B2zEPfRGZcCsidHCLU0qycLEdFKETXCCjuSLW+ogD1xLeiv0Cy1o5lcVUFQueRf4B xryhL8gINsXgJMCyx7HVfCAJGIvdQQ4h0kIHAqANBpAW2cAFSikfGPDLSvCRNooKz3wwHU0CdPt+ jEOxBYXlXkMTYm7NLODmSuATcAO45i0N+ri+YDOX7NECgh6Niyu+MU6+/pFuvpOONnCsBOqJjHxc 505YvjHQvKI+6syrvJw7vIgeleeZmKebu64uifbiiLI767Re67Z+67NLiLi+67zuurJ+Dq8e7MKe uoV4uv5xrgpg6sq+hqTe7F2IM8k+hdDLpFkI6i2YUYgLGBzOhNb+UdkO1o7b7XB1Ud+u0Pc4kQ/A 5xkl7oP8TdP+veg+UAjAliDF7iU4NbGcAer+NeV+lT0Zjx/V7T+j6BuqyHzQspCbsQl/CDGD5SrZ pSBT7gbalvG47aJj7V0AMhD5ATQxyplOyONuExuzAre4wTX5IgSBMH4r8ezxrPDoANBBjnWeyYzx 1aLyNB4rlSMA6l2g/qH7DvF9iqCBkBMKai1GoQezca8lbgIjosQkcNFl/hDkShRgISXXyfIinKgG AJARBR3z/gAOnQHHMuT3u98MzCXd0QL54NzfTJOT2Zud7AGa+TMsuQHTiR0OEyCncCNqYNBSQgcK cRMmANopGzSxHSo0EyLZ8i84ORP16q0K2IvUzgf+1wkIMNP36Y8FUOfYUeYT+vGhfiUxafMnkCnX AKJSPxx4KSV+wtLErLGCUOlDYZelzcrO8eCuPBfNYAu1vwJFGZ3IEQ7I8aco86m4WgvnkabIcCXf 3pUiPD0UAS5ZzZMw7wEdsflHgi5cIJtqUDFtkZFC/fSZndELra9B/rN1TXGfzRin9xrUro8CVH2P 6PIVTBLUdsK0KsGovZ8C4S+qiR0SEIAASGReQA4JIFjsEgQu6zxwQhRskELgKRynOIMkOWVHTmAg SvIDGCwI0MDyGQA2E4KEwDEKkK9gFpZSXghNzKfC2aQyhEroY54YDhfk5YCYe7UHgVYfOCGwWaQ3 ACSOCoE1tAEDJKKKDqUAkp8KhDW9y4kEliADoigoFDi2jNCPLAOwTwASjBUMhb8LnpoCuJcHhpka IsxEMJzBJJCvYKihYSgwTK2UuOStJqQ8AhZnIxilkkwzZyeEBKxRDLxlD75zPpU8vYGDzW/wgQSr hIEPie9f5Y0A/joBxUgKlJWD0UlLmgypOrD6ICgZuSXiMvD6wEebik0TYAGZ5QAcjAK6dpVDQGJd kQFdimWQoPLTNVIsCWbhkoKAATUgnB1ooiomBlQxEzhUYVNJuDsntfTz07SSh0FKZ06lOnXMFHFu npmYICZHiKsdTF24NjTnRYyvYk14kCBkSB0YaOlKgLPcFC9HSqRpiGIRmjP9CBzSUDWEmU+sck5w 2UQxTBUIUib8BuQmgC4VEybFVAldOluGRY8mnaUiDl4YfJZ2dWEjkLexH8wu0OBtjTrlDGRkxIhC lECMo7T7NkfBFzqpDbPBCmQsTMAoDiCUg1UeVrxjm3edsjYE/rlLT4MEMCC19Hn0M9col3PifGuN 3mO4jZ0jB1y4cUW7T2+YvwrTLrgBig6Q+C+DA25ApysBYTgQBvDGi8SeICSTrz8MM9Sws4wAeA02 +mITsYChLtzwxPQQMa+IDjGMEAinPjvHipJQtPFGFOHz8MK2DBixvnpwFBLDB3F80TmmRlDykBmL HPJJKPXQ8UMYHugkRCBzMDFKLrvU48gABeTPSS/LfHLKFbvqRxH72lwENDNtTDPOLBQgk04884Th nxYGCgMdyRRBJSXPziFIRkQTVXRRRhv9bElII5V0UhqdsvRSTFPSdNOUBOApUE5DFXVTBQQSlYVS U1V1VVZb/lX1AFhjlXVWWmu1FVbsctV1V157zbUMX3/d4CQlgOX1VlyDVRY7ZJt19lloo43VVWqr tdbUUd0BdVRuMfX20kotpXRccsst11F0000Xxg5d0PNdeAlKMF564+XTtTnr1TdPMPf1F8opt/x3 YCj7JfjgDQNGeOEuDWb4YdIUhnhiGx2m+GKSOqQSY45Ls7hjPSlET2KQSzbsYw3hHM+GLiGDwq7R slHtshCM4A+vEAbQWGAxTfZ5gnmhLEwPnL2AGcUPTvpiutE0mW6YATxNzQ0SThiODZ3V2kPRnzsO esg17lSpQSEHMwZo9giKIq57JlCsCBAq+ggzM7J27UJ0/qcCzdCuy/xaSDpUiZqCIYSz2QMslADj B2nQM3usYhQ5KjBR6iHqt3Xcg4xmlrSBHLOdJXQ0Xwen0GGKy/uGwY8T/y5NZQebeOI3VNAADBKX GGeBmCnakYgqs3+KY/IpLCrQAhJS7w4oM+ryomru+nxlxSZnPGSESPggPacmJnuX8xPDvmCM1YnJ 6xLXHTRHLPfaV1OLo4oPJaFrCoB6M2KegO7Ou/KAfHhBmI8D/xtFFHiyjcPALAqeq9tAFLCiknRK glGTYCXEswwlzKMVc3vKIkQQpEF4RmTnGVvCDtCJT3xBMK3ggACjhhYIkWlRDIIT7GrGByTYZRiS sQB0/noiBVh40CBcKU3wVEGNInjiBTvMBFGkAAodFUWKQ/zKBeymEfMEgIIucIEfJlUjeV3kJldw wk2WNxQmnEERMCTN79AjD3dlICMpeNtgnLcKN6Zva2r4UxbGVjzN3CQNLunATdIIlSe0rYjhMAIR ZidAq9WueVPwEa5QESTJBIM6uFKO97AYu5IoyYuSidTgCGI/XpQAMIHc3TGE46fzuDEnwTHCQLrD BiS0aCW75EmE8vgg/gGiSGtowhqexhPsRAIrEgibJHR4tdRVZYROUIYVGHMCMESDaiEIRDRSooAD ZnIVnYSlJz2UxU35gVCh8sMDD+UHVXzDCDjRDgsC/oBMhwytP7IMA2CQ0JNiqnIUGWRhQYH2DaVx Zk/BVIM5X1cknnGJkmwkIgkduCJurZNUhwqgKgv5g3pmIA+wUoESjhbLcozFGbxDSs1coBOsGSV4 PwGCwTLKLVQwVHWSGWZ/zOlOB2GLneos1fYEdMbeUYMQOKAGCb7QnQ3IbAMnbWNKhfGM40hRTJMZ zOeeFwrFmCULDovEt8ClU9VB6adpCkCpMloqtJqDbFoE0N6s6La4qoefR23DMIiguNlxh5I56B3T gIEgbWQjmuMwalontlbTtMNVPMnrv2CphRdEAq9F8ABxtkAMpmiKMWThjzW/VFnHEgyyppEMq1yA /trUanI140sbelAW24et1kEKktH6cKu3Q3BJj7+lmG75iAkbEjdew1Vubi/a3LQyF7oIM+50TSZd 6w6sug9rLG6xm11/ifOT4DWZncgLsZ8WU13rZa+53Esus3oLM4Rqyk3te9/7WkuyOrsWOKX1XwDf alkDJnCBDWwBAg8LA54KcIOj5QRY9VfCE8ZvhUXllBDGtynvjRRPOPzhSbH3M+tT13lNfGIUp1jF K2Zxi138YhjHWMYzpnGNbXxjHOdYxzvmcY99/GMgB1nIQyZykY18ZCQnWclLZnKTnfxkKEdZyibr 7pStfGXnVPldI1aDiL38ZTCHWcxj1h6IzXxm/jRb4bL90aKF3WxfA8RZznOmc5vcZGc851nPe+az g6N1YEAHWtCDJnShBw3bZSDC0ItmdKMd/ehBy6rRyRK0pFHnZ0wHmKIp0gCuLtvWS/831JlGVqdJ LepRn1rV0sLKs1o9K2atWtazjtVQ+IE0U88UG6jTFbBiBWllweoqwfq1oY/DawMbq9fA7hU4mf1s aPvKVptGjzGXF4xUJLjYyEs2siudK2dbWli+nrb5fDfu48CaGr2itKmVrYEpHJtZAuHhriwNhWjn W9uEphW1z9OQdlMjN8rMTmEU56Fd4VvfeZB3RLToaBT8QLG9K4qupADod7MgG1hZiGCWpXBm/m9b 38dydqCnjWjkIru1sPLTdgpDgu7Fu+Qo0ECpymDzUB9bZ9gRyLt1tY50cwdY9Ib3zVOCnS6irp04 y865mf6FpH/C4w8UwLEJsYFRWmcEx7Fn4OSHnaprwKlLerqSNvDAdUdhBEpIXsOlPXK4Sxrll1C0 FRKUDWUgopAWsN80BjjSiPjvnnGjGw1LYIl+0M1XwcUMVEwBPcKMQCbBBeQL36BZl+hkA2XA9zU3 I5gmBGVsk6Fr2z7SdGB1PDNIDAoC6OlwChRSGcRwXjPgfvt9z30Py7w6LIBK8+zYswmGKEIAQ0EI szG98yTYXfc6OgUlydupwglFF4xQvH8M/kMvHijD3kHB/N8gu/N90cQZksDMJdSScknIQxyuz3GU HAcn/mv818FaGHcoXh2kcCru/X8sucM15Ii3rrggRbMibDIbK3i444M3vyuk5UMiYqgvsCsJ6VMC gSi4wiuWwWgOSzAQL/A+UvgAFng/l4sIFsi/7qMAwrIAvFs/KBgKg8uVvdsOuukJVbq/N8i/E8SL jfs/IHy1TvO319EA32E5+BMsiksemvM7D9QL6DsDUJBCmMMfZumVh8OOBlS8Fno6PPo6vysFJPpB LyRBCijBr9NCp3IlrmCWL+zBiJAdFkAIZJAJ2ktDkkK+IARCciNC0gC4drsca4tDxbu8/kOIg6RZ hcFzG7iBgjeoQoS4nmDJPi18vMdJGqwAKenQLEJgkIKTOmB5AVYAP7ajObEoPEKQneQboEcALekz hzgIjvw7B+zTgHQ4uNRLBw4gwz28PWPBFd1bilZrKsk7C6xwg4lCOk1BA6M7t5QYAxm0HdM5RlQw wQErA1/ThF1pQWqIxktjtysMtl8ZOQnwuV48R5O7tfBBtnwZxmNBR3iMx12xE3msxwILwHVMFntQ lFSzNFhTtl+0R4EcSILcw2A0jYJMSIVcSIYksIMcD1qbFf86tQmryGt5M4zMSI3cSI6sMA1rigz7 SJEcSXGBFPFKmTKjFJLMFE1Rp458/kmYjEmZnEmarEmbhEkbwYFQSjNJITOf/Ekww7KJOSyhxBGg PEqkTEpEyUmQqgSefEqojMpzkUqq5EmlvEqsFDOmJLGs7Eqv/EqwDEuxDMutDMtCSYexTMu05Eq1 bEuxLMulbJDs+bI/OYenYJ8SWxCgrEsRczyf7LJF0QGkNBC3LMxEgUsZiZERuET20pQ3oUUv2sd0 +Qc+4CLJFDPXs4+zVBdP+YafnEZWXMrTWC8AKIAEsYjLLAbDXM0FQRqQGrFhk4fGERNHgRvrgAr6 UYm8gQ6eGAi0ZB+2XMoKsLU/4BoS6yzd5C3lbJTrEIgZ0gzSpI7LMJSqYU3rRExD/kEiBNyLINlN h+iAKxkMK0ADwWyURqSAOTiGiFiFN5CH4IRNokAEFHgEiTujf3opH7w2rGCS2oScbHimAQpQQDJP m0FN8yM41LHOwtxKrqQdLXkqAXCD47jMGcqgyzACZ1McNDAAdbkJSEiEpQGH7eMLRrFNiouzHICE 3ziKK+gdmFMhxVEcNOLP2oSeKviATri7p1KcEiNDeZiDCrg+i7g8BV1L11QTQwnS6finp5LG9xwx GZWCVNDQJ13KDHoDgUM6A/qCazBPQ/CDGtzFp/qNl5nOMTXRJsXLGi0BmHiagNLQ0CRQVlyaTOxE CKvSIr1K7EyH/PMCDaWgzeQa/pcBrR2Nm920nQzA0LKShKci0RkSq2dgCESlQyOQABKACYQQjyjM GxsdhqhKhsPLDjmFinVjJngCgUTK07c80gbFC88o1OM51Oy0J1glzVtjxoASjA5whNp01MsAQRV1 hBa11AWyB0iAuX4o0LwB1gFco+K4Ah4qzxLli0QFLGS6iVpS1bFkUNjskKdC0HXRw4u7JY8rscqw wsRg0yXwUiLdVdSRIvBcnnSlOcUbVzUtUaJMxW0YoDkgwHQRLwohn4ejBDzVVqTcUxyyoAWUK0NR l0HJqTH7B8kpAGZKSkVIFQ7trSf1LY5dr1yjiBo6RSR1FD28NrkyVIMlS1Yd/jFrFLzfzJuNS9SC LdGSVS+k3LzuU8s2OaGjtKBBSYnHBJSUNdLwIYK4HNmg5MswA8yk3C2ipc2jdNqhXdCVnVqrvVqs zdqHHA+j1Vqv/VqwbUtuDVuyLVuzjdqqHbOZzVMlKQ8OW0m4FcmbxK+QKM0CoDO8zVu93Vu+1Vs+ +1vADdytbKTALVzDPVzE5TNX6Vu+nduXjFu4fcqzHZOtdY7aKkrM5ZLDkqHJzVrsSZRzQYeqHF3S Ld33KstA7Vz2YtoZEp2jtFnjXFvVdcuxnd2+RA3NrNJg4JV7XZQ4RVrtadfeUrTDM0yl7dzatd11 IV7sqNjeogSnGM/iNc/p/iMEevqM1xyxNbCCsJOfwowR5U1e7VVe7UUdThkD510QSFUNSlhTN4gz 02HL7P0M7eS9AeUb2Q1KHJAVWGpN4B1a8U1S2OUyPC28waTQ1SWmK9mNurgOl03SuglT89TDzVsl 7GVLKTwDxpu+dKARBK7N1PXdwWgKI/SRoMAhOZsHL3M9ngLLAI7XAU4H5LvepezSvbyCoLzU3biO epAc0IJNM4CM0TzMq5OOs5Pf4JxGC5IcppqR5q3LkZUrAJlZuLkKnrBiFSqjMjDAw2TYQbiOjt2b vUzbJK2AGO4A+7EIe7LSdY3dtT2EN8lY3+XHKwaDecmH40hfd1UBFEql/hkqYqH7YXSY30JqPjTV gUc6qRywC3n4iPIoD9qBhzNWX0EMAcU4oKPyp7gIkjHgA3Coh3rDCSEFvjEuWqQlU2sEpMJDV3xA nWsQ1cTkg9lAlByYjgWeF4gF3YSVEQ8FJ2Wgg0GROvXluzyoovlUlOsTxGWSEUIuI0gmPgddApPa ZNvBCUbowsEwghOCBxV61BTg0CiAGWcYtmJ2AzBGkKMAJ0LgoVqKUC41IFgIYbok4wB4APPJiVtM pvmqpQGimxw4zP4rDI2lqvHR4+z0XnRIBGS0mhM6Oj0m048YkCGWkSMunW4e5AbdAEq4Z4RLJMyI FacS2Gqmwz5AIG8W/oHb1CqsAwhFu6faOaSnaombeL6kQlkyE197/gXR7Wf7eYbm3Yts6F20pDhE 4aF/iLMCeK3DotFB/s6EFog7Wgc4mhwgxk07MIEu1oYxAAOtYOZWjblLpJtUNZoxSrqXMuf5VIE9 niFMrWmYepmjMlYX1IAfIFQVbaRhEL6FuF+1pefCGzaOQ2NU/dSE4IJ+FeqFIORzoFimANONmN7e Cq65FAtqgKNgsOYeFmYIVo0pjFNepuxjM+kLlhESaOXUCGz6PRzUAAHCer0XeApHFc64CYQsXomX s4hWBhpV0gEmbUVIuCeQigI+OI5S3pDNZVnC7iP7gV92NoTjqIc0/iAjrmldNagHsWDq8ZWRWvrR uhiKBkYD2RasAWCZif7sLSwjJO4tnGGESBgK3US63f2EqzApD+g/DiXTk84EwBIFoBFefTYLiwCk EugC+t5PvSvulOnaEfun96QDrOur6egAWFmE+yY9L4MULRKEyc5LX8DbNXrgdKAOFeUORtGGuRZt jE4UW9TG7fht7JFs7OkK7Ebsab0cPzEFFz5YejYUpe5ijn0fGlrOMMusMMugnwXaeTrM9Y0Fz6bf PKiaNhVeTw5O4FOEZDFpqD3O/13dKmDJb2hjsH3hlyVfQyGEukgVog5v3CzzJk9oX6Hhc1Bs+tVC SNiN/CWzkuUV/jspWzFnzTsf8lz54AXhRV1ZXsp9FCk/WhnWbJXdGj7fcTLH1/ahcfx1XZ+c5NaN 9KTc83VZ2Sgusf3AE2BCuTHWdLDVMqoABi2CXJe8yR8ZEcaNdVnn28StdVu/dVzP9VpXAMW9El3v ryvZSgthdcidcW2lmL3KXAe53OyyTkkhdrN6sx+Zdb/VdTyD7KxEXRELsUfpScBuSEgzP3BfSLX2 yj5XyhvccABW9oIAAWMnbUo3T0jHSrpxj3ABSXbfF5x59wVh8Hk25T+P9xId8YrqimnK9yjZSQy3 BEWc4IPzMvENeNIkeJi5ARZG+C7h931vlC+XvYAX3xlPjGAI/kqCH3BXXaYwGA3QQHWhZDyo3XhF +QYsUKZ9BL5+pvK0DQYi9QJmmp/WxN+QbcU+4DlTkomrlvHNugTlex3COgGYIeilgHoUY5TZeXdx sku4iQbh1iymuNfklcHgcr3D6W4O8APM1o9gRw05rne4IaWg5nnOJou8xgQ6rAo2oAQVDdWZ6AZ6 eQA6YSoa5D53VxQiaKRKUD9F6oqwIGDj7trCu4ZiGRYLvdYXsjXyQAM7sbW1z3se2rmiWQ14YwGn ykKPixtBeIwqSj9gyCQOve86bINNIIaqEaiSMB/y8QZw1s68QNVYRPmUqYEGaIAFWIAGiJN4zVk+ qPpEKQlr/qsHYd4LDlUJkvLfxn8f98PS2FfRFy1mCwjS9TYfdPjto+uq7IF7P+3M0oabadCBLhjn AAokIeh+BMt7CCSLAMqsUG1i0LI7xIMh2e9CCACCAEBGzXrzDkLRNAvJmGbjqSvLCpVBEMEXBAcl 2ftuAMmhMpAhaoGZRTasAI20FnQVSFReR5lsoqhckIhuBSdADGzfWWBItQGGAQeOEEwfMNxiJnf8 cu1Iy0ZCDsHXlIHCDULCTYKAwcCigcFijhCW3QfSUVtQAoagzCYA38bfTM4SQF3UygPJAsECiggt 7est7m0BwwIr684PDQ9OFQ/PIwVNjNWOYMVRDFMysG/1/jOVxCghwsSBd+aydioBNiGM6XTbTHcc loZ5XtUB6QXXU+X53cXBzYABIwJFiwYM4OdJDwADQRQ+O2WDwhJPnuyhqnTv3gRLTDBZ0+DgY4MT shLUEvHgJMqUKdk8YNCRBQ8nNojpMGZjAB8zRYwlxDJDARYBPF/+wvaC1I9OWB7KqDPt0pV1TWO6 sTAkaCk8XCoUQlK13hJSqyzQ0JQjmoVyVir+yOGMwFo+0S4g4DckI7iyC+d5EgXtC0eiG2w42GXi VQpfCFwK7mDTGE2hjw9pEmazDcGdBJlRawwTG7CYPol8kMnGCGqZ2p5YeDQpAewEMbRGgdvBmYUt nnd7/p7ShDfwDQ4YB3/MZkoOyZfPoDHu/HFwD1OePa9u3bg61u1Ge2MdxYdjPAi8Ry/fgqD56IuD Q5Id+73syNfnW0+vYbpp+vp53rXv/z+AAaowHHDMjXZgcvspGNN/+C34IDAxkCcghRVaSBSBFz4j xWmNTVieg/lBeJ2GJZpIIX0AFLDGiA8i8AhBMcpYAI012liAJDnquGOO2PhnCHxBCjkkkUQagCOP SSqZpHuwKVkkbD9AOSWVVVoppAJZaqnAkl16CaOMYYqJUwILkDEmmmmGGRCbbbopAJxxyjlnnCKS 2GANJ+q5J58VIpBYn4EKOiihhQq4nqGJKrooo41m/oCoo5FKOiml9kFaKaaZarppBy1x+imooTbq qailmnpqiaSiuiqrrQKnqquxyjrrCpfSeiuurtqaK6+9grqrr8EK29EDJQI7LLLJEqqIss022GKL Kkk7LbXVpuTAAx9puy233Xq7bQjfansjueWaey66N9ZSQLGSBvBACCfIOy+99dp7L7756rsvv/32 WxLAAQs8MMEFE5wuuh/dKC7DDTusrbUqrUiCAx8KOhwDBYxXnbMdg1rAAg1YrOdwBYzsMcqmulKA oAEswHLKMc+6S58utyszzq7SrKcrJ+f8M6iunOiyz0AbvakDgF7IQNFHO41pAQ5oyIDUT1tdKnEo /vZyNdegFmYhAy90PbamAWQd4Nlkqy1pAzcD+PXacUv6gNL/tS033o2aTSHTefud6N4A0lD334X3 Sbh9iBu+eIl9C75A04xLbp/jDSo++aJmr6tByM+Y2fLSkXt4uXlp5Egbb0WXE9gH4K0Q5S+aPhCL T5BXwAABLMMiegt7TFr5j2n711QcQQCXigqiDCC2BritACcreGVwBO8nulI1AK5sDQAJBRCAvWMc dMiBA7lLR94TrFW/G/D2BUB6ed80hEkAqG8w3v2sOa/BGA2JD7P3PIMeaTBPG/bTwIvuMwn0LaBq I3gCL7ZHAs/xol24y8AEKzA7t13Qc53TYMgY/uCKlsSiXd6Dhe24xwsCjGAEMJseLGTQrtmNIBky CNkHAdS+9LyvQjTJRxJk4Dqu+MQOoJBBJshRiqUAwio9QSIfZmcxOagoOYNYSlSmhwVB+KEIo6HB F+YBjzz04gpSc4AsXvYBimWPALw4IyyKhcYXrswGJHyhikSYgRMWhmLaWyPL0JgYEjSgYg1IQPtI 8ID3fa+NDBAZ9xZwEgaQREA7LB38ovNDbfSEBsgjIgbGsRMloiUPOcCBKAjhuxkAZowcQCJaMlKV MmSHf0g4wBqQQEVVUECJneRcGWWRApDRjQKG0R3TRgAAjKVgf65YoSzwCICQsKZ8VcugLDKw/kjD VGABPtqgcCRJxkzADI3tclkmeXNJEAnPPpvsilYIMMRUUK+UfEAKFwqYyoDg4yrG8wAVU4EXGSxC I/fxCgXQ8ocJGCgUGlhZCEaQNJd4ryWPbJv5rBlREfLioeZ75gZml8FlEqBd2GQMyNxYSRVqs5HN w8cEj1A177Emh/9ZZ3QCJ6BNzoV5vjRoPS0CEXyQ5aB3wOcQgDIyKgYwE48CBScPeo8h4GGhcKkH GDkQwkXisFiuCAm2HqlGQYrwq+Js6QzdCMzylbOk3dxaNmfHspYMkjizA18VsafEu1ZgjiBMJ/vW 1xGdBkh+mcDALo9QQHra8B5DLQU2unIH/upZYAyPBWgQUuEMZqkjqhmYgNhiYArjUXGX0ssAJcWZ 2id4c2vkANQhbdfa283VpQDAHcxwJ7U4ktSkcHUJX0E2yO3J9XaMIcHgGlnc2+UOZNO0pGA70s70 KAESSJSAEHeZAbQUIgmgAKM8bUmOC6SSCjhwxjgoIIDA0GQ0SRSED66wxFFi4otJVAIHREoD7xEH dzmABXFO2E21JqGNeAxF+bY2OwpYcytcgGssVsgFoboxwQ2hXdVmx5EGuNGi0LWknxSAg7Fcg8TT w4TrIIGIDGRpMIfAgx3wNwrd1C8DGCilNJ6xvGx8gAzMWy8HaFnZPAgFdQGxWIfQp77B/txnek5m cmnCF6hsoi261gBsrwTgo0xsWTDyjQfXrnASh1ZZQFhGFpk9I6F3WDlZiiBBAvDqH5xG58yYu3Ng QYznPeuwzb6gM58DLRhAAweSgj40cAitTj8jutG3ZXQUFO3oSXdA0p6xtAd23Bj7CTk4QxSgdsuT wEDh75O7icZp31HAwR4w0ZCGAqY7MA8PuTIt6iFqYwiggFUHZ3/l6XILbIPj3eBmiryuRqjLE2ui LNsFyVu1MP5QmnpQ51GDMfKENrHI+6BufM9wXXd794/zeIch4/4seKbAuiV/ADblts30gI1dH3xB yz76wrlvAu/7kQO8G9IGPDRhvzNg/sKyXnAocvjBFXwz+9UtaHbzilAQrBwUC1X1iTJ8UgTRJnSL AybNBNxRcSGe47ocV5/Gg4jiHHTXvYq9QxD7WUSAE8K9Ch2EXvB7BFz68hIc+G5Dk2Ddssz8pXGo HwXuKQcc+AANyfYeP6lwBqAkPRRH2PVXyME6VkDcGl3nwhay8GVT5tgNyClLEb7gRSSsmbJe+MQp vXMEDIB2yOYQBHlwY/Z9Z2LtbYn2Q8RmjmRXEbwPATwXDJCT6zY2T/1eTVEB+gLGqh0cFiAtPnzX BjKot5fgIUNran2ERQRAQn4ZxI1VOQHEtprrDmfB1534G1O3NAiJnUFTLeBFbAgi/jbhVcITvpAA +4lCFcYrvW18rfmi4vr3XoznP0zhRV6XEi6icB4fCDFx5IeBNDF3KK5V3ZOGNDTsYtufqZcwgZe/ I81E3I5T4x/eI5JG2i+JPSsMTZR64GbYHC8taMxA9XmR8QjCi7zIExzRhblS8SXAFsBCfyjfGOlS kOWOLsVTGUif7nEAQ9gDZTlPRChAI0yCtHHeKWCAGTgYQJUeWuxBJQie2LyTtHHf+o3RC1zAsM3d Z0VVKvnAb4yCPTQG/kWB/r0E/7GF+LWFEmbH+vXd5XXfdlUAzIBWAMRg5pkF5wWhrxVYJpSFrOna hFWB0xXB7Nwgp7Fd49XdE15F/hVelygUAm5kRPF1gDkwFvvZBrxt0hNeHqpRAFBMmNt1GSqNHymk UtWlnS752RBCQRF2hBJdl6/JgZYh0eh5Dx52QT1cV8hdxYSdQRUhA0dcAVSNHsltoShSEWVtQH+8 1y6NhhexDv2F0h9QHZkxnh74hG74RC6J4StdQBx2nMgFHFFFxWPRAxOZgw62H2lUxRuG11WAYeQ1 nJn52awNgG5wlhaRA15cgTU+AQ50Y0LQz4g9gQCMoxB4Q2CkwRToxijwA+ilgWPABiZsXVXYmALQ BkHUDxhl202ITY09Ck7ch9jIWI9xAwIRpD/imj5GWZRVIfPIXQdAz7+pD7sx/OR9INmTpccitkAj cs0XsGOm4AfQbCQLdOTVXBelfViAmKTVvF5KPpxLqgBLviRNasB0lYfJ1KROOsZNRkfU7CRQapOd CQa8BGVQ0giK9KRRIhpJwuRS1mQPVQhSPuVL3k2FuAxVpiRhUcjOZGWjNSUrnJVXChrVnEgKjeWe NYA0XUjPoCWeqdGe2IxbSo7ZrKVZDuVcHs0DEYpf5WXcoJFYFopwVUxMDgq0HCZiGkPELCZjNuZi dssyPYxkTua4kEtIEFJhmge8RJC/1EtIdCZohqZojqbBGMw0lSZqioCNlATCtKZrvibCqMi5UGa3 IMC2+SVu5qZuTkoEAAA7 ------=_NextPart_ABD_AD6A_F4241EA8.0264D12A-- From sip-bounces@ietf.org Wed Jan 31 22:10:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCSJ7-0007qS-HV; Wed, 31 Jan 2007 22:08:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCSJ5-0007qE-Sn for sip@ietf.org; Wed, 31 Jan 2007 22:08:15 -0500 Received: from wx-out-0506.google.com ([66.249.82.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCSJ0-00068Y-Mu for sip@ietf.org; Wed, 31 Jan 2007 22:08:15 -0500 Received: by wx-out-0506.google.com with SMTP id h31so404624wxd for ; Wed, 31 Jan 2007 19:08:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:to:subject:organization:content-type:mime-version:content-transfer-encoding:message-id:user-agent:from; b=XmzMHc7CcLVLQ+DHbFHz9gTYrlu18+FodLnd7ScfrNVgqZ1pEp7m60aBbQbT198vcwGPD2yfFoYoyA+8AmPdMu+wu14CWuUdAGntpF/vNSDBJYvabeLbAUoYfJ2qkFrDsKkvWB3XP/bOl/N7YqHJJFd7SL9QwNZuWZ3nOGqTJhQ= Received: by 10.70.74.1 with SMTP id w1mr2846553wxa.1170299290376; Wed, 31 Jan 2007 19:08:10 -0800 (PST) Received: from seu-xcr ( [202.112.23.206]) by mx.google.com with ESMTP id i35sm3924709wxd.2007.01.31.19.08.03; Wed, 31 Jan 2007 19:08:09 -0800 (PST) Date: Thu, 01 Feb 2007 11:07:56 +0800 To: sip@ietf.org Organization: SEU Content-Type: text/plain; format=flowed; delsp=yes; charset=gbk MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: User-Agent: Opera Mail/9.10 (Win32) From: XuChunrong X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Sip] How does SIP keepalive between 2 UA? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi.. I have a simple question.. When 2 SIP UAs have established a dialogue, and they want to exchange text infomations.. However this text infomation exchange may be very infrequent, how does SIP keepalive between the 2 UAs? for example, 2 IM(Instance Message) users may online but talk very infrequent, -- Best Regards Xu Chunrong Southeast University, Nanjing _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 31 23:53:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCTvE-0002O2-T8; Wed, 31 Jan 2007 23:51:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCTvD-0002Nf-BY for sip@ietf.org; Wed, 31 Jan 2007 23:51:43 -0500 Received: from celine.siteprotect.com ([64.26.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCTvC-0007mp-3M for sip@ietf.org; Wed, 31 Jan 2007 23:51:43 -0500 Received: from [192.168.1.102] (c-24-9-79-73.hsd1.co.comcast.net [24.9.79.73]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id l114pdx10562 for ; Wed, 31 Jan 2007 22:51:39 -0600 Message-ID: <45C171D8.9030500@cornfed.com> Date: Wed, 31 Jan 2007 21:51:36 -0700 From: "Frank W. Miller" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Sip] Simple procedure for NAT traversal for a UA X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org NAT Traversal Procedure for User Agents I've implemented a fairly simple but general mechanism for doing NAT traversal with a User Agent. 1) Open a UDP port for SIP on port number 5060 2) Open a UDP port for RTP on port number 5004 3) Send a STUN binding request out the SIP port 4) Send a STUN binding request out the RTP port 5) Record the IP address and UDP port number returned in the MAPPED-ADDRESS attribute of the binding request response received on the SIP port (call this the visible SIP endpoint analagous the the ICE server reflexive address) 6) Record the IP address and UDP port number returned in the MAPPED-ADDRESS attribute of the binding request response received on the RTP port (call this the visible RTP endpoint) 7) Use the visible SIP endpoint addresses in things like the Contact header address and the Via header line in outbound requests 8) Use the visible RTP endpoint addresses in the SDP offer for session establishments This procedure seems really simple to me and seems to work well with the limited testing I've done. It does require the UA to multiplex STUN on both the SIP and RTP ports but it only requires binding requests so, again its pretty simple. This procedure is certainly a lot simpler than ICE but does not take into account relay servers. I would be curious on anyone else's experience with a procedure similar to this. It sort of seems to take bits and pieces from things in various drafts. Thanks, FM _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip